►
From YouTube: IETF99-DNSOP-20170720-1810
Description
DNSOP meeting session at IETF99
2017/07/20 1810
https://datatracker.ietf.org/meeting/99/proceedings/
A
C
D
B
D
D
B
B
B
Yeah,
the
blue
sheets
are
out
there
in
the
wild,
though
quickly
where's
mr.
Laurence
raise
your
hand.
Mr.
Laurence,
oh
I
can
see
you
I
can't
see
mister
okay,
so
there's
a
gentleman
from
and
mr.
Edmunds
is
he?
Okay,
sorry
I
didn't
mean
to
scare
you,
but
there's
a
gentleman
from
time.
Jason.
Where
are
you?
I
talked
to
you
who
has
an
interesting
CD
and
Ian
has
problem
that
I
think
the
two
of
you.
He
would
like
to
pick
your
brains
a
little
bit
so
I
talked
to
him
and
I
said
I.
B
Think
you
need
to
find
the
smarter
people
and
those
are
the
youtubes,
so
I
apologize
for
that.
So
so
you
know
the
blue
sheets,
this
I
hope
so
quick,
Jenna
batching
it's
time
for
the
bad
idea
fairy
they
come.
You
know.
So,
if
you
remember
Andrew
slide
from
who
knows
where
so
wow
this.
This
is
really
kind
of
barred
me
out.
So
we
we
had
a
discussion.
I
know
talk
about
that
I
yeah,
this
the
end
of
the
day.
It's
my
brains
will
fry.
A
B
E
B
So,
rather
than
you
know,
HTTP
over
DNS
and
stuff,
like
that,
here's
our
agenda
war
West's
got
a
little
talk
about
multi
responses
and
multi
cue
sites.
We
talked
about
this
and
we
spent
a
lot
of
time
trying
to
member
what
what
meaning
that
was.
If
that
was
Berlin
last
year
or
Argentina
and
I'm
so
kind
of
confused
Peter
is
gonna
speak
about
xpf
for
Ray.
Is
that
correct?
Yep
I
have
to
tell
your
boss
II
get
a
gold
star.
Warren's
got
extended
error,
there's
client,
ID,
DNS
capabilities.
B
Roberts
got
one
slide
that
I
made
for
him
I'm
first
going
to
make
DNS
SEC
validate
requirements
and
actually
the
algorithm
one
humans
at
the
bottom
of
this,
and
for
some
reason
it's
hurting
me.
So
what
we're
looking
for
is
basically
in
these
discussions,
kinda
think
of
as
lightning
talks
right.
Are
they
worth
adopting?
Do
they
need
work?
Are
they
like
no
way
go
away?
Kind
of
thing
we're
not
looking
for
large
architectural
boundaries,
you
the
mic,
but
just
like
yes,
like
needs
more
work
support.
B
You
know
whatever
that
kind
of
stuff,
because
you
know
and
that
stuff
you
know
we
can
throw
it
through
the
mailing
lists,
but
we
just
want
to
get
that
sense
of.
Should
we
start,
you
know
here's
our
pile
of
stuff
that
we're
looking
about
you
know
moving
forward.
People
of
air
seem
interested
in.
Where
are
we
going
with
it
right?
So
that's!
Basically,
it
I
got
some
slides
from
warned
about
the
TLS
usage
I'll,
throw
them
up
right
now
and
then
it'll
be
on
to
Mister
harder
core
sort
of
thing.
So
thanks.
B
Yep
so
Warren,
you
said:
one
client
went
a
little
crazy,
looks
a
little
I'm
Warren's,
hiding
that's
okay!
Oh
that's!
The
spike
that
you
were
talking
is
that
the
spike
you're
talking
about
yeah
yeah,
a
pre
pictures
where
we'll
upload
them
just
sort
of
showing
the
TLS
or
usage,
the
DNS
usage
and
then
Tillis
usage
and
yep
and
we're
gonna
let
warrants
because
he
is
the
ad
and
he
asked.
C
You
know
there
be
any
grass
that
shows
stuff
what
I
actually
wanted
to
say
is
we
have
an
open
errata
on
eight
zero,
seven,
eight,
which
I'm
not
completely
sure
the
conversation
ever
converged,
people
wouldn't
mind
having
another
look
and
commenting
to
me,
it
looks
like
there
are
two
should
be
accepted,
but
a
little
bit
more
feedback
would
be
good.
That's
all!
Okay,
Wesley.
F
F
Technology
these
days,
it's
ruining
all
my
jokes
darning
all
right,
so
both
this
one
and
if
I
could
go
back
to
the
title
page,
the
queue
type
document
and
the
multiple
responses
document
they're
both
solving
two
different
problems.
So
is
there
a
bellows
in
the
room,
no
okay
and
unfortunately,
because
he
helped
off
with
these
slides
and
he
doesn't
know
it
all
right,
so
it's
actually
painfully
breaking
us.
F
Isn't
it
all
right
so
back
in
the
good
old
days
in
like
the
early
1900s
plants
would
like
use
anything
that
you
sent
Adam
and
that
included
anything
in
the
additional
section.
So
they
would
take
it
as
a
good
leap
of
faith.
They
said
you
know
the
Internet
in
the
early
days
was
all
trustworthy
and
nobody
bad
existed
so
yeah.
Next,
then,
along
came
the
dark
and
dreary
Middle
Ages,
where
cache
poisoning
plague
to
the
land
and
the
additional
section
all
the
code
was
rewritten
so
that
the
additional
section
was
like
just
dropped.
F
If
it
wasn't
useful,
if
it
wasn't
in
zone
even
if
it
was
in
zone
but
not
what
you
were
expecting,
it
was
tossed
out
next
enter
DNS
SEC.
It's
a
new
era
and,
and
everything
can
be
happy-go-lucky
again,
because
we
can
actually
validate
that
those
records
are
valid
and
it's
not
even
just
DNS
sex.
So
some
more
recent
code
bases,
including
according
to
mark
you
know,
more
recent
versions
of
bind
actually
will
accept
some
records
as
long
as
they're
related.
F
So
if
you
know,
if
you
had
a
if
you
have
for
MMX,
and
it
gave
you
back
an
a
record
for
the
MX,
you
know
it
was
all
happydunk
E
and
that's
about
what
you
were
going
to
ask
for
anyway,
but
that's
not
the
you
know
that
doesn't
always
happen.
So
these
two
documents
kind
of
fix
that
problem
next.
So
two
things
there's
two
different
problem:
cases,
which
is
the
thing
I
want
you
to
take
away
from
today.
Two
problems,
not
one
or
two
optimizations.
Some
is
when
you
have
a
smart
client.
F
The
client
actually
knows
ahead
of
time.
It
needs
more
information.
It
might
need
to
look
up
both
an
A
and
a
quad,
a
the
quintessential
example.
It
might
need
to
look
up
if
it's
going
to
send
you
mail,
it's
not
just
going
to
send
you
mail
and
ask
for
the
MX
record.
It's
also
going
to
ask
for
your
NS
record
if
it
hasn't
been
there
before.
So
it's
probably
going
to
ask
for
both
write,
multiple
cue
types.
That
document
is
what
lets
you
do.
F
G
F
So
the
other
possibility
is
that
the
client
actually
has
no
clue
what
to
ask
for
it's
starting
a
whole
chain
of
stuff,
and
it's
gonna
ask
some
question.
First
and
then
that's
gonna
follow
on
and
you
know
it's
gonna
come
back
later
and
ask
more
questions.
It
could
be
because
there's
application,
specific
knowledge
and
there's
no
way
in
the
world
that
DNS
protocol
knows
it
ahead
of
time.
It's
not
possible.
So
this
is
the
multiple
responses
draft,
which
is
this
so
when
I
say
our
draft
I
should
have
changed
that
to
multiple
responses.
F
I
originally
wrote
this
from
a
single
point
of
context,
so
this
is
when
the
server
has
a
better
idea
than
you
do
of
what
you
might
need.
So,
for
example,
if
you
go
to
WWE
my
comm
there's
a
decent
chance,
you're
gonna
come
back
and
look
up
images,
comm
and
JavaScript
comm,
and
you
know
who
knows
what,
especially
if
you're
doing
you
know
lots
of
round-robin
mixing
with
names.
F
F
So
if
we
compare
these
two
different
drafts,
there
they're
actually
solving
completely
different
use
cases.
So
you
know,
in
both
cases
the
client
indicates
desire,
there's
a
bit
in
the
idea
of
zero
field,
there's
in
both
drafters
away
for
the
client
to
say,
I
want
this,
you
don't
just
get
it
for
free
automatically.
F
In
the
multiple
responses
case,
the
client
doesn't
request
specifics.
The
client
actually
just
says
I'm
clueless.
Please
help
me
out
and
give
me
additional
information
if
you
can
and
in
the
queue
types
draft,
the
client
actually
says,
I
want
as
much
information
for
this
name
as
you
can
or
I
want
these
few
types
in
for
the
server
selects
the
specific.
In
the
multiple
responses
case.
Again,
that's
the
opposite.
Where
the
server
is
saying
you
know,
you
asked
for
this
extra
stuff
I'm
going
to
give
you
a
bunch
of
stuff
all
within
zone.
F
Both
of
them
support
multiple
queue
types.
They
can
both
return.
Multiple
queue
types
for
an
answer
in
additional
multiple
responses,
because
it's
you
know
a
little
bit
more
on
the
intelligent
site
from
the
server
can
also
give
you
different
names
back
that
you
didn't
even
ask
for,
and
that's
not
possible
with
queue
types,
because
that's
out
of
scope
of
that
work,
they
both
use
eating
us
arrow
to
signal
support
so
that
ruins
the
joke
to
stop
I'm.
Sorry,
that's
okay!
Go
to
the
next
one
and
then
make
the
cursor
go
away.
We.
F
So
the
important
thing
to
note
is
that
the
happy
eyeballs
that
you
see
down
at
the
bottom-
these
are
both
optimizations
right.
These
are
both
happy
eyeball
type
problems.
You
know:
does
the
world
work
without
them?
Yes,
they
are
optimization
mostly
to
do
happy,
eyeballs
type
stuff
on
both
both
proposals.
Next
last
one
all
right,
so
that's
an
overview
of
what
they
both
are
note
that
I
didn't
go
into
the
gory
details
right.
This
is
this
is
about
the
concept
of
solving
the
problem,
and
you
know
these.
How
many
people
have
read
the
multiple
responses?
F
Draft
excellent?
How
many
people
have
read
the
multiple
cute
cute
type
draft,
excellent,
all
right,
so
there's
a
lot
of
basis
for
understanding
for
these
now.
The
question
is:
what
do
we
want
to
do
with
them
as
the
working,
but
I
will
turn
that
you
want
do
this?
Aren't
you
a
quick
comment
whether
or
not
either
one
should
be.
H
H
E
I
J
I
I
both
have
two
things,
I
mean.
Have
we
ever
seen
that
there
was
really
stuff
on
clients
that
do
done
that
kind
of
do
new
stuff
like
how
many
do
bc?
One
of
the
things
we
see
will
of
these
ideas
is
we
have
no
data
and
there's
a
lot
of
caching
and
browsers
they
a
lot
of
cash,
giving
it
resolvers
I
mean.
Is
this
really
a
problem
because
I.
F
Don't
think
so?
Well,
so
that's
what
I!
That's
what
I'm,
what
they're
happy
eyeballs
existed
on
the
screen
right?
This
is
an
optimization
not
in
the
same
way
that
that
all
of
the
that
the
entire
happy
eyeballs
RFC
is
not
a
problem
right.
It
was
just
to
make
clients
have
their.
Have
we
any
chance
to
really
have
that.
J
K
F
F
A
F
N
N
These
are
optimizations
that
part
I
agree
with,
but
actually
they
are
optimizations
that
change
a
bunch
of
the
architectural
assumptions
about
the
DMS.
Now,
maybe
we
should
do
that,
but
I
think
that
that
analysis
has
been
part
of
the
thing
that
has
been
missing
and-
and
maybe
we
need
to
have
a
focus
discussion
about
that,
because
both
of
these
things
right,
they
change
like
on
what
you
can
expect
from
caches
and
all
the
rest
of
it.
O
Paul
Bocuse
I
also
like
both,
and
we
already
have
a
use
case
for
the
unbound
IPSec
module
that
currently
sends
two
queries
in
parallel
and
would
be
awesome
if
it
we
won
great
I
would
also
maybe
these
to
record.
These
two
drafts
can
also
help
sort
of
simplify
your
more
standardized.
The
alias
or
a
name
proposes
that
fin
rod
so
that
we
have
less
special
processing
and
detect
used
each
generic
mechanisms.
F
These
are
the
two
active
documents
and
I
strongly
encourage
anybody
that
wants
to
write
a
solution
for
this
space
to
do
so
soon
yeah.
So
it's
Daniel
our
proxying
two
comments
from
the
jabber
room.
First
rave
Ellis
was
on
objecting
to
Oliver's
comment,
saying
we
had
this
discussion
in
Berlin
and
he
also
said.
Please
ask
Andrew
to
send
email
to
the
list
explaining
his
comment
and
then
the
second
one
is
from
I'm
gonna
mess
us
up,
but
mogandfrog
ramen
ramen
from
is
C
I'm.
Sorry,
if
I
slaughtered
your
name,
but
he
said
that.
F
He
prefers
smart
clients
to
smart
servers,
CDNs
clients,
sudden
that
only
works
on
stuff.
In
the
answer
section,
smart
servers
can
have
a
performance
impact.
Additional
internal
data
structure
queries
having
a
big
impact
on
performance
and
it's
better
if
the
client
requests
what
it
wants
in
the
server
provides
that
than
guessing
what
the
client
may
need
that
the
client
may
end
up,
throwing
away.
F
P
N
G
Q
My
pal
said
I
like
the
ideas
behind
both
of
these
drafts
and
I'm
sort
of
amazed
that
has
this
didn't
occur
to
me
before.
Maybe
other
people
thought
about
it,
I
didn't
think
about
it.
What
I
saw
both
the
the
feature
set
side
by
side
but
I'm
kind
of
curious?
Now,
if
there
isn't
a
way
to
do
both
of
these
things
in
a
single
change
rather
than
two
different
graphs,
I
did
so.
F
They're,
really
off
the
top
of
my
head.
Yeah
no
I
mean
that
I
think
that
was
one
of
the
things
that
was
confusing
in
Berlin
or
wherever
the
previous
discussion
was,
but
the
reality
is
is
that
there
are
two
very
different
cases.
One
is
who
has
the
knowledge,
and
in
one
case
it's.
The
client
in
one
case,
is
the
server
so
it'd
be
kind
of
hard
to
combine.
F
F
B
B
R
R
R
We
may
need
to
fix
this
if
we
go
to
publication,
so
it
makes
more
sense
so
to
provide
some
context
long
ago
was
not
a
long.
Long
ago,
DNS
looked
like
this.
Yes,
the
machines
at
home,
yet
a
router,
the
router
for
to
query
iiters
through
nets
or
as
a
simple
forwarder
to
a
resolver
resolver
spoke
to
an
authority.
If
you
got
an
answer
back
pretty
soon
see,
DNS
came
up
and
it
wasn't
enough.
So
we
added
18s
client
subnets,
which
allows
the
authoritative
to
see
at
least
part
of
the
client
IP
address.
R
Then
people
started
doing
even
more
complex
things,
putting
load
balancers
in
front
of
their
resolvers
or
today,
for
example,
a
DNS
or
a
TLS
on
wrapper.
This
means
the
resolver
no
longer
has
the
client
IP
address.
It
only
has
the
IP
of
the
load
balancer
or
the
TLS
on
beverage,
which
might
even
be
on
localhost.
So
this
is
where
xpf
comes
in
the
load.
Balancer
adds
a
meta
records
to
the
query
and
forces
2/4
forwards
it
to
the
resolver,
which
can
then
add
a
DNS
client.
Subject:
information
as
before.
R
Now
suppose
the
authority
also
has
a
load
balancer.
Suppose
a
query
comes
in
without
eating
as
client
subnets,
then
the
authoritative
would
still
want
to
know
the
IP
of
the
resolver
asking
questions
so
again.
Xpf
comes
in
here
to
clarify
these
are
the
boundaries
of
these
extra
messengers
for
extra
options.
Each
option
is
generated
on
the
leftmost
machine
in
a
box
and
it
is
removed
on
the
right
mouse
machine
in
a
box.
R
So
xpf
never
leaves
a
network,
it
might
might
not
even
leave
your
machine
while
it
has
client
subnet
will
most
definitely
leave
your
autonomous
system
and
go
from
the
access
provider
to
a
sea
and
to
clarify
David
Lawrence
is
going
to
present
a
client
ID
later.
This
is
the
box
of
client.
Id-
and
it's
add,
is
it-
is
added
on
the
home
CBE
and
travels
no
farther
than
the
resolver.
R
This
is
what
made
our
looks
like
the
previous
draft
version
made
the
Adina's
option,
but
we
realized
that
this
would
make
d
sick
very
hard.
So
now
that
it
is
a
separate
matter
are
in
the
additional
section,
it
is
very
easy
to
ignore,
while
generating
your
t,
sick
message
for
verification.
The
IP
version
is
a
four
or
a
six
like
in
an
IP
header
search
for
bits.
The
protocol
is
the
protocol
number
from
Diana
protocol
registry,
so
TCP
or
UDP.
R
I
did
just
realize
that
the
quake
is
not
in
there
yet
so
I
hope
it
will
be
one
day.
Then
you
have
the
source
address,
which
is
an
obvious
use
case
for
this,
but
also
a
destination
address
and
the
source
and
destination
ports.
This
allows
the
authoritative
or
resolver
that
is
behind
the
proxy
to
still
apply
fuse
or
ACLs,
etc.
The
source
port
is
in
there,
so
you
can
distinguish
different
clients
in
citynet
situations.
The
destination
port
is
in
there,
so
you
can
distinguish
plain
DNS
from
DNS
over
TLS,
for
example.
R
Next
steps
I'd
like
to
ask
for
adoption,
and
we
need
to
get
some
code
running
today.
Dns
lists
does
the
same
thing,
but
using
it
in
s,
client
subnets,
which
confuses
matters
if
EDS
clients
have
subnet,
is
also
actually
in
use
for
its
normal
purposes.
So
xpf
is
specifically
specifically
designed
to
be
able
to
coexist
with
it.
R
G
R
R
The
previous
version
was
an
adenine
zero
option,
but
if
there
is
a
t6
signature
over
the
query-
and
you
are
putting
another
option
in
the
option,
records
then
validating
the
signature
becomes
more
complex,
it's
more
pointer,
magic
or
whatever
you
like
to
call
it.
This
is
simpler.
In
general,
you
could
let
the
amps
in
general,
the
authoritative
or
result
we'll
find
it
at
the
end
and
just
remove
it,
and
then
the
TC
processing
there's
not
impossible
as
an
option,
but.
S
Can
I
start
by
correcting
you
on
one
thing
we
didn't
add:
client,
subnet
EDS
can't
something
it's
not
an
IETF
standard.
It
was
documented
as
informational
so
and
it's
an
example
of
I
think
kind
of
protocol
development
that
we
should
be
doing
differently
now
so
I
see
the
use
case
of
this.
Obviously,
but
I've
said
this
before
that.
I
think
this
violates
a
couple
of
principles
and
one
is:
it
makes
a
pervasive
monetary
easier
we're
supposed
to
be
mitigating
that
in
protocol
design
and
the
other
is
it
was
directly
injecting
metadata
into
these
queries.
S
R
S
Are
the
things
we
can
do
so
one
is
about
the
tone
of
the
draft
and
considerations.
The
other
thing
I'd
like
to
see
in
terms
of
protocol
is
that
for
that
this
explores
other
ways
to
do
this,
that
mitigate
the
monitoring
within
the
protocol.
So,
for
example,
this
is
supposed
to
be
between
trusted
proxies
service.
So
you
have
a
relationship
with
that
proxy.
So
it
would
be
nice
to
explore
how
to
do
this
by,
for
example,
encrypting
this
native
creature
keys,
as
opposed
just
assuming.
It's
gonna
go
clear
text
so.
S
S
C
Warren
Kumari
one
of
the
authors
of
the
e
DNS
client
subnet
document,
there's
some
text
and
there,
which
I
couldn't
find
quickly
scrolling
on
my
phone,
which
largely
said
if
we
had
been
designing
this
protocol
today,
we
probably
wouldn't
have
done
it
because
you
know:
we've
learned
more
about
privacy
and
stuff
like
that.
Yeah.
B
D
K
K
K
This
was
the
response
you
may
remember.
In
the
olden
days,
we
actually
used
to
return
a
referral
to
the
root,
and
that
was
determined
to
be
too
much
of
an
easy,
amplification
and
message
size
and
so
server
started
returning
refused,
but
that
overloaded,
the
other
existing
meanings
of
what
refused
was
supposed
to
be.
K
There
is
also
a
prohibited
response
specified
in
here
that,
for
some
reason,
if
this
is
the
other
meaning
that
were
refused
and
then
there's
a
question,
that
might
perhaps
be
a
bad
idea
that
it
a
too
busy
error
code
might
be
something
that
would
be
useful
to
signal
say
if
you
were
under
very
heavy
load
from
a
toss
or
something
then
so.
This
would
create
another
Ayana
registry
for
code
points,
but
at
the
moment
is
just
these
five
that
are
presented.
K
We
have
a
couple
of
feelers
out
to
people
to
find
out
what
other
codes
be
useful
straight
out
of
the
gate
and
that
invitation
extended
to
all
of
you.
If
you
have
an
idea
of
something
would
be
really
useful
in
this.
Please
go
ahead
and
send
to
the
list.
There
is
also
a
question
about
maybe
to
just
be
a
generic
one
of
the
things
that
this
signals
that
the
existing
DNS
protocol
does
not
signal
is
whether
you
should
retire
your
query
or
not,
for
example,
under
a
validation.
K
Failure
contacting
a
different
server,
probably
not
helpful
under
other
error
code
conditions.
It
might
in
fact
like
perhaps
you
serve
fail,
but
you
have
reason
to
believe,
because
you
didn't
have
a
data
file
you
expected
to
have,
but
you
you
know
your
secondary
might
have
that
information,
and
so
you
could
surveil
and
then
set
the
bit
that
says
you
know
what
this
is
probably
worth,
refining
this
query,
but
at
the
moment
there's
no
particular
way
like
all
of
the
retry
bits
are
attached
to
one
of
those
specific
error
codes
that
were
on
the
previous
slide.
K
There's
no
way
to
just
kind
of
generically
say
you
know
what
I
don't
have
an
answer
for
you,
but
retry,
and
there
were
additional
questions
about
whether
to
have
an
exclamatory
test
detects
that
would
explain
the
error
code
that
you
might
want
to.
Then
you
know
present
poke
upward
through
the
UI.
Somehow
it's
both
through
logging,
and
there
was
also
a
question
about
whether
this
is
currently
called
extended,
error
and
right
now
it's
only
used.
K
If
your
our
code
is
an
error,
our
code,
perhaps
it
should
be
extended
to
be
able
to
be
used
in
any
situation
and
there's
an
additional
question
that
right
now,
the
way
you
need
s
works
is
you're
only
suppose
ever
include
an
EVMs
option
in
a
reply.
If
it
was
received
in
the
query,
however,
by
the
original
specs
assay
you're
supposed
to
understand,
you
know
additional
records
and
if
you
don't
understand
a
particular
record,
an
additional
section
you
just
ignore
it.
K
There's
also
a
belief
that
you
could
maybe
push
an
e
DNS
option
back
in
a
reply,
even
if
you
didn't
get
it
in
the
original
query,
whether
that
should
be
pursued
as
a
separate.
You
know,
question
and
not
necessarily
miss
talk
is
something
else,
but
overall
we
are
interested
in
having
it
picked
up
as
working
group
document
and
move
forward
with
this
mechanism
for
providing
extended
information
about
errors
and
we're
doing
questions.
A
Concern
actually
before
we
start
with
comments
again,
because,
because
this
is
an
older
draft,
that's
just
recently
been
revived.
We
do
want
to
hear
real
quick
takes
on
it,
but
also
I
think
for
everybody
who's
in
the
mic
line.
We're
going
to
assume
that
you're
going
to
review
you're
committing
the
reviewing,
because
these
are
these-
these
questions
are
the
right
ones.
Do
I
need
to
be,
they
need
to
be
answered.
So
what
we're
really
looking
for
at
this
stage
is
review
and
I'm,
calling
on
her
secretary
to
take
down
take
down.
Oh.
K
A
A
M
Very
reasonable
point
Ola
from
book
David.
This
is
not
new.
People
have
wanted
something
like
this,
where
ever
and
ever
I
have
a
proposal
from
last
century,
but
I
just
put
in
the
jabber
room
yeah.
This
is
great.
We
should
talk
about
how
to
do
it,
and
sometimes
people
want
more
visibility
into
it
when
they
are
the
lender
versus
what
the
public
gets
right.
P
Jimmy,
what
all
of
us
say?
It's
I,
think
it's
a
great
idea,
there's
something
long
long
overdue
I've
got
one
or
two
concerns
and
just
a
couple
of
things
we
can
think
about
when
we
actually
do
to
like
in
this
document.
First
of
this,
maybe
we
won't
have
some
kind
of
like
they
could
point
allocation
policy
like
we
do
without
our
takes.
Maybe
some
expert
scrutiny
if
we
need
to
do
that,
we
should
also
be
very
very
careful
about
and,
of
course,
it
was
tons
in
this
proposed
format.
P
K
T
U
If
charg
and
as
one
I
definitely
support
his
draft
I
support,
adding
some
extra
information
about
about
a
failure,
I,
don't
like
like
having
her
coat
in,
had
her
eating
as
option
like
extended
error
code
and
some
other
code
phone,
so
I'm
just
asking.
If
there
is
a
space
for
maybe
under
specific
error
like
a
textual
information,
but
would
it
be
readable
to
the
client
you
one
without
like
reading
an
e-coat
point
and
then
matching
it
against
some
registry
yeah.
J
Are
they
were
no
number
Lakhia?
They
will
support
a
review.
I
think
it
could
also
be
useful
for
other
result.
Codes
in
error
and
I
mean
I.
Don't
think
we
should
do
it
for
an
on
India's
request
and
I
mean
the
other
thing
that
Paul
mention
is
right.
We
need
to
look
at
security.
Wise
I
mean
this
unencrypted
data.
How
to
your
left
right,
I
would.
K
C
So
when
this
was
written,
most
of
the
point
was,
you
know
specifically
debugging
type
information,
additional
server
advisory
information.
So
if
you
get
back
surveil-
and
this
leads
you
down
the
wrong
path
because
somebody's
fiddled
with
the
answer-
I-
don't
think
it's
a
huge
security
thing.
You're
just
gonna
be
confused
about
where
but
I
don't
think
it
should
actually
break
stuff.
But
I
haven't
thought
about
a
DP
right.
Q
A
K
Don't
even
remember
how
I
organized
this
suppose
I
should
look
at
it,
but
the
main
thought
that
I
want
to
communicate
here
is
my
primary
concern
about
advancing.
This
draft
is
the
fact
that
it's
obviously
PII,
where,
obviously
you
know
it
goes
beyond
client
subnet.
Here's,
the
full
identifier
of
a
person
making
a
DNS
query
in
a
request
and
I
had
my
own
misgivings
about
like
well.
Can
this
be
done
in
part,
because
it's
already
being
done
by
several
vendors
and
some
of
it
going
across
the
wide
area
network?
K
And
so
my
approach
to
this
was
much
like
my
approach
to
client
subnet
in
that
documenting
existing
practice
and
perhaps
improving
on.
It
was
probably
the
better
approach
to
take
than
just
let
it
continue
to
lurk
in
the
shadows.
But
I
will
write
up
front
and
get
my
own
discomfort
with
the
privacy
aspects
of
this.
K
The
goal
of
it
is
really
based
around
providers.
Internet
service
providers
primarily
actually
being
able
to
enable
filtering
on
DNS
requests,
and
so
it
is
meant
to
be
used
between
a
client
network
and
their
full
service
resolver
and
not
sent
out
to
authorities
the
document
attempts
to
address
this,
perhaps
not
to
sufficient
detail,
but
it
does
make
it
at
least
an
initial
attempt
at
doing
it
there,
as
mentioned
here.
It
is
already
used
on
the
network,
and
so
the
big
question
is:
do
we
document
existing
practice,
try
to
improve
on
it
or
just
say?
K
G
K
There's
this
VIII
draft,
that's
out
on
the
network
and
not
getting
any
feedback
I
send
explicitly
to
both
Ted
our
privacy
maven
and
to
Sara
Dickinson,
who
did
provide
some
useful
feedback
on
it
and
I
do
want
to
explicitly
say
that
neither
one
of
them
were
supporting
the
draft.
They
just
provided
feedback
about
how
it
might
be
less
terrible.
K
I
also
asked
for
an
e
DNS
code
point
under
the
expert
review
process
and
it
was
denied
on
the
grounds
it
was
too
complicated
because
it
quote
created
a
registry
of
sub
options
and
reportedly
it
would
have
been
granted
if
it
just
asked
for
multiple
distinct
options.
Now
I
want
to
say
without
regard.
This
is
not
the
expert
review
process
and
needs
improvement,
and
this
is
not
a
complaint
about
our
expert
review
or
who
didn't
have
sufficient
guidance
about.
You
know
what
should
be
considered
in
granting
an
idiot
a
zero
option
code.
K
Ok
with
that,
but
as
I
mentioned
in
the
previous
talk,
Suzanne,
Warren
and
I
are
all
and
Tim
are
all
working
with
Michelle
from
the
I
Anna
to
improve
this
process,
and
we've
already
seen
some
of
those
improvements
like
now.
If
you
go
to
the
IANA
registry,
it
will
point
you
at
least
to
the
documents
that
say.
Oh,
this
is
how
the
expert
review
process
was
established
to
whatever
degree
it
might
not
really
have
any
sufficient
documentation
to
establish
your
expectations.
K
At
least
you
know
how
to
begin
the
process,
and
so
oh
I
didn't
mention
my
co-authors
name.
Unfortunately,
beginning
Robert
lick,
the
Charter
started
this
process
with
us
because
he
had
the
option
to
use
one
of
the
existing
code
points,
but
he
uncomfortable
with
it.
Not
any
part
of
the
visible
standards
process
and
wanted
you
know,
even
though
we
have
some
software
that
will
go
ahead
and
talk
one
of
the
existing
options
we
wanted
really
to
focus
on.
K
K
K
I
know
our
we're
going
to
implement
it
anyway
for
the
purposes
that
Charter
wants
we're
going
to
implement
it
using
one
of
the
existing
option
codes,
because
that
code
is
already
there
and
we
actually
have
within
our
organization
something
I
can't
say
too
much
about,
but
essentially
they
need
an
opaque
token
that
is
supposed
to
be
sent
across
a
wide
area
network.
And
if
you've
read
the
draft,
you
see
that
you
know.
O
So
that's
very
public,
so
people
came
to
us
to
the
working
group
and
said
we
need
this.
You
know
eating
a
subnet.
You
know,
we've
deployed
this
already
and
you
know
we're
just
documenting
running
code
and
we
said
we
really
don't
like
that,
but
fine
and
now
you're
coming
back
and
saying
we're
running
code.
O
It's
actually
worth
saying
we
will
write
running
code,
no
matter
what
you
do
so,
please
adopt
it
and
I
think
it's
time
to
actually
put
a
foot
down
and
say
about
not
further
like
we
should
but
good,
because
a
year
further
you're
back
again
with
more
privacy,
disabling
features
like
like.
We
should
stop
doing
this.
S
Sorry
Dickinson,
so
I
want
to
applaud
all
the
efforts
that
are
going
on
to
document
what's
being
done,
regardless
of
what
we
do,
because
that's
really
important,
because
people,
a
lot
of
technical
people
are
completely
unaware
that
this
kind
of
thing
is
happening
on
the
wire.
So
as
a
minimum,
I
would
like
to
see
us
at
least
do
an
informational
draft
to
document
what
is
being
done.
Sorry,
and
so
as
a
minimum.
I
would
like
to
see
as
document
information
Lee
what
is
being
done,
but
he's
really
really
happening
out,
and
why?
S
Because
that
in
and
of
itself
is
compromising
users
privacy,
whether
or
not
we
you
know,
do
any
further
work.
I
think
that
I'd
like
to
see
that
sort
of
as
part
of
our
role
I
also
like
the
way
the
draft
is
written
currently
because
it
try.
It
does
acknowledge
the
problems
around
this.
It
tries
to
talk
about
some
of
the
principles
around
exposing
this
kind
of
information
making
it
opt-in
doing
it
over
TLS
I'd,
also
like
to
think
that
we,
as
a
working
group,
constructively,
try
and
help
solve
these
problems.
S
If
we
can
in
a
previously
preserving
way,
if
we
don't
think
we
can
do
that,
that's
when
we
come
to
the
debate
that
place
is
like
hey,
TLS
and
quicker
having
all
the
fun.
You
know
these
massive
fun
fights
over
this
sort
of
thing,
but
I
think
we
need
to
be
very
careful
about
where
we
draw
that
line,
because
I
think
we
want
to
be
doing
everything
we
can
to
do
both
of
the
things
which
is
preserve
user
privacy
and
provide
usefulness
on
the
network.
So
I
think
we
should
be
at
least
exploring
this.
Ok.
R
V
Stefan-Boltzmann
I
don't
commit
for
reviewing,
because
I
think
it
would
be
a
bad
idea
to
adopt
it.
Basically,
it
wastes
too
many
privacy
issues
are
nice.
They
want
to
say
that
second
to
today
is
really
really
weak
circus
thing
that
it
has
to
be
obtained
by
the
administrator
of
the
network.
It's
no
good!
It's
privacy
should
be
under
control.
The
user
not
yet
mister.
On
giving
as
an
example,
reading
Terms
of
Use
and
clicking
yes
I
accept
it's
certainly
not
a
reasonable
way
to
accept
something.
It's
I
mean
people
click
on
everything
every
day.
V
K
I
actually
really
agree
with
you
on
that.
One
of
the
things
I
can
mention
you
know,
as
I
was
trying
to
make
it
cuz.
The
original
protocol,
as
it
was
sent
to
me
saying:
hey,
can
we
work
on
this?
Didn't
have
any
of
this,
and
the
question
I
was
trying
to
address
was
essentially
the
situation
of
well
a
homeowner
trying
to
stay,
push,
establish
and
I
might
be
all
wrong
about
this.
K
That's
what
I've
loved
does
he
happen
until
they're
friends
with
the
iPad
comes
over
and
is
now
on
the
network,
and
everything
is
just
fine
and
it's
not
being
filtered
the
way
they
expected
things
to
be
filtered
and
I.
It's
a
I
agree
with
you
very
much
that
I
want
to
see.
People
make
conscious
choices
in
life,
not
just
about
their
privacy,
about
their
diet,
about
many
many
things
in
life
that
don't
happen
because
I
click
right
through
you
lists
do,
and
so
it
is
a
problem
and
I
don't
have
any
good
answers
for.
I
This
is
Daniel
con
Gilmore,
so
the
from
the
ACLU
so
I
do
appreciate
the
attempt
to
document
privacy
violations
that
are
ongoing
on
the
network.
Today,
I
am
disturbed
by
the
eagerness
to
try
to
make
this
more
flexible
with
even
more
privacy,
invasive
options,
the
idea
that
there's
a
registry
of
sub
options
or
that
there
would
have
been
a
registry
of
options,
I
mean
I'm,
trying
to
imagine
what
that
is.
Social
Security
numbers,
credit
card
information,
so.
G
I
K
And
so
I'll
mention
the
other
aspect
of
that
that
those
of
you
who
haven't
read
the
draft
essentially-
and
this
was
our
expert
reviewers
concerned
and
I've
mentioned-
am
onion,
because
we're
still
buddies
and
I
am
really
not
upset
with
him
for
denying
it,
because
he
had
reasonable
grounds
on
you
know
in
his
mind,
but
the
essentially
it
proposes
to
use
address
families.
So
a
Mac
at
or
IP
address,
open
DNS
uses
both
of
those,
for
example,
but
then
also
had
the
flexibility
to
use,
as
it
turns
out.
K
Dns
names
have
an
address
family
assignment
and
so
use
the
address
family
assignment
of
a
DNS
name
to
be
able
to
indicate
essentially
a
domain
name
within
somebody's
controlling.
As
I
mentioned,
we
have
a
security
division
product
that
is
really
meant
to
protect
people
talking
business
client,
that's
in
their
local
coffee
shop
and
is
connecting
to
their
secure
resolver
across
the
network
and
being
able
to
send
this
opaque
token,
which
does
not
actually
fit
in
in
an
address
family
identifier,
because
it
includes
actual
user
identifier.
K
O
So,
just
to
reply
to
Sarah,
unfortunately
outside
of
the
IETF,
nobody
knows
the
difference
between
an
informational
RFC
understand,
let's
track
RFC,
they
just
know
RFC.
So
if
we
document
something
in
an
RFC
and
that's
basically
sickening
to
the
world
outside
of
IETF-
that
this
is
something
you
should
support
and
implement
answer
standard.
So
I
really
wanted
like
pushback
against
that
notion,
leaving
as
a
draft
is
something
I
could
see
doing
but
publishing
as
an
RFC
is
basically
you
know
in
the
eyes
of
the
world.
They
stand
by
the
idea.
So.
G
K
K
But
we
didn't
support
TCP
on
the
one
server
that
ripe
connected
to,
and
so
they
pushed
back
and
said:
hey
standards
required
TCP
and
the
guy
that
came
to
me
about
I
said
yes
and
it's
required
TCP
and
you
went
and
looked
up
the
sander
and
said
he
said
it's
a
proposed
standard.
It's
not
standard
and
I'm
like
well.
K
As
far
as
the
DNS
is
concerned,
proposed
standards
are
standards,
but
we
should
be
better
about
moving
things
that
are
proposed
standards
to
being
actually
standards,
because
for
that
same
set
of
people
that
think
that
informational
or
proposed
is
a
standard.
There's
another
set
of
people
that
thinks
that
informational
and
proposed
are
nothing.
So
somehow
we
have
to
really
start
hardening
that
59
seconds.
W
Okay,
so
this
is
a
proposal
about
algorithm
negotiation
in
the
NSX
and
so
hiya
Schulman,
who
I
think
some
of
you
know.
She's
done
some
work
with
yes,
privacy.
She
prevented
an
IETF
in
the
past.
She
did
some
early
work
on
this
mechanism,
so
she's
very
much
a
part
of
this,
and
this
week
Shane
Kerr
gave
me
some
useful
feedback.
So
I
recruited
him.
G
W
Or
perhaps
tricked
him
into
joining
me
in
this
document,
so
let
me
try
to
motivate
the
proposal
by
talking
about
the
use
case.
We
have
in
mind
so
zone
operator
wants
to
incremental
e
deploy
a
new
DNS
that
rhythm
and
also
they
don't
want
to
disenfranchised
the
population
of
resolvers
that
don't
yet
understand
or
haven't,
been
upgraded
to
understand
and
you
outlive
them,
and
we
know
this
is
going
to
become
an
issue
in
the
future.
W
There
are
new
algorithms
proposed
being
proposed
or
already
appearing,
and
we
know
there's
other
stuff,
that's
going
to
appear
in
the
pipeline.
So
what
the
zone
operator
can
do
is
deploy
both
algorithms
and
then
monitor
somehow
have
a
capability
to
monitor
its
population
of
resolvers,
to
figure
out
when
they
have
been
upgraded
to
support
the
new
algorithm
and
then
withdraw
the
old
one.
So
some
of
this
can
be
done
today,
so
the
DNS
protocol
certainly
supports
signing
your
zone
with
multiple
algorithms
and
returning
signatures
with
multiple
algorithms
in
the
responses,
but
it
doesn't
have.
W
The
zone
operator
could,
when
a
response
exceeds
the
path
empty.
You
truncate
the
message
and
cause
the
client
to
retry
with
TCP,
but
that
involves
an
additional
round-trip
additional
latency,
an
additional
processing
cost
associated
with
TCP,
and
perhaps
the
zone
operator
hasn't
upgraded
their
infrastructure
sufficiently
to
deal
with
TCP
DNS
over
TCP
queries
on
a
large
scale.
So
well,
let's
here
this
week,
several
people
tell
me
well,
you
can
do
this
today.
You
can
just
just
deploy
the
new
algorithm,
because
DNS
SEC,
of
course,
fails
open,
so
nothing
breaks.
W
So
nothing
breaks,
of
course,
except
security,
and
maybe
security
is
important
right.
So
obviously
you
lose
the
benefit
of
clients
being
able
to
authenticate
your
DNS
SEC
data
and,
furthermore,
it
may
end
up
being
a
critical
problem
if
you're
using
gain
applications
which
have
a
critical
dependency
on
on
DNS
authentication.
So
they
really
can't
afford
to
fail
open
unless
they're
entirely,
unless
the
application
mode
of
using
des
is
entirely
optional
or
opportunistic
so
that
dissuades
them
from
deploying
or
adopting
the
algorithms.
So
proposal
here
is
essentially
a
new
option.
W
Of
course
that's
the
way
we
extend
the
DNS
that
allows
the
client
to
specify
an
ordered
list
of
algorithms.
They
both
support
and
and
prefer,
and
the
DNS
server
upon
receiving
this
option
can
attempt
to
select
the
best
or
strongest
algorithm
they
support
in
common
with
the
client
and
then
selectively
deliver
DNS
signatures
only
associated
with
that
algorithm.
They
can
read
the
draft
for
more
technical
details.
I
know,
Suzanne
I
have
way
too
many
slides.
W
These
are
just
for
reference,
so
you
can
I'm
not
going
to
go
through
all
of
them,
so
we
have
a
couple
of
proposals,
how
it
can
be
done
and
how
you
can
implement
algorithm
downgrade
protects,
which
will
be
important
if
we
do
this
kind
of
algorithm
negotiation,
so
you
can
go
read
those
this
would
be
a
relatively
simple
protocol.
If
DNS
were
a
you
know,
point-to-point
client-server
system,
we
all
know
it's
not
right.
There
are
caches
and
other
intermediaries
in
the
way.
W
So,
essentially
that
problem
has
to
be
solved
and
we've
sketched
up
how
to
do
that.
In
the
draft
we
have
a
little
bit
more
work
to
do
to
more,
fully
specify
the
different
scenarios
and
how
it
work,
essentially,
to
summarize,
the
resolver
will
have
to
keep
track,
of
which
cache
entries
are
so
ciated
with
signatures
from
a
subset
of
the
algorithms
support
it
and
then,
if
they
have
a
downstream
validator
that
requires
them
with
algorithms
that
are
not
that
they
don't
have
but
which
are
supported
by
the
authoritative
zone.
W
They
have
to
be
prepared
to
request
them
so
I'm
going
to
just
quickly
finish
it
before
it.
You
want
to
interrupt
me
with
an
organ,
so
there's
some
diagrams
here
about
how
the
cache
management
would
work,
and
the
other
thing
that
this
protocol
provides,
of
course,
is.
If
you
know
what
6975
is,
that
was
the
original
algorithm
cryptographic,
algorithm,
signaling
understanding,
a
signaling
mechanism
which
was
standardized
and
published,
but
as
far
as
I
know,
no
one
actually
deployed
it.
So
this
protocol
actually
is
a
superset
of
that,
so
it
can
provide
the
same
functionality.
W
So
a
couple
of
things
we
plan
to
do
in
the
future
we're
going
to
continue
working.
If
there's
a
brand
new
drop,
we're
gonna
continue
working
on
it
a
little
bit.
We
might
add
the
direction
bit
in
the
e
DMS
option,
which
is
something
that
I've
seen
in
several
drafts.
That
way.
Bellis
has
his
name
associated
with
it,
so
this
is
essentially
to
detect
broken
devices
that
without
understanding
the
DNS
option,
just
blindly
reflected
back
to
you
and
before
I
finish.
The
other
thing
we
can
do
is
we
can
decide.
W
We
don't
need
to
solve
this
problem.
We
because
we
might
be
able
to
deal
it
with
it
in
other
ways.
So
I'm
just
going
to
put
a
list
of
the
potential
other
ways
we
can
try
to
mass
migrate,
the
DNS
each
alternative
transports
that
don't
have
to
deal
with
this
problem,
so
TL,
TCP,
quick.
These
guys
I
think
there
was
a
suggestion
by
someone
on
the
mailing
list
that
the
way
to
solve
this
problem
is
just
fix
the
entire
internet
so
that
large
UDP,
fragmented
packets
work
successfully.
W
Personally
I,
don't
think
that's
realistic,
but
maybe
other
people
do,
but
even
if
it
were
the
case
that
we
could
solve
this
problem,
fragments
do
cause
of
the
problem.
So
higher
has
actually
written
a
paper.
I
think
it's
a
five-year-old
paper
called
fragmentation
considered
poisonous
where
she
demonstrated
a
bunch
of
attacks
that
she
mounted
on
the
DNS
protocol
using
fragments
and
more
recently
and
actually
long
ago.
W
In
the
past,
there
have
been
various
attempts,
even
within
the
idea,
to
completely
deck
that
deprecated
the
use
of
fragments
and
if
you
look
at
I,
think
Andre
was
that
you
that
mentioned
ECB
145
recently.
So
if
you
look
at
the
UDP
usage
guidelines
that
the
ITF
has
published,
they
say
that
if
you're
a
you
to
be
protocol,
make
sure
your
payload
comfortably
fits
in
inside
the
path
MTU,
otherwise
you're
going
to
have
problems
and
I'm
pretty
sure.
W
If
DNS
were
designed
in
the
modern
way
in
the
modern
day,
it
would
have
had
an
application
layer
framing
mechanism
so
that
you
could
fragment
and
reassemble
large
packets
at
the
dns.
Maybe
that's
another
solution,
but
that's
that's
a
pretty
big
endeavor
to
so.
Ok,
so
that's
it!
So
can
I
quickly
ask
how
many
people
have
read
this
proposal?
Okay,
that's
great,
and
so
my
question
is
I.
X
X
W
W
Point
I
agree,
so
the
way
to
deal
with
that
problem
is
there's
two
ways
you
can
do
it.
You
can
either
have
a
client
driven
preference
where
the
client
specifies
its
ordered
list
and
it
doesn't
matter
what
the
server
prefers.
The
server
has
to
pick
the
most
preferred
algorithm
that
it
supports
from
the
clients
list.
W
That's
proposal,
one
that
I
have
documented
here,
but
there's
a
second
proposal
where
we
do
the
opposite,
and
maybe
this
is
the
way
it
should
really
work,
because
I
think
a
lot
of
people
think
that
the
zone
operator,
not
the
client,
should
be
able
to
dictate
its
algorithm
preferences.
After
all,
it
is
in
the
zone.
Operators.
Interest.
Do
you?
Have
the
client
population
authenticate
signatures
with
the
strongest
algorithm
that
the
zone
operator
thinks
it
supports
versus.
W
X
W
There's
another
piece
needed
to
make
this
happen,
which
is
the
way
that
a
resolver
knows
what
algorithms
a
zone
supports.
It's
pretty
easy,
just
inspect
the
sign
here
as
PR
set,
but
you
it
doesn't
know
the
order
of
algorithms
that
the
server
is
inclined
to
use,
because
there
may
be
some
disagreement
about
how
to
rank
3,000
men,
RSA
key
versus
an
ECDSA,
P
256
or
approximately
the
same
strength.
W
L
W
Krypto,
there
are
still
algorithm
choices
right,
so
you
may
have
ECDSA
P
256
deployed,
and
maybe
you
want
to
get
out
of.
You
want
to
move
to
add
255
19,
because
the
former
algorithm
is
tainted
by
association
with
Anna
with
NIST
or
something
right.
So
you
still
may
have
other
reasons
to
transition
to
new
out.
Yes,.
L
G
W
A
V
You
Stephanie
Oh
DNS
shop
has
a
great
capability
of
producing
internet
draft
with
new
e
dns
option.
So
maybe
it
would
be
a
good
idea
to
consolidate
a
bit
and
it
seems
to
me
that
this
idea
could
fit
in
the
DNS
capabilities
draft
by
Robert
Edmunds.
At
first
glance
it
seems
compatible.
So
maybe
that's
something
to
consider
before
deciding
to
editing
this
ID
and
to
discuss
on
the
details.
Okay,.
W
J
Dana
site
already
is
fairly
complicated.
This
makes
it
a
hell
of
lot
more
complicated,
I
I,
don't
think
that
will
actually
help
with
the
adoption
of
DNA,
because
we
still
have
huge
gaps
in
kind
of
Tina,
SEC
adaption,
so
rather
rather
work
with
what
we
have,
which
seems
to
work
roughly
ok
than
to
kind
of
add
more
complicated
stuff.
That
will
actually
people
say:
oh
no,
these
are
these
guys
are
still
thinking
about
it,
maybe
not
implemented.
Now
we.
T
W
G
Y
W
M
W
M
Main
thing
is
like
route
set.
This
will
actually
delay
the
NSF
deployment,
because
people
who
think
we're
not
done
with
the
protocol
and
to
answer
your
question
when
it
is
safe
to
deploy
an
algorithm.
We
have
techniques
already
like
you're
shown
us
how
to
detect.
Hamas
is
validated
by
what
algorithm,
so
it
becomes
an
operator's
choice
of
when
they
want
to
make
that
cut.
It
shouldn't
be
baked
into
this
protocol,
making
more
round
trips,
making
resolver
slower,
making
resolvers
have
more
memory.
A
If
you're
really
lucky
well,
if
there's
enough
going
on
we'll
do
an
interim
to
work
out
some
of
these
things,
but
for
now
we
are
over
time.
We
don't
want
to
impose
on
particular
on
me:
Dec,
oh
yeah,
but
thanks
everybody
for
your
time.
Thanks
everybody
for
the
good
discussion,
and
we
will
see
you
out
there
in
radioland
and
we
will
see
you
in
Singapore.
Thank
you,
where's
that
yeah.