►
From YouTube: IETF100-DOH-20171116-1330
Description
DOH meeting session at IETF100
2017/11/16 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
A
D
A
C
F
F
E
G
E
Here's
the
plan,
we're
gonna
briefly,
tell
you
the
thing
that
I'm
telling
you
now
and
then
we're
going
to
hand
it
over
to
Patrick
and
maybe
Paul
Hoffman,
who
are
the
co-authors
of
the
one
draft
that
we
have
on
our
agenda
today,
we're
going
to
hear
what
they
have
to
say
about
the
open
issues
on
that
draft.
We
have
time
to
discuss
anything
you
want
to
discuss
about
that
draft,
and
then
we
have
scheduled
block
for
open
discussion
on
all
issues
related
to
the
entire
concept
of
what
we
are
doing
here.
E
F
F
However,
where
things
actually
land
at
the
end
of
the
day,
I'd
like
that
to
happen
as
we
identify
solutions
because
I
don't
think
what
I've
been
raising
on
the
list
requires
a
tremendous
amount
of
text
and
it'll
be
really
silly
to
create.
You
know
a
three
to
six
paragraph
internet
draft
to
you
know,
to
address
something
and
I
think
the
at
least
one
of
the
co-authors
I
haven't
talked
to
the
other
about
it,
but
at
least
one
of
the
co-authors
understands
the
you
know
what
I'm
talking
about
so
all
right,
okay,.
H
H
A
H
Right
good
afternoon,
yeah
all
right
regain
my
footing
here,
yeah
good
afternoon
I
guess
we
got
15
minutes
and
I
aspire
to
stay
within
that
time
frame.
H
Okay,
I
think
we
all
know
why
we're
here
so
3ih.
Tfs
ago
we
had
a
little
barb
off
I
arranged
the
room
for
24
people
about
85
showed
up.
Then
we
talked
about
what
DNS
over
HTTP
means
to
you,
and
it
turns
out.
It
meant
something
different
to
everybody,
so
that
has
informed
this
work
going
forward.
Last
time
around,
we
had
a
dispatch
version
of
this
proposal
in
Prague,
and
we
ended
up
with
this
esteemed
working
group.
Welcome
and
thank
you
got
appointed
at
the
laptop
all
right.
H
We
have
a
draft
I
love,
first
working
group
meetings.
How
many
people
have
read
the
draft?
Yeah,
that's
got
to
be
around
50%,
maybe
more,
that's
awesome!
No
one
came
out
to
capture
some
early
feedback
and
I.
Think
the
most
important
thing
to
note
is
we
have
essentially
six
months
according
to
our
Charter,
to
submit
the
specification
to
the
iesg
as
a
proposed
standard.
So
I
certainly
don't
want
to
spend
my
whole
career
on
this
document.
So
I
appreciate
everyone's
help
in
making
that
happen,
there's
a
github
a
set
up,
Ben
and
Dale
Dave.
H
Sorry
I'm
announced
this
on
the
mailing
list.
There's
a
little
screen
shot
of
this
from
a
few
days
ago.
As
always,
substantive
discussion
should
remain
on
the
mailing
list.
You
know,
chatter
always
bleeds
back
and
forth.
So
I
would
just
have
personal
recommendation
to
everyone
out
there
to
go
to
subscribe
to
the
issues
notification
on
the
github.
It
will
make
your
life
a
whole
lot
easier.
H
Okay,
so
because
we've
all
read
the
draft,
we've
all
read
the
mailing
list.
We
won't
go
through
in
detail
everything
that's
gone
on,
but
more
or
less.
We
have
three
three
distinct
categories
of
issues
that
have
been
opened
about
the
protocol
draft.
Now,
if
you
have
a
new
issue
you'd
like
to
make,
you
can
either
go
open
it
in
the
github
yourself
or
you
can.
H
You
know,
make
a
comment
on
the
mailing
list
and
the
editors
will
go
do
that
for
you
if
they
realize
you're
raising
a
new
issue
instead
of
just
contributing
to
an
existing
discussion.
If
you
really
want
that
issue
open,
you
should
either
make
that
clear
in
your
content
or
open
it
yourself,
so
that
it
doesn't
just
get
incorporated
into
the
discussion
about
about
something
else.
H
So
there
are
three
broad
categories
of
things:
they
are
interaction
with
HGB
interaction
with
HTTP
caching
in
general,
and
things
I
have
labeled,
possibly
editorial,
hopefully
editorial
in
my
mind,
so
I
think
we've
identified
two
issues
that
are
worth
face-to-face
time.
So,
if
I
don't
capture
in
my
two
issues
for
my
15
minutes
up
here,
what
you
want
to
talk
about
I
think
that's
fine,
because
the
way
we've
structured
the
agenda
here
there's
another
35
minutes.
So
please
I
think
this
is
a
wonderful
use
to
make
our
wonderful
use
of
our
face-to-face
time
together.
H
They
built
in
an
out-of-order
response
mechanism,
which
is
going
to
be
very
very
similar
to
what
hu
hu
is
going
to
give
you
in
this
situation
and
the
the
argument
to
be
made
here
is
that
the
end
result
would
simply
not
satisfy
the
use
case.
If
you
didn't
have
that
property,
ok
multiplexing
becomes
a
bigger
problem,
as
responses
get
large.
H
So
if
you
want
to
do
things
like
transfers
and
things
like
that
or
this
mechanism,
the
ability
to
do
prioritization
as
well
as
multiplexing,
becomes
key
something
just
a
mere
head-of-line
blocking
solution
doesn't
have
and
then
number
4
the
number
4
bullet
down.
There
is
also
really
important.
Is
that
the
ACB
overhead
mitigation,
the
header
over
again
mitigation
that
goes
along
with
HVAC
and
the
other
compression
schemes,
may
be
necessary.
H
As
you
look
at
the
protocol,
you'll
find
out
that
perhaps
a
preponderance
of
the
bytes
are
actually
in
HTTP
2
or
are
in
HTTP
headers
rather
control
data
instead
of
DNS
data,
but
htv-2
will
successfully
mitigate
a
lot
of
that
for
you.
The
last
argument
is
over
there
actually
bullet
number
3
I,
apparently
wrote
them
in
a
different
order
than
I
had
them
in
my
head,
and
that
is
just
the
notion
that
it
is
ok
under
some
circumstances
when
doing
new
features
to
require
best
practices
for
those
new
features.
H
G
H
Right
all
right,
so,
on
the
con
side,
you
know
I
think
perhaps
the
winning
argument
at
the
end
of
the
day
is
that
the
scheme
is
largely
impractical,
that
it
is
hard
for
say
a
JavaScript
implementation
of
this
or
a
remotely
deployed
implementation
of
this
to
be
aware
of
the
infrastructure
between
it
and
the
endpoint.
So
you
may
not
even
know
what
the
client
is
running,
even
if
you
can
control
the
DNS
API
server.
Much
less
know
what
downgrades
maybe
enforced
in
the
middle.
H
On
a
more
positive,
no
argument,
number
two
on
the
con
is,
you
know.
The
whole
point
of
you
know
using
HTTP
is
to
rely
on
the
semantics
of
it
to
get
a
widely
compatible
and
deployable
benefit.
This
is
you
know.
This
is
why
we
develop
things
and
layers,
and
you
should
just
put
your
trust
in
the
layers,
so
rely
on
those
semantics
to
get
the
full
benefit
of
HTTP,
and
the
third
argument
is
say,
is
sort
of
a
counter-argument
to
the
it's
okay.
H
To
require
best
practice
is
to
say
that
requiring
those
best
practices
is
then
actually
an
anchor
on
your
neck
and
you'll
never
get
dough
deployed
at
the
bottom.
I've
listed
the
three
obvious
options,
though,
I'm
happy
to
hear
others,
which
is
to
continue
with
the
requirement
to
have
silence
on
the
issue,
which
is
to
say,
we
use
HTTPS
and
not
say
what
that
means
in
terms
of
versioning
or
to
endorse
HTTP,
to
with
an
explanation
of
why
it
is
a
good
thing
without
any
normative
requirement.
So
that's
my
thoughts
on
the
matter.
I
G
I
I
G
Thanks,
thanks
for
summarizing
all
of
the
the
options
here,
I
think
you're,
pretty
much
covered
covered
all
the
ground
reasonably
well.
Some
of
these
are
less
important
than
other
ones.
I
think
I
originally
argued
for
silence,
but
I,
like
the
endorsement
actually
I,
think
there's
plenty
of
reasons
to
to
recommend
this,
and
obviously
the
performance
is
going
to
be
less
good.
I
will
say
on
HTTP
one
one
but
and
security
benefits
and
all
the
other
things
that
HTTP
two
brings
are
obviously
improvements,
but
I
would
be
opposed
to
a
requirement
for
the
reasons
decided.
I
I
G
H
I
mean
the
other.
The
other
approach
is
how
we
always
do
multiplexing
with
HTTP
one,
which
is
parallel.
Tcp
connections
right
up
to
some
time
up
to
some
kind
of
limit
and
I
mean
I
would
note
you
know
the
directions.
Each
time
we've
had
a
revised
HTTP,
whether
it
was
for
you
know
one
one
or
two
have
been
with
direct.
You
know,
charter
level,
language
saying
you
know:
thou
must
use
fewer
connections
right
that
that's
always
been
a
goal
of
making
it
happen
and
so
to
you,
know,
kind
of
invent
a
new
higher
level
protocol.
I
G
J
Mark
Nottingham
I
think
it's
fine
to
say:
if
you
do
this
over
HTTP
one,
you
might
have
a
bad
time
and
to
list
out
the
various
ways
that
that
could
happen.
But
you
know
you
say
man-in-the-middle
up
there
I
mean
a
lot
of
reverse
proxies
and
a
lot
of
CD
ends
talk
h2
on
the
front
end
and
h1
on
the
back
end,
and
so
I
really
don't
think
it's
realistic
to
say
that
you
know
it
has
to
be
h2.
You
can't
guarantee
that.
But
what
was
I
I
missed
something
I'm.
J
J
H
H
H
K
H
K
Yeah
that
that's
what
I
was
gonna
comment
is
it's
at
least
for
our
load
balancers.
It
would
be
quite
difficult.
It
would
be
a
very
odd
policy
for
us
to
restrict
this
to
http
to
only,
and
it
would
be
sufficiently
odd
that
I
don't
think
we
would
do
it
because
it
probably
would
violate
some
rule
that
you
know
if
that
was,
she
speaks
HTTP
it
better
work
either
way
or
something
and
same
with
the
load.
Balancer
back-end
comment
is
yeah.
H
K
H
L
Already
totally
impractical
I
actually
want
to
cut
up
in
order
to
suggest
that
we
might
want
to
say
different
things
about
clients
and
servers,
because
there
are
going
to
be
some
servers
in
the
future
that
have
client
bases
that
are
h2
only
because
of
the
deployment
practice
that
it's
going
to
be
common
to
them
and
that,
if
you
put
it
as
should,
you
could
end
up
in
situations
where
the
mix
of
what's
available
to
what's
available
on
specific
servers
is
unknown
to
clients
and
I.
Think
that's
a
bad
situation.
L
So
what
I
was
going
to
suggest
to
say
that
servers
must
support
h2
and
may
support
versions.
Other
than
versions
below
h2
and
clients
should
support
h2
with
the
endorsements
that
you
have
there
and
I
think
that
will
get
you
the
the
best
mix
of
deployment.
I
I
do
believe
that
there
are
our
cases
and
I
certainly
understand
the
cases
where
you
have
a
front
end
and
back
ends
that
are
different
and
I.
Actually
don't
think
that
those
are
really
captured
unless
you
break
out
the
client
and
server
requirements
separately.
Thank
you.
M
M
This
requirement
is
basically
saying:
well
you
want
to
do
this
because
it
matches
the
operational
reality
of
the
DNS
traditionally,
so
it
could
be
that
that
that
is
the
way
out
of
this-
that,
if
you
do
this,
should
or
something
like
that
in
order
to
make
it
clear
that
the
reason
why
this
is
the
case
is
because
DNS
operates
this
way
today
it's
got
lots
of
stuff
in
flight
and
I
think
that
could
be.
You
know
this
is.
N
You
know
if
you
want
to
make
everything
if
you
want
to
keep
people
people
from
spying
on
you,
you
need
HTTP
to
if,
in
my
case,
I
just
want
to
look
up
some
SRB
sorry
for
for
some
use
cases
you
need
HTTP
to
like
if
you
want
to
keep
evil
people
from
spying
on
you
HTTP
to
is
much
more
helpful
if
you're
in
my
case,
I
just
want
to
look
up
some
SRV
records,
so
I
don't
really
care
what
the
transport
is.
So
I
think
you
know
in
to
us
with
explanation
is
bloody.
J
J
The
reason
that
a
lot
of
reverse
proxies
haven't
done
h2
on
the
origin
side
is
that
they
don't
feel
they
need,
if
they're
using
other
techniques
to
get
multiplexing
and
to
mitigate
these
effects
are
seeing
that
aren't
used
commonly
by
browsers
and
and
so
I.
Think.
If
you
want
broad
deployment,
then
then,
then
you
need
to
not
cut
things
off
arbitrarily.
J
Also,
you
know
the
HTTP
working
group,
you
might
be
aware,
has
just
adopted
a
document
that
talks
about
how
to
use
HTTP
as
a
substrate
protocol,
revising
BCP,
56
bits
and
when
andrew
says
things
like
HTTP
as
a
transport,
I
bristle
and
I
get
concerned
about
building
that
double
out.
Hourglass
and
I.
Think
Roy
fielding
just
woke
up
and
screamed
into
the
night,
so
you'll
get
that
feedback
too.
If
you
go
that
way,
so
I.
I
H
H
So
the
other
thing
I
wanted
to
make
sure
we
talked
about,
though
I'm
sure
we'll
talk
about
a
lot
more.
Is
this
bucket
of
issues
regarding
interaction
with
HTTP
caching,
which
is
not
extensively
defined
in
the
document?
And
this
not.
This
is
kind
of
thematic
with
the
last
set
of
questions
of
whether
or
not
it
really
needs
to
be.
Does
hgp
already
define
everything
we
need
to
know,
so
you
can
see
these
go
from
the
concrete
to
more
abstract
issue.
H
The
other
issues
here
are-
and
that's
already
I'm
committed,
but
as
we
talked
about
before
you
know,
anything
that
gets
committed
off
of
github
is
nothing
other
than
an
iteration
of
an
internet
draft
does
not
necessarily
reflect
consensus
until
we
get
consensus
that
will
be
declared
by
the
chairs
or
through
last
call
all
right,
but
that
is
just
you
know
in
this
survive
in
advance.
Just
trying
to
move
forward
model.
The
other
issues
are
a
little
more
abstract.
They're
saying
you
know,
the
document
doesn't
specify
a
particular
caching.
H
How
does
the
DNS
cache
interact
with
the
HTTP
cache
how's
that
interact
with
recursive
resolver
I
think
that's
kind
of
implicit
in
there,
but
we
can
talk
about
that
some
and
finally,
the
draft
does
discourage
HTTP
revalidation,
given
that
it's
fairly
impractical
for
a
bunch
of
these
use
cases,
although
I've
had
a
conversation
with
Martin
that
makes
me
think
we
shouldn't
be
quite
so
firm
on
that
topic.
So
that's
my
set
up.
Welcome,
mark
nodding
him
Marc.
J
Marc
Nottingham
so
issue,
thirteen
I
think
that's
fine,
I
think
I
want
to
get
in
there
and
wordsmith
exactly
how
you
specify
it.
So
you
know,
if
you
do
it
in
terms
of
the
TTL
I,
want
to
make
sure
that
if
we
have
further
extensions,
the
caching
model,
it
will
be
compatible.
Those
for
example,
if
we
one
day
define
an
invalidation
protocol,
it
should
be
able
to
slot
in
with
us
really
nicely
yeah.
H
J
Yes,
exactly
and
because
that's
the
core
concept
regarding
fourteen
I
think
you're
right
I,
don't
think
we
need
a
specific
one.
We
just
need
to
describe
the
interactions
where
appropriate
and
put
the
perfect
caveats
around.
You
know
here
be
dragons
where
necessary
and
the
issue
15
is
the
discouragement,
a
RFC,
2119
kind
of
discouragement.
It's
just
text.
J
J
H
H
J
It's
I
think
you
know.
Generally.
Maybe
we
should
have
a
discussion
about
principles
in
that
you
know,
especially
when
we're
talking
about
how
we
profile
these
protocols,
illustrating
why
you
might
have
problems,
is
great
and
exploring
that
space
is
something
we
definitely
should
do,
but
just
preemptively
saying
don't
do.
That
is
is
perhaps
too
much.
G
G
I
In
the
DNS
world
we
pretty
much
are
in
denial
about
this.
That
is
that
the
server
gives
some
TTLs
and
those
are
understandable
and
what
the
client
does
with
those
is
really
a
local
policy.
Many
of
the
local
policies
are
to
follow
it.
Some
of
them
are
to
follow
it
until
it
looks
like
it's
going
to
expire
and
then
preemptively
renew
some
of
them
are
to
say
I
know
my
number
better
than
theirs
I'm
just
going
to
stick
my
number
and
and
those
are
all
very
common.
E
And
Schwartz
as
individual
contributor,
I
I,
think
that
the
the
logic
and
the
draft
works
for
me.
But
it
took
me
a
long
time
to
understand
that
logic
as
a
simple-minded
person
and
and
implementer.
It
would
be
really
nice
to
have
a
couple
of
extra
sentences
explaining
things
like
when
you
might
rewrite
the
TTL
on
an
HTTP
to
DNS
conversion.
H
So
the
HTTP
caching
language
is
fairly
extensive,
shall
we
say
met
it?
Has
you
know?
Has
it
been
talking
more
with
folks
from
from
the
DNS
operations,
community
I've
had
to
explain
some
of
the
finer
nuances
like
like
the
age
header
that
a
cache
actually
knows
the
difference
between
now
and
when
something
was
generated.
How
long
that's
been
and
can
make
that
part
of
its
TTL
and
I
think
perhaps
exploring
some
of
that
space
could
be
a
useful
contribution
here.
Yeah.
Q
So
rave
Ellis
I
see
yeah
I
kind
of
have
to
take
something
sure
what
Paul
just
said
yet
TT
ELLs
are
supposed
to
be
sorry,
I,
just
it
sorry,
most
clients
should
be
treating
the
TTL
as
an
absolute
maximum,
not
standing.
There
are
some
that
do,
but
if,
for
example,
we
go
an
HTTP
packet,
sorry
of
ENS
packet
that
comes
back
from
the
DNS
server
that
says
the
TTL
is
300
seconds
and
that
then
has
go
through
into
the
HTTP
caching
headers.
Q
H
So
that's
actually
just
what
I
was
referring
to.
So
that's
the
age
concept
of
the
cache
yeah.
So
when
that
response
is
served
from
the
cache,
then
the
second
iteration,
it's
served
with
a
say,
an
expires
time
of
300
seconds,
but
it
also
has
a
age
of
291
to
99
and
it's
in
HTTP
rules.
It's
impugn
its
required
by
the
client
to
do
that.
Subtraction
to
know
that
this
this
response
only
has
a
one-second
lifetime
left
so
allowing
on
the
HTTP
layers
to
override.
What's
in
when
you're
using
HTTP.
H
Q
Yeah,
we're
not
were
styling.
There's
a
lot
of
people
treaty
tails
advisory
as
a
maximum
I
think
it
should
be
very
clear
that
so
far
as
possible,
we
do
not
extend
the
t-tail
records
because
the
TTL
dns
records
are
actually
for
the
zone
and
mints
traitors
benefit
and
not
for
any
downstream
user.
Don't
use
it
free
to
use
something
lower,
but
it
should
never
go
higher.
Yep.
F
F
The
DNS
message
is
the
fundamental
unit
of
cacheable
information
and
that's
kind
of
contrary
to
what
the
DNS
people
expect
as
our
our
set
being
the
fundamental
data
unit
for
caching,
and
so
that
leads
to
interesting
second-order
effects
where
a
lot
of
things
get
requireed
well
before
they
need
to
be
read.
For
example,
a
cname
chain
that
has
to
our
C
names
in
it
and
then
ends
with
the
twenty-second
address
record,
will
end
up
being
requireed
the
entire
chain
every
20
seconds,
instead
of
based
on
the
our
sets,
the
C
name
so
yeah.
R
And
I
know
you
so
I
mean
DNS
caches
on
the
left.
Side
can
be
sort
of
magnitudes
of
orders
of
forwarders
and
I'm,
not
sure,
if
that's
also
true
in
the
HTTP
world,
but
you
you
have
to
make
sure
that
you
have
the
shortest
time
of
all
this
stuff
in
to
make
sure
that
this
stuff
is
fresh
and
one
more
question
because
I
don't
know
the
HTTP
stuff
too
much.
What
would
happen
if
I
give
back
a
TTL
of
zero,
because
that's
you
I
mean
unfortunate,
getting
more
and
more
common
in
the
answer
also.
H
J
B
C
F
I
S
The
person
who
operating
the
server
assumes
that
the
record
will
stay
around
for
sort
of
20
minutes
or
sometimes
30,
because
there
are
forwarders
and
wrath
for
it.
Is
you
just
take
the
TTL
and
you
store
it
for
that
and
hand
it
back.
So
if
there
is
a
forwarder
and
an
HTTP
cache
and
then
another
DNS
thing
behind
it.
S
Another
thing
which
needs
to
be
kept
in
mind
is
there:
are
various
records
would
actually
expire
at
a
time
things
like
DNS
keys,
you
know,
GSK
ksk
have
an
actual
wall
time
at
which
they
expire,
and
that
needs
to
be
kept
in
mind
as
well
and
I
can't
remember
what
the
third
thing
was.
So
I
will
assume
it
wasn't
important
and
we'll
sit
down
stay.
I
There,
so
you
have
two
things:
one
is
that
the
first
one
you
said
it
was:
maybe
the
HTTP
server
should
change
the
TTL
in
the
record.
The
second
one
is:
we
have
some
wall
clock
things,
okay,
I
would
like
to
respond
to
the
first
one.
Our
model
so
far
in
the
draft
has
been
that
the
HTTP
server
is
passing
along
DNS
data.
If
you
want
something
different,
please
suggest
text,
I
would
yeah.
I
So
so
that's
you
know,
you're
changing
sort
of
a
fundamental
thing
here
which
I'm
not
saying
you
can't
do
I'm
just
saying
that
that's
the
first
we've
heard
of
that.
Second,
one
about
the
wall
clock
again,
we
are
passing
things
through
there's
nothing
in
here
that
says,
if
you
are
passing,
say
a
DNS
key
record
that
has
an
absurd
wall
clock
time
in
it
like
some
in
the
past
or
in
the
future.
You
should
do
anything
again.
The
idea
is
we're
passing
things
through
so.
S
For
the
first
one
I'm
not
saying
we
should
necessarily
change
it,
I'm
just
saying
that
if
it
changes
operational,
stuff
whoever's
doing
this,
should
you
know
be
aware
of
that
may
be
changing
the
record.
The
TTL
and
the
record
is
useful,
maybe
not
more
discussion
right
on
the
wall.
Time
thing
what
I'm
concerned
about
is
a
record
arrives
now,
should
it
should
be
okay,
I
was
calling
a
record,
would
end
up
and
the
HTTP
cache
way
after
it
had
expired
and
would
continue
to
live.
I
T
I
T
J
Listening
to
the
comments,
I
think
it's
safe
to
say
that
we're
kind
of
witnessing
a
little
bit
of
a
collision
of
cultures,
in
that
there
are
some
people
in
the
room
who
are
very
fluent
in
HTTP
caching
and
don't
know
a
darn
thing
about
DNS
and
I
feel
like
that
I
think
Patrick
probably
knows
more
about
DNS
than
I.
Do
he's,
squinting
and
and
other
people
know
a
lot
about
DNS
and
have
a
lot
of
contacts
there
and
don't
really
understand
HTTP
and
so
I
think.
J
Maybe
we
can
look
at
a
couple
of
different
ways
of
improving
that
if,
if
the
spec
were
to
contain
a
number
of
worked
examples
of
the
messages
on
the
wire
in
completely
in
toto
as
well
as
the
deployment
scenario,
that
would
probably
help
if,
if
yes,
if
the
draft
were
to
be
extra
careful
about
its
terminology,
because
you
know
I've
already
heard
a
bit
of
confusion
about
caching
and
different
things.
And
and
finally,
if
we
can
do
a
little
bit
of
Education,
I
mean
I'm
more
than
happy
to
arrange
to
give
people
in
HTTP.
J
I
Would
love
to
have
those
happen
before
London,
since
we
are
sort
of
on
a
short
leash?
If
we
have
a
virtual
interim
before
then
I
think
that
those
two
tutorials
would
be
really
good.
I
would
not
give
the
TTL
one
in
fact
I
might
make
ray.
Do
it,
but
yeah
I
think
that
that
would
actually
help
these
issues
and,
as
for
the
examples
I,
just
a
quick,
Chuck
I
think
worked
out.
I
Examples
with
x
in
them
would
actually
be
really
good,
because
if
nothing
else
that
would
shock
some
of
the
DNS
people
into
understanding
what
we
do
ourselves
anyways.
We
don't
have
worked
out
examples
like
that
in
any
of
the
DNS
RFC's
you
can
as
for
being
care
about
terminology,
I'm
going
to
switch
hats
quickly,
RFC,
seven,
seven,
one,
nine,
seven,
seven
one
nine
is
DNS
terminology,
and
that
is
being
revised
in
the
DNS
off
working
group
and
I'm
the
author.
I
So
if
any
HTTP
people
are
reading
either
77,
19
or
terminology
Biss-
and
you
say-
oh
I
was
expecting
this
to
explain
this
about
DNS
to
me
and
they
don't.
Please
speak
up
now,
we're
going
to
be
in
working
group
last
call
on
the
bist
soon,
and
this
is
exactly
what
this
document
is
meant
to
help.
Okay,.
J
Okay
can
I
make
one
more
request,
then,
in
the
HTTP
world
we
have
a
home
page,
HTTP,
WG
org,
that
has
a
listing
of
all
the
relevant
specifications
and
current
specifications
for
HTTP.
And
so,
if
you
want
to
understand
part
of
HTTP,
you
can
get
the
correct
reference.
At
least
I
can't
claim
that
it
will
make
you
understand
HTTP,
but
at
least
you
can
get
the
correct
reference.
Dns
I'm,
sorry
to
tell
you.
This
is
very
confusing
from
the
outside.
So.
J
I
J
I
O
N
Thank
you,
Mark
John,
Levine
I
would
like
to
strongly
endorse
the
suggestion
that
we
work
out
some
some
examples
of
how
the
caching
interacts
me,
because
I
can
imagine
a
way
to
use
the
HTTP
date
header
to
adjust
down
the
TTL
Xin
the
reason
in
the
received
data
and
an
received
library
which
seems
too
ugly
to
live
but
I.
You
know
I'd
like
to
make
sure
we
all
agree
that
we
either
do
or
don't
want
to
do
something
like
that.
Yeah.
G
I
G
I
Really
is
one
of
the
reasons
we
have
done
that
and
it
you
know
no,
no
negative
on
mark
about
the
homepage
for
ACP.
This
is
you
know.
Dns
is
hard
for
outsiders
to
understand,
and
this
was
one
of
the
reasons
we
did
this
and
if
it's
not
fulfilling
that
you
all
here,
you
know
are
on
the
bleeding
edge.
So.
G
We
talked
about
revalidation
briefly
was
the
conclusion
there
that
we
would
save
virtually
nothing
about
revalidation,
because
I
think
there's
some
interesting
things.
We
could
do
with
things
like
stairwell
revalidate
and
those
sorts
of
things
in
this
in
this
space.
That
would
be
really
interesting.
Yeah.
H
I
think
we
can
express
much
that
sort
of
explore
the
space.
I,
don't
know,
there's
anything
normative.
We
want
to
say
you
know
in
terms
of
how
you
use
this
I
think
this
is
gonna,
be
one
of
those
PCP
things
where
the
draft
as
it
is
discourages
revalidation
probably
shouldn't
do
that
HTTP
is
what
it
is,
and
three
or
four
is
what
it
is,
and
you
know
if
modified
is
what
it
is,
and
you
know
so.
H
We
really
shouldn't
say
anything
strong
about
that,
but
you
know
exploring
the
interactions
between
stay,
awhile,
revalidate
and
exploring
the
interactions
around.
You
know
what
does
a
three
or
four
really
buy
you
in
terms
of
light
byte,
guys,
sighs
versus
the
actual
DNS
thing,
and
all
that
I
think
that's
worth
spending
some
text
on
yeah.
So.
P
H
I
B
I
H
I
I
Yeah
so
I
just
want
to
point
out
visually.
One
of
the
two
co-chairs
of
DNS
opt
is
sitting
here,
wincing
and
possibly
crying
almost.
I
digital
visitor
I
right
from
the
future
of
the
sandstorm,
that's
coming
towards
us,
so
no,
we
haven't
done
it
if
the
DNS
off
working
group
gets
ahead
of
us
on
this.
It
would
be
part
of
this,
and
but
no
again,
let's
not
let's
not
try
to
change
the
way.
Dns
is
working
just
for
this.
This.
G
I
D
E
E
F
F
I
Are
there
other
issues
about
what
we've
done?
You
know
the
protocol
draft
at
this
point,
since
there
is
the
other
ones.
Are
there
I
mean
we
just
opened
up
cans
of
worms,
but
are
there
other
things
that
people
who
have
been
reading?
The
draft
are
current.
You
know
like
want
to
bring
up
right
now,
because
I
think
there's
plenty
more
to
be
discussed
in
the
second
half
I
think
you're,
free
and
I'll
follow
you.
E
Q
So
right,
ballast
I
see
if
this
is
to
be
implemented,
using,
for
example,
a
front-end
HTTP
proxy,
which
is
then
talking
wire
format
to
a
downstream
server
I.
Have
a
draft
in
DNS
up
called
draft
belliston
is
up
xpf,
which
is
for
carrying
the
original
clients,
transport
information,
for
example,
their
IP
address
ports
and
so
forth
to
the
back-end
server.
This
just
appeals
get
more
review
of
that
draft.
Q
F
So
this
is
a
follow
up
to
the
email
discussion
we've
had
on
list.
There
were
basically
three
issues
that
I
raised
on
the
list.
The
first
was
that
had
to
do
with
split
DNS
and
how
this
work
with
split
DNS
as
an
operational
issue.
The
second
had
to
do
with
global
server
load,
balancing
the
third
had
to
do
with
device,
acuity
appliances
and
tools
that
actually
use
DNS
and
enterprises
relating
to
trying
to
prevent,
prevent
malware
or
detect
malware
in
discussions
on
the
list.
F
What
I
think
we
we
found
at
least
some
common
ground
on
one
of
those
issues
think
mark
had
a
suggestion,
at
least
to
point
out
in
terms
of
how
we
deal
with
global
server
load
balances,
little
server
load
balancers
in
just
private
conversations
with
some
of
the
people
around.
It
seems
like
there's
an
easy
way
around
addressing
split
DNS
in
terms
of
at
the
bare
minimum,
a
configuration
point
in
terms
of
understanding
what's
local
versus.
F
What's
not
so
you
know
when
you
don't
meet
when
you
can't
really
use
like
a
DOS
server
that
is
outside
some
proxy
boundary,
for
instance,
and
the
third
issue
around
cyber
security
and
doing
scans
of
the
DNS
packets
looking
for
packets,
I
think
I'm
looking
for
malware,
I
think
that
one
sort
of
remains
open,
but
the
one
suggestion
I
think
I
saw
on
the
list
was
well.
We
just
don't
use
it
if
this
is
the
thing
that
you
are
worried
about.
My
point
in
all
of
this
is
I.
F
Think
probably
there's
you
know
if
those
are
the
three
issues
that
anybody
could
think
of
around
this
I.
Think
there's,
probably
just
you
know
a
paragraph
or
two
at
most-
that
we
could
probably
add
into
the
draft
and
I
just
suggest
a
that:
I
create
a
pull
request
and
people
can
review
it
and
then
just
saw
whether
they
really
feel
the
need
for
a
you
know
for
somebody
to
publish
a
large
internet
draft
for
a
one-paragraph
issue.
So
that's
that's
what
I
want
to
mention.
F
If
they're,
you
know,
I
meant
to
mention
these
things
as
issues
that
they
can
be
resolved
in
various
different
ways.
You
know
some
of
them
are,
you
know,
as
simple
as
you
know
was
suggested,
which
is
you
know,
have
a
manual
configuration
people
can
explore
things
like
proxy
packs
or
not.
That
was
not
meant,
I,
don't
feel
the
need
like
we
have
to
solution
engineer.
F
Absolutely
everything
here
for
this,
but
just
to
you
know
mention
the
issue
and
even
if
we,
if
we
have
one
simple
approach
to
get
around
something,
and
then
that
should
be
enough
from
an
operational
consideration
standpoint,
and
if
people
want
to
get
further,
you
know
more
elaborate
about
it.
That's
fine,
too,
but
we
don't
have
to
not
all.
F
To
go
into
a
draft
I,
the
draft
is
relatively
compact,
it's
relatively
well
written,
and
rather
not
you
know,
you
know
disturb
that
with
lots
of
operational
stuff,
but
if
we
can
keep
it,
if
we
can
keep
a
paragraph
or
two
small,
you
know
to
address
these
things.
It's
not
uncommon
to
have
in
our
RFC's.
You
know
some
operational
consideration
discussion.
If
it's,
if
it's
compact,
if
it's
a
whole
model
or
a
whole
new
deployment
approach,
then
then
yeah
you
fork
that
off
into
an
internet
route,
so
I'll
stop
there
Patrick.
H
Don't
have
to
be
asked
twice
to
hug
the
microphone
sure
I
mean
I.
Think
most
of
the
considerations
brought
up
are
probably
similar
things
to
what
you
know
deprive
how
to
consider
it.
I
mean
most
of
these.
Things
are
a
matter
of
if
your
recursive
resolver
is
different
than
your
default
recursive
resolver.
What
happens
right
and
I
was
just
actually
trying
to
call
up
the
deprive
draft
and
say
what
did
they
do
and
I'm
sure
I
would
say.
F
I'm
just
gonna
say
you
know
just
on
that
point,
I'm
perfectly
happy
to
negotiate
with
you
between
two
or
three
sentences
and
a
paragraph
and
so
as
kind
of
half
a
hat
as
co-chair.
I
know
that
one
of
my
own
personal
concerns
from
the
DNS
world
perspective
has
been
the
greater
ecosystem
in
which
this
gets
used.
But
I
see
that
as
a
separate
document
from
just
how
can
we
describe
the
protocol
and
what
the
protocol
should
be
doing?
F
P
Hello,
hello.
Oh
sorry,
this
is
stephen
from
rockton
I'm
totally
new
here.
So
please
correct
me.
If
I'm
wrong
anywhere,
so
I
was
trying
to
to
think
that
there's
basic
based
on
the
security
implementation
of
DNS
over
HTTP,
the
underlying
protocol,
HTTP
I,
mean
relies
on
PKI.
Basically,
in
that
sense,
when
we
want
to
validate
where
the
certificate
is
valued,
so
we
basically
have
to
put
the
trust
on
a
certificate
that
the
HTTP
server
presented
in
this
situation.
P
Now
most
of
the
CAS
most
of
the
commercial
ca's,
basically
rely
on
HTTP
or
something
similar
to
basically
publish
the
CRL
or
os
using
using
OCSP
in
a
situation.
So
basically,
we
now
have
a
circular
dependency
here,
because
unless
we
are
saying,
okay,
we're
not
totally
replacing
dns
we're
just
basically
using
it
as
an
addition.
Otherwise
we
have
a
circle,
a
dependency
here
in
size.
You
need
dns
to
resolve
those
names
in
order
to
be
to
pin
on
that
trust,
but
now
there's
no
mechanism
for
you
to
validate
whether
that
underlying
dns
is
well.
P
Of
course
you
could
use
DNS
SEC
or
you
could
potentially
define
a
special
CA
that
uses
IP
address
yeah
or
you
staple
it
in
some
way.
But
but
then
how
exactly
I
mean
do
we
are
actually
looking
at
solving
this
issue
or
is
there
any
other
ways,
because
if
we
staple
it
I
mean,
and
then
we
go
back
to
whether
there's
a
new
certificate
is
true
for
the
same
thing
and
the
client
would
have
to
be
updated
in
some
sense,
so
yeah.
G
So
Mountain
Thomson
I
think
there's
a
there's.
A
really
easy
answer
this
and
the
Patrick
just
said.
Ocsp
stapling
means
that
you
don't
have
to
go
to
another
server
to
get
the
answer
that
you
need,
and
so,
if
we
I
it
might
actually
make
sense
for
us
in
this
group
to
even
mandate
the
use
of
OCSP
stamp
stapling
in
this
particular
context,
simply
to
avoid
that
that
circular
dependency.
G
U
That
roach
had
off
one
of
the
things
that
I
wanted
to
point
out
about.
The
operational
considerations
that
have
been
brought
up
is
that
some
of
these
are
likely
to
have
proposed
mitigations
that
actually
bear
on
the
implementations.
So,
for
example,
if
you
were
to
have
a
recommendation
that
informations
have
exceptions
for
local
domains
in
some
way,
putting
that
off
into
a
separate
document,
I
suspect,
would
probably
not
get
it
read
by
most
implementations.
U
So
I
have
some
sympathy
for
the
prospect
that
at
least
some
aspect
of
this
is
likely
to
be
useful
in
the
protocol
document
itself.
So
what
I,
but
I
think
I'd
like
to
see
is
like
putting
together
some
text
about
what
this
is.
You
know
what
these
considerations
will
look
like
and
determining
whether
we
need
them
or
some
of
them
in
the
protocol
document
before
we
sort
of
you
know,
rule
them
in
or
out
of
scope
sight
unseen.
B
J
F
F
F
So
there
are
a
number
of
questions
about.
You
know
the
data
authorization
model
right
that
the
integrity
of
the
DNS
and
and
different
aspects
of
are
we
like
right
now
we're
essentially
defining
a
protocol
that
could
be
the
norm
for
now,
h-e-b
servers
to
push
down
all
kinds
of
DNS
data
into
a
client
and
say
oh
hi,
even
though
I'm
example.com
server,
I'm
gonna
tell
you
about
ad
server
comm
and
we're
not
defining
anything
right
now
about
you
know,
pulling
in
same
origin
model
or
whatever
else.
F
F
That's
one
thing,
but
if
the
the
possibility
that
this
is
a
mechanism
that
is
going
to
be
used
to
introduce
DNS
data
to
a
client,
I
want
to
see
that
area
fully
explored
about
what
all
those
implications
are,
especially
with
regard
to
the
way
the
current
DNS
operators
work
and
the
expectations
they
have
of
how
their
data
is
getting
used.
Sure.
J
So
I
have
all
I've
only
aware
of
one
use
case
primarily
for
this
to
start
with,
which
is
user
configures
manually
somehow
just
like
they
can
configure
an
alternative
resolver,
they
configure
a
dos
server
in
their
software
or
their
OS,
probably
in
their
software.
To
start,
if
it's
gonna
be
something
that's
you
know,
another
was
a
big
discussion
in
chartering
about
javascript
something's,
somehow
having
some
secret
mechanism
to
do
this
I
think
that's
a
red
herring,
because
that
would
have
to
go
through
the
w3c
and
be
specified
as
an
API.
J
F
F
J
E
U
G
However,
I
would
caution
that
taking
on
the
people
who
want
to
look
at
what's
in
the
packets
question
is
going
to
blow
it
up
more
than
we
we
already
have,
and
so
we
should
probably
avoid
that
one.
The
second
one
was
the
the
concerns
about
configuration
or
random
servers
on
the
internet.
Sending
me
DNS
responses,
which
sounds
kind
of
scary.
G
This
is
a
fear
that
is
grounded
in
some
reality,
at
least
in
that
I
now
have
a
client
that
is
going
off
and
talking
to
servers
using
the
protocol
that
they
can
use
to
make
those
things
appear
right.
So
we
need
to
be
a
little
bit
careful
on
this
front.
So
I've
got
a
web
browser,
I
go
to
a
site,
and
it
sends
me
it
pushes
me
the
the
dot
well-known
with
a
request
for
some
something
request
in
it,
and
it
provides
a
what
appears
to
be
a
legitimate
response.
G
What
am
I
to
do
with
that?
Well,
obviously,
you
just
don't
do
anything
with
it,
but
there's
questions
here
about
how
that
how
people
are
expect
how
people
are
approaching
this
particular
situation
now,
obviously,
if
you've
configured
a
particular
server
as
your
DNS
API
server
you're,
not
gonna,
have
that
response.
That's
come
from
some
random
server
somehow
appear
in
the
cache.
G
Save
you
the
time
and
that's
the
sort
of
thing
that
I
want
to
make
sure
we're
really
crisp
about,
because
if
we're
not
crisp
about
it,
people
will
do
those
sorts
of
things
and
I'm
sure
many
minds
were
blown
in
the
process
of
thinking
about
that
and
trying
to
work
out
the
ramifications
I'd
rather
not
go,
go
there
just
just
yet,
maybe
eventually
not
right.
Now,.
M
M
M
This
should
be
on
a
webpage
somewhere,
I,
don't
really
care,
but
I
do
think
that
we'd
better
work,
some
of
those
things
out
in
in
detail
pretty
promptly
or
we're
going
to
continue
to
to
founder
on
this.
This
example,
for
instance,
of
of
data
showing
up
kind
of
randomly
at
a
client
from
some
DNS
things
somewhere
and
it
being
accepted.
Maybe
sounds
really
weird
if
you're
familiar
with
HTTP,
but
if
you're
familiar
with
the
history
of
the
DNS.
M
That's
not
weird
at
all:
it's
all
the
time
we
call
it
poison,
so
I
think
that
that's
something
that
we
want
to
work
out
in
in
a
certain
amount
of
detail
and
and
again
I
think
the
mechanics
of
what
document
this
goes
into
and
so
on.
We
should
put
that
off
until
we
sort
of
work
out
some
some
concrete
things.
Thanks.
H
B
H
With
other
operational
considerations,
I
had
thought
during
chartering,
we
were
pretty
close,
pretty
clear
on
the
resolution
of
like
what
this
would
cover
and
what
wouldn't
cover.
Clearly
the
case
for
recursive
resolver
is
the
primary
use
case,
we're
all
on
board.
With
that.
This
question
of
you
know
JavaScript
and
the
thing
about
the
w3c,
where
you
don't
really
need
the
w3c.
If
you're
just
going
to
directly,
you
know,
use
the
HTTP
methods
specified
in
here.
H
You
can
just
do
it
out
of
fetch
or
a
xhr,
but,
as
martin
said,
you
don't
have
to
worry
about
those
answers
ending
up
anywhere,
whether
it
be
mistaken
as
IP
addresses
by
other
parts
of
the
system.
Javascript
is
just
not
have
those
kinds
of
privileges.
I
would
not
worry
about
it.
We
can
write
a
sentence
that
says
that,
but
I
would
not
worry
about
it
and
then
the
third,
an
interesting
case,
that's
always
lurking
over
everyone-
is
what
happens
if
this
website
pushes
me
these
unrelated
addresses
right.
H
In
my
view,
that
is
clearly
not
something
that
doe
directly
enables.
It
would
be.
You
know
a
spike
of
IOB,
an
HTTP
spec
violation,
because
HTTP
defines
how
you
decide
where
you
get
your
information
from
an
origin
on,
and
that
is
generally
through
DNS.
We've
recently
added
an
extension
proving
that
we
really
do
define
this
called
origin
frame,
which
is
a
slight
twist
on
that
matter,
and
you
could
conceive
of
the
group
Marx.
Look
at
me
like
he
doesn't
think.
Origin
frame
is
a
twist
on
the
DNS,
which
is
interesting.
H
Okay
and
you
could
conceive
of
you-
know,
dough,
given
information
becoming
something
else
that
that
HTTP
group
would
want
to
consider
for
routing
information,
but
dough
does
not
enable
that
by
itself
that
would
be
an
HTP
decision.
It's
not
been
made,
you
know,
there's,
obviously
a
ton
of
stuff
to
consider
in
making
it
so
I
would
want
to
make
sure
we
didn't
write
logic.
That
said,
you
know
this
could
never
be
done,
but
we
can
certainly
say
this
does
not
enable
it
I
hope.
That's
clear,
yeah.
E
F
Would
also
I
would
like
to
point
out
that,
when
we
had
the
Boff
and
soul
and
the
85
people
showed
up
for
the
room
for
24
and
as
you
observed,
there
was
a
lot
of
different
impressions
about
what
DNS
over
HTTP
would
mean,
and
what
that
implied,
and
so
I
do
think
that
clarity
around
that
saying.
No,
this
is
not
supposed
to
be
a
mechanism
to
poison.
Your
cache
is
useful
to
pursue.
F
V
Well,
probably,
if
you're
going
to
do
that,
it
would
have
to
be
DNS
SEC,
because
otherwise
it
is
poisoning
your
DNS
cache,
but
the
the
origin
extension
DHCP
to
also
means
that
we
rely
less
on
DNS.
For
that,
and
so
the
use
case
where
we
wanted
to
push
DNS
records
has
largely
going
away
if
you
implement
origin.
V
W
Erik
coin
I
wanted
to
ask
an
implementation
question
sort
of
that
maybe
too
early
and
also
will,
of
course,
betray
my
deep
and
abiding
ignorance,
we're
late
last
night
and
some
conversations
about
Dino's
over
TLS
and
DNS
over
TCP
sort
of
things.
The
question
of
pipelining
many
queries
to
a
server
yielded
a
result.
We're
like
what
happens
when
the
server
sort
of
has
too
many
of
your
queries
right
and
in
in
HTTP.
We
have
429
and
too
many
queries,
but
I
don't
know
what
we
really
do
in
DES.
W
G
Yeah
Simon
Thompson
HTTP
2,
actually
has
a
bunch
of
mechanisms
in
it
to
sort
of
protect
against
these
this
class
of
attack.
It
limits
the
number
of
concurrent
requests
that
you
can
make.
It
provides
very
specific
control
over
things
like
buffers
and
or
compression
State,
and
all
of
the
things
that
a
server
might
have
to
exhaust
in
in
the
process
of
actually
dealing
with
all
those
requests.
So
I
think
that
here
we
have
a
reasonably
good
story.
G
If
we
go
with
the
the
endorsed
version
of
the
protocol
and
I
think
other
than
that
were
still
in
the
Wild
West
yeah
HTTP
1
1,
we
probably
want
to
go
back
to
the
rules
in
HTTP
1
1
about
the
number
of
connections,
because
that's
really
going
to
limit
the
number
of
requests
you
can
have
concurrently
and
I
mean
the
actual
number
varies,
but
it's
616
to
pick
a
number.
It's
not
really
specified,
but
it
there's
this
text
about
it.
Man
and
anyone
who
creates
a
thousand
connections
to
a
server
gets
what
they
deserve.
X
Other
ones
a
clue
di
I
have
to
say
I,
don't
think
other
people
be
confused,
I,
don't
I,
don't
know
enough
to
say
that,
but
I
do
know
that
I'm
confused,
because
this
text
is
what
like
I
don't
understand.
For
example,
you
know
if
I'm
the
web
server,
for
example,
calm
and
I've.
Certified
myself
as
such
you
know,
can
I
update
the
quad
a
record
for
example.com?
Yes,
no,
no,
okay!
So
where
does
it
say
that
I
see?
And
where
does
it
say
here
that
that
work
is
out
of
scope?
I
Hoffmann,
it's
not
that
it's
out
of
scope;
it
doesn't
work
in
HTTP,
you're,
going
cross-origin
and
such
if
you
haven't
asked
for
it.
You
just
don't
get
it
then
that's!
We
might
need
to
clarify
that
a
bit
more!
It's
not
that
it's
out
of
scope
that
we
don't
want
you
to
do
it
you,
that's
just
not
what
we're
doing.
X
I
Like
today
that
to
discover
recursive
resolvers
that
you
want
to
use
it's
not
just
that.
Oh
look!
Here's
a
recursive
resolver
in
the
same
way
in
the
DNS
right
now,
there's
lots
of
open
recursive
resolvers.
But
if
somebody
was
if
a
DNS
stub
resolver
said,
oh
look.
Here's
an
open,
recurse,
er,
I'm,
gonna
start
using
it
now,
which
is
you
know,
a
completely
insane
thing
to
do.
They
could
probably
view
that
here
and
we're
not
endorsing
it,
but
we
can't
prevent
somebody
from
doing
and
saying
things
saying:
look
I've.
I
X
F
Explodes
I
think
you
should
yeah
can
I
make
a
suggestion.
No,
let's
have
this
discussion
when
there's
actually
a
proposal
of
some
text
in
front
of
us,
because
right
now
we're
having
the
Charter
discussion,
we're
already
charted
and
we
actually
have
some
issues
to
close.
That
on
the
existing
text
is
that
okay,
yeah.
F
So
I
just
had
a
logistical
question
regarding
the
the
three
ones
that
I
mentioned
and
and
and
I
think
Andrew
had
a
point
which
about
you
know,
maybe
developing
out
the
the
use
cases
for
sorry,
the
and
Reata
suggestion
about
developing
out
use
cases
and
having
and
having
text
around.
You
know
these
use
cases.
F
E
Y
As
soon
as
this
protocol
gets
traction,
so
things
like
extended
response
codes,
yeah
that
we
are
discussing
in
DNS
up
right
now,
I
mean
it
is
essentially
an
eating,
a
zero
option,
but
it
has
a
couple
of
implications
that
go
actually
beyond
beyond
poor
proxying
of
the
DNS
contents,
so
I
suppose
from
that
direction.
We're
gonna
see
like
a
couple
of
copies
of
things
that
go
on
and
the
NS
up.
I
So
Paul
Hoffman,
responding
to
that.
It
is
our
belief
currently
that
it
is
wire
format.
So
anything
that
comes
goes.
The
N,
the
receiver
of
the
wire
format,
should
be
acting
like
a
stub
resolver,
possibly
a
newish
stub
resolver,
with
things
like
that.
If
you
see
things
that
tickle
that
please
send
them
to
the
list,
I
think
that
there
might
be
a
short
list.
I
hope
the
list
is
zero
length.
I
So
so.
But
that
means
just
like
you're
saying
that
stale
response
we
have
a
bunch
of
things
sort
of
in
flight,
indiana
saab,
but
those
all
expect
the
receiver
to
do
something
different
and
the
receiver
of
this
data
would
do
something
different
we're
not
expecting
the
server.
You
know
the
one
who's
who's,
encapsulating
the
water
format
and
pushing
it
down
to
do
anything
different,
including
on
the
TTL
stuff
that
and
that
comes
up
in
the
same
way.
M
Hi,
I'm
andrew
sullivan,
coming
back
to
the
question
from
the
chairs
about
drafts.
I'm
not
here,
to
volunteer
to
write
a
draft
because
I
I
feel
like
it
may
be
premature.
I
think
what
I
was
trying
to
suggest
earlier
was
that
maybe
what
we
need
are
a
bunch
of
threads
on
the
on
the
mailing
list.
First,
to
sort
of
figure
out:
look:
are
there
things
here
that
that
that
could
coalesce
into
something
that
could
be
a
draft
at
the
moment?
I
think
you
know.
M
If
we
try
to
write
this
down,
it's
just
gonna
be
incoherent
and,
and
we've
got
too
many
things
to
work
out.
It
was
very
obvious
from
this
discussion
today
that
there's
a
whole
bunch
of
things
that
are
big
gaps
and
if
we
could,
if
we
could
narrow
this
down
a
little
bit
in
discussion
on
the
list
or
an
interim
or
anything
like
that,
I
think
that
would
be
more
useful
than
then
trying
to
write
a
draft
that
is
just
full
of
holes.
So
I.
F
Just
want
to
agree
that
I,
don't
think
it
should
be
inferred
that
if,
at
the
end
of
this
session,
we
have
nobody
saying,
oh,
let's
do
another
draft.
That
doesn't
mean
that
the
working
group
has
concluded
just
one.
The
one
draft
is
complete:
it
we're
still
exploring
the
area
and
we're
not
likely
to
come
to
conclusions
about
it
in
this
session.
J
Mark
Nottingham,
could
you
scroll
all
the
way
to
the
bottom?
Well,
one
of
the
real
charms
of
this
charter
when
it
went
around
was
the
very
short
timeline
and
I
think
that
sold
this
working
group
to
a
lot
of
people.
I
would
suggest
that
that
maybe
we
keep
the
document
list
very
short
as
short
and
close
to
one
as
possible.
J
Having
said
that,
from
what
I'm
hearing
here,
I'm,
not
certainly
not
volunteering,
although
I
can
put
some
effort
in
it,
might
be
helpful
if
there
were
a
throw
away,
ID
or
a
wiki
page
or
something
describing
what
people
think
the
use
case
for
this
protocol
is
I
know
we've
kind
of
avoided.
That
till
now,
because
we
have
a
lot
of
different
document,
I.