►
From YouTube: IETF101-DNSOP-20180320-1550
Description
DNSOP meeting session at IETF101
2018/03/20 1550
https://datatracker.ietf.org/meeting/101/proceedings/
B
A
A
C
A
A
This
is
Tuesday,
so
we
should
all
have
the
new
text
sort
of
memorized
by
now
so
and
I
actually
put
links
into
all
the
BCPs,
so
there
are
blue
sheets
floating
around
and
we
yep,
so
please
fill
them
in.
It's
always
intrigued.
Seen
who
shows
up
I
like
to
read
them
later
and
find
out
who
actually
appeared?
Who
didn't
so?
We've
got
some
agenda
bashing.
Mr.
A
Lawrence
wants
to
talk
for
a
little
bit,
some
updates
some
working
group,
business,
some
new
stuff
and,
of
course,
a
special
guest
at
the
end,
because
I
always
love
a
little
crazy
going
on
so
David.
Do
you
want
to
do
your
little
thing
about
dough,
so
David
Lawrence
is
one
of
the
co-chairs
of
the
DNS
over
HTTPS,
because
everything's
gonna
be
over
HTTPS
and
next
you
know
if
it's
not
already
ntp.
D
To
your
attention
that
the
one
single
document
that
the
DNS
over
HTTP
working
group
has
been
working
on
is
trending
towards
being
wrapped
up
and
we're
probably
going
to
end
up
moving
it
to
last
call
after
this
meeting.
That's
a
discussion
we're
having
endo,
but
since
many
interested
people
are
likely
in
this
room
as
well
and
might
not
have
been
aware
how
close
that
was
getting
finalized.
You
might
want
to
show
up
at
the
working
group
meeting,
which
is
Thursday
session
one
Thursday
afternoon
session,
one
if
you
have
some
input
on
that
document.
A
Thanks
Dave
and
if
you're
worried
about
us
getting
out
of
here
on
time,
my
better
half
is
here
and
we're
going
to
the
social,
so
I
know
we
will
be
out
of
here
at
on
time.
So
if
you
feel
like
the
Campbell
presentations,
gonna
take
us
all
off
the
rails.
If
you're
not,
you
know
at
least
who's
in
and
myself
and
Paul,
we'll
all
leave
it
at
the
proper
time.
So
so
a
bunch
of
stuff
we've
got
a
bunch
of
documents
floating
around
the
5011
one
we've
been
sort
of
being
back
and
forth.
A
There
is
some
serious
rough
consensus
on
this.
Wes
has
promised
to
do
that,
but
there's
just
some
updates
from
pictures
comments,
and
we
have
some
some
I
know
some
very
strong
negative
comments
from
mr.
st.
John
that
if
we
do
move
it
forward,
it's
all
going
to
end
up
in
the
Shepherd's
notes
and
it's
all
going
to
end
up
in
the
IHC
pile
to
sort
of
let
them
sort
of
sort
it
out.
So
cuz
I
trust
them
to
sort
of
do
the
right
thing
there,
Lee
Howard.
A
Finally,
we
finally
sorted
out
our
IP
six,
so
we're
gonna
actually
kick
off
this
working
group.
Let's
call
I
always
do
say
after
this
meeting,
but
it'll
probably
be
tomorrow
morning,
after
the
social
so
and
we'll
do
a
one
week,
because
the
most
of
the
comments
were
non
normative.
So
it's
just
updates
and
we'll
get
that
thing
out.
Joe
finally
appeared
out
of
nowhere
and
with
updates,
for
they
refused
any
draft,
and
he
will
be
talking
later
about
that
and
then,
as
long
as
everything's
been
addressed,
we
will
be
kicking
off.
A
G
This
was
actually
one
of
the
things
that
we
had
hope
to
have
off
the
docket
by
now,
but
the
plan
is
what
it
is
the
same
as
it
was,
which
is
to
now
that
people
have
had
a
rest
from
related
topics.
We
got
the
problem
statement.
Special
use
names
document
out
late
last
year,
and
people
have
had
a
worked
example
of
an
IETF
working
group
that
needed
a
special
use
name
with
home
DARPA
we're
going
to
now
that
people
have
had
a
rest.
G
We're
gonna
bring
this
forward
again
and
see
if
there's
consensus,
to
move
it
forward.
We
did
a
last
call
earlier
that
didn't
get
a
lot
of
informed
commentary.
We
would
like
to
see
a
little
bit
more,
so
we
gave
people
a
break
from
the
entire
topic
and
now
we're
going
to
try
it
and
see
again
what
the
sentiment
in
the
working
group
really
is.
A
This
chair
is
just
sort
of
like
to
make
it
all
sort
of
vanish.
So
let's
please
move
that
document
out
of
here
and
then
that'll
one
way
or
the
other
and
you'll
just
make
me
a
happier
person.
So
she
hasn't
chicken
wing
has
been
working.
Your
last
call
and
Stuart's
gonna
talk
about
the
updates
that
have
sort
of
been
a
drip
that
have
come
up
during
that
your
and
the
localhost
one
which
we
kind
of
went
through
that
right
now
sit
back
down.
A
A
Some
of
these
are
actually
gonna
be
talked
about
this
afternoon,
but
these
are
basically
up
on
the
in
the
in
disorder.
That
working
replies
call
thing
that
Deena's
capture
format,
which
there's
one
or
two
issues
that
they're
going
to
talk
about
that
are
sort
of
open
but
I
believe
that's
once
those
could
address
working
less,
calling
that
the
KSK
role,
I,
believe
David.
A
Just
everything
and
I
think
that
looks
like
it's
once
we
sort
of
go
through
it
in
the
meaning
here
were
being
the
similar
state
there
and
Paul's,
making
slow
steady
progress
on
the
terminology.
Biz
and
I've
been
seeing
lots
of
there's
lots
of
great
discussion
on
the
mailing
list
about
the
split
horizon
and
all
sorts
of
other
excellent
esoteric
names,
but
we're
sort
of
shooting
for
mid-april.
If
all
goes
well,
so
we
finally
found
Dave
Crocker's,
so
Dave.
A
Thank
you
for
showing
up
and
he
published
the
new
ad
relief
draft
and
it
looks
like
we're
splitting
it
into
two
different
documents.
So
he's
got
the
first
one
in
there
and
we're
gonna
get
the
application
guys
to
look
at
it
and
if
it
looks
good,
that's
ready
to
move
forward
I'm
pretty
happy
about
that
I
think
Peter
is
talking
about
the
a
no
evidence.
A
There
is
some
discussion
and
you'll
see
this
in
the
pimpy
in
his
talk
about
wanting
to
some
ideas
about
where
to
move
forward
on
that
I'd
like
to
move
forward
on
a
name
but
I
know,
there's
some
outstanding
issues
that
the
working
group
has
to
address
extended
error
I.
Think
it's
ready
right!
There's
one
I
believe
the
author's
OS
one
update.
Ok,
mr.
Lawrence
is
gonna
get
up
and
apologize.
D
D
To
the
extent
sure
the
authors
would
love
to
hear
that
it's
ready
for
working
group
last
call
but
I
think
you
should
probably
wait
till
you
see
the
edits
before
you
make
I
think
if
there's
no
other
cause
that
it's
it's
mostly
just
adding
more
possible
responses,
so
yeah.
In
that
sense
it
probably
is
ready.
But
yes,
so.
A
D
A
It
is
you
have
a
little
bit
more
spare
time
right
now,
so
vacation
so
and
on
the
TCP
requirements.
Duane
and
John
actually
are
gonna
put
together
an
update
in
the
next
week,
or
so
there's
some
dues
in
there,
but
once
they
do
I
would
we're
gonna
push
some
stuff
to
list
see
help
to
get
some
folks
to
help
us
fill
out
some
of
the
sections
in
there
Thank
You
Francis
for
submitting
that.
A
Finally,
the
2028
45
biz
we're
actually
gonna
kick
off
working
a
call
for
adoption
well
pine
up
tonight,
because
we're
going
to
the
social
but
party
tomorrow
and
I
believe
that's
gonna
be
easily
adopted
because
we're
very
much
we're
gonna
do
that
after
Singapore.
But
then
we
lost
you.
So
it's
okay
that
happens.
A
So
we've
got
a
big
list
of
documents
that
we're
working
on
and
stuff
that's
sort
of
coming
in
and
out
of
the
group,
as
you
can
see,
because
you'll
see
that
on
Thursdays,
which
is
all
sort
of
the
sort
of
the
rough-and-tumble
world
of
the
world.
But
what
we've
realized
is
I
used
to
work
with
a
many
years
ago
and
Silicon
Graphics
Mike.
One
of
the
kernel
guys
I
mean
this
guy
John,
the
Scottish
guy
would
always
say
we
having
a
crisis
of
success,
we're
doing
too
good
right.
A
So
we've
got
too
many
documents
too
much
stuff
coming
through
the
group
so
and
a
lot
of
stuff
wanting
to
line
up
for
adoption
and
we're
sort
of
keeping
busy
trying
to
track
all
this
stuff
down.
Stuff
is
sort
of
occasionally
falling
through
the
cracks
and
Paul's
keeping
us.
You
know
finding
stuff
like,
oh
you
know.
Mr.
waters
forgot
to
update
you
know,
but
that's
okay.
You
know,
so
we
could
actually
probably
use
an
extra
set
of
hands.
H
H
A
A
So
here's
I
kind
of
run
down
on
stuff
going
on
that's
our
new
stuff
or
here's,
a
new
stuff,
of
course,
Birds
and
special
guests.
Bert
raise
your
hand,
I,
don't
see
you
out
there.
Oh
there,
you
are
no
you're
speaking
for
my
slacker,
okay,
so
that's
probably
better
so
I
figure,
that's
interesting
cuz,
as
you
know,
John
Clinton
published
83
24
recently
and
the
independence
dream
and
it
talks
about
similar
stuff,
but
from
our
standards
point
of
view
and
birds.
A
Coming
from
a
very
operational
point
of
your
like
as
folks
who
have
to
build
this
stuff
and
deploy
the
stuff
which
hey
that's
us
Deena's
off.
This
is
the
stuff
I
think
about
you
know
in
my
day,
job
are
we
sort
of
putting
too
many
pieces
together
and
which
pieces
do
to
do
we
deploy
versus
not
deploy
so
I
figured
Bert
will
be
highly
entertaining,
if
not
anything
else,
so
so
moving
forward,
Paul
I
think
you're
going
to
talk
about.
A
I
I'm
gonna
stand
down
here,
because
I
actually
have
no
slide.
Thank
you
for
the
people
who
are
participating
on
terminology
piss.
Thank
you
for
the
people
who
are
disagreeing
with
the
current
text,
because
in
fact
the
disagreements
have
actually
brought
out
additional
terms
and
new
things
and
such
like
that.
We're
getting
close
towards
working
group
last
call.
I
As
Tim
said
earlier,
we
still
have
two
or
three
more
terms
that
people
had
pointed
out
to
Andrew
and
cousin
or
ni
as
a
possibly
problematic
and
you've
noticed
that
I
on
Monday
mornings
have
been
throwing
out
a
term
and
then
the
conversation
is
very,
very
active
and
usually
dies
out
within
a
week
or
so
I
think
I
still
have
two
more
terms
on
my
list
of
possibly
problematical
ones
will
do
a
new
draft
and
then
I
think
it's
okay.
If
this
is
a
contentious
working
group
last
call
that
is
with
lots
of
comments.
I
If
people
don't
think
that,
let
me
know,
and
then
we
might
do
just
sort
of
another
round
of
staring
at
it,
but
I
think
that
this
is
probably
an
okay
time
for
us
to
try
to
close
it
out
and
I,
don't
mean
close
it
out
as
in
we're
done.
But
then
to
you
know,
people
people
in
this
room
especially
do
tend
to
all
of
a
sudden
pay
attention
during
working
group.
Last
call
and
I
believe
it'll
be
a
long
working
group
last
call,
but
then
I
think
we
will
be
really
done.
J
Andrew
Sullivan
Oh
just
to
follow
up
on
that.
There
is
one
thing
that
I
would
like
people
to
think
about
before
that
last
call
happens,
and
that
is
does
this
document
you
know:
is
there
a
future
for
this,
or
is
there
a
different
forum
for
it?
This
kind
of
this
kind
of
thing
right
that
that's
a
taxonomy
or
a
dock
of
what
do
you
call
that
see?
I,
don't
know
words
anywhere
the
the
wordy
thing.
A
And
while
77019
was
informational,
this
will
be
standard
track
as
well
so
pay
attention
folks
and
actually
what
I've,
what
I
forgot
to
put
at
the
bottom
that
if
Burt
gets
done
talking
in
time
his
out
there,
he
is
hi
Burt.
Thank
you
for
showing
up
his
employee
Peter
will
talk
about
the
xpf
stuff
that
him
in
ray
bells
and
working
on,
but
Peters
not
holding
out
hope
for
that.
So
anyway,
Stuart
is
up
next
and
will
cover
some
of
the
working
group
stuff.
A
B
K
So
I'm
hoping
we
can
help
with
your
backlog
of
documents
by
getting
one
of
them
published.
This
is
a
status
update
now
just
to
remind
people
of
some
day
history.
Here
in
the
DNS
SD
working
group,
we
wrote
the
draft
for
push
notifications
back
in
2015
and
ray
Bayless.
Looked
at
that
and
I
think
rightly
said:
you're
mixing
up
general
session
management
information
here
with
the
specific
push
notification
mechanism
and
he
argued
for
separating
that
into
two
documents,
which
I
think
was
good
advice.
It
did
slow
things
down
a
little
bit
now.
K
The
good
news
is
I
think
we
end
up
with
something
better.
As
a
result
of
that
the
session
signalling
draft
went
through
about
a
year
of
work
there
and
last
September
with
discussion
of
the
authors.
We
realized
that
it
was
about
more
than
just
session
signaling.
It
was
really
a
foundation
for
supporting
stateful
operations,
so
that
led
to
the
name
change
so
getting
up
to
the
recent
status
update.
K
K
We
decided
to
remove
the
requirement
that
every
request
is
paired
with
the
response
and
we
introduced
the
concept
of
unacknowledged
messages,
and
that
was
discussed
very
well
in
Singapore
and
we
updated
the
document
as
a
result
of
that
and
started.
The
working
group
last
call
that
working
group
last
call
happened.
Last
month
we
got
some
bunch
of
good
feedback.
The
result
in
lots
of
textual
changes
to
the
document.
If
you
run
RFC
DIF
you'll
see
lots
of
red
and
green,
but
nothing
substantive
about
the
over
the
wire
protocol.
K
So
I
think
we
clarified
some
things
that
were
ambiguous,
but
we
didn't
get
any
major
show-stopping
objections
about
things.
We've
done
wrong
in
the
design,
so
we
submitted
draft,
oh
six
in
time
for
the
draft
cutoff
deadline
to
give
people
chance
to
review
that
and
hopefully
confirm
that
the
workgroup
feedback
was
adequately
addressed.
K
Dns
push
notifications
depend
on
this
document
being
published,
and
one
of
the
open
questions
in
that
was
how
do
we
require
replies
for
every
message
or
not,
and
until
this
working
group
had
actually
got
consensus
on
that
issue,
we
didn't
know
how
to
define
the
push
notifications.
The
discovery
relay
had
the
same
question
that
the
technology
was
building
on
was
still
uncertain
and
both
of
those
are
required
for
the
discovery
proxy.
K
So
the
DNS
st
working
group
is
keen
to
have
these
questions
settled,
so
they
don't
keep
changing
and
that's
why
we
were
keen
to
get
the
document
updated
right
away,
stay
on
top
of
address
and
the
feedback
that
we
got.
We
feel
this
is
now
ready
for
ITF
last
call
and
that's
why
I'm
here
presenting
this
to
see
if
anybody
in
the
room
disagrees,
anybody
feels
their
feedback
was
not
adequately
addressed.
A
A
L
A
M
So
the
last
round
of
changes
we
did
was
basically
comments
from
the
last
working
group.
Last
call
they're
all
relatively
minor,
Richards
happy
now,
I,
don't
believe
there
are
any
other
outstanding
concerns
about
it,
except
the
same
sort
of
concern
that
you
would
have
about
a
fish
that
had
been
slowly
decomposing
in
the
back
of
the
car
yeah.
M
It
is
I'm
kind
of
a
nasty
idea,
no
one's
suggesting
that
anybody
has
to
do
this
for
some
people,
it's
all's
problems.
All
of
who
was
telling
me
that
he
is
now
responding
like
this
to
300-thousand
any
queries
per
day,
which
is
enough
to
be
useful
for
him
and
he
has
not
identified
any
problems,
or
at
least
no
problems
have
been
reported.
M
A
N
O
P
Christmas
right,
okay,
dinner's
capture
format.
Now
for
those
of
you
quickly
who
haven't
come
across
this,
yet
this
is
about
space,
efficient
storage
of
large
packet
captures
of
DNS
traffic,
we're
using
a
format
based
on
seaboard,
we're
getting
about
40%
of
the
size
of
a
pcap
capture
after
both
have
been
through
general
purposes,
compression
and,
furthermore,
compressing
Narsee
bore
output,
uses
a
lot
less
CPU
than
compressing
sea
pcap.
P
Basically,
we
are
come,
is
a
combined
query
and
response
we're
blocking
these
into
groups
of
several
thousand
abstracting
common
data
from
them.
So
it's
a
reasonably
complex
format,
but
it's
doing
what
we
need
it
to
do
now.
The
last
time
we
discussed
this
in
public
was
in
Prague
last
year,
when
we
were
discussing
draft.
Oh
three,
we're
now
up
to
draft
those
six
draft.
Oh
four.
We
released
at
the
start
of
this
year,
really
just
with
a
few
editorial
changes
in
a
holding
pattern.
Draft.
P
P
To
this
end,
we've
reworked
the
file
preamble,
which
previously
basically
just
contained
configuration
information
information
on
how
a
capture
was
configured.
We
mouse
waded
out
into
information
on
the
storage,
what's
actually
in
the
file
and
then
configuration
items
as
before,
and
we've
extended
this
so
that
you
can
re
specify
storage
parameters
at
the
start
of
each
block
as
we
go
through
the
file.
The
intention
here
is
to
allow
merging
of
CDNs
files
at
the
block
level,
so
you
can
interleave
blocks
from
two
different
original
CDNs
files
safely.
P
The
other
major
change
is
the
next
major
change.
I
should
say:
IP
address
flexibility.
We
got
asked
if
we
could
store
IP
addresses
at
a
granularity
below
the
full
address.
So
we've
done
that,
though,
currently
that's
specified.
You
specify
a
prefix
as
part
of
the
storage
information,
we've
added
a
mechanism
to
store
malformed
messages.
If
a
message
fails
to
full
decoding,
then
we
class
it
as
malformed
and
there's
a
separate
data
area
within
the
file
in
which
the
raw
malformed
data
gets
stored.
P
P
Now
we've
got
a
few
discussion
points
here.
The
first
one
I
just
mentioned
that
we
are
Matt
we're
currently
defining
malformed
messages
as
those
that
could
not
be
fully
parsed.
Okay
up
the
draft
three
had
a
discussion
of
a
distinction
between
partially
passed
and
foot,
it's
very
partially
malformed
and
fully
malformed
messages.
P
We
didn't
get
any
feedback
or
any
indication.
Anybody
felt
partially
malformed
messages
were
of
great
interest
or
the
distinction
was
worth
mentioning,
so
we've
removed
that,
but
we
think
possibly
we
need
to
make
it
more
clear
in
the
draft
that
we
are
assuming
that
all
stored
messages
are
fully
passed,
including
all
the
RRS.
P
P
Okay,
so
you
could
include
an
RR
without
the
our
data.
This
is
a
very
small
change
and
one
that
we're
very
minded
to
go
ahead
with
the
other
request
we've
had
is
for
variable.
Ip,
address
storage
now
I
mentioned
earlier.
We've
already
done
this
at
the
file
level,
but
we've
actually
had
a
request
for
this
to
happen
at
the
per
individual
address
level
within
the
file.
P
A
P
A
You
deploying
are
you
storing
the
our
data
as
well.
We
all
store
over
absolutely
everything.
Okay,
at
the
moment,
I
would
say:
okay,
I'll,
let
Jim
talk
now
I
was
gonna,
say
we
should
probably
take
some
of
that
to
list
and
sort
of
figure
how
to
sort
of
get
that
was
resolved.
Mr.
Reid
yeah.
A
G
A
N
H
So
yeah
this
is
just
gonna,
be
some
updates
on
changes.
We've
made
since
the
last
last
IETF.
First
off,
thank
you
to
everyone.
Who's
been
sending
us
Paul
requests.
It's
made
life
way
better,
you
know,
having
actual
provided
text
is
great,
so
the
major
changes.
First
off,
we
added
a
conversational
description
on
how
this
actually
works.
A
lot
of
people
found
it
very
confusing
because
it
said
sort
of
this
person
sets
this.
H
This
person
sets
this
but
know
sort
of
what
you
actually
do
with
this
information
and
why
you
might
want
to
use
this
so
I
think
that
was
a
a
good
good
addition.
We
also
clarified
that
the
trust
anchor
that's
being
discussed
when
you
look
up
the
key
tag
is
the
active
one
for
the
root,
not
one,
that's
an
add,
pending
or
any
other
sort
of
5011
state
or
revoked,
or
something
one
that
you
would
actually
possibly
use
for.
Validation,
not
actually
what
you
did
use
for
validation,
but
one
that
would
be
acceptable
for
validation.
H
There
were
a
lot
of
readability
fixes.
So
thank
you,
everyone
for
those
silly
little
things
like
the
examples
we
hadn't
made
fully
qualified.
Now
we
are
so
that
makes
stuff
a
lot
better
for
readability.
There
were
some
privacy
clarifications,
I
think
Duane
centers,
and
thank
you
very
much
for
those
and
then
recently.
Actually
this
afternoon
we
integrated
another
pull
request
from
Cole
Hoffman.
Thank
you
explaining
why
we're
returning
so
fail
and
not
an
extra
main
and
I
think
that
makes
it
a
lot
easier
to
understand.
H
Another
obvious
one
is
the
whole
names
discussion.
It's
start
off
being
underscore
is
ta
or
underscore
not.
Ta
turns
out
that
didn't
work
so
well
with
a
records,
so
it
then
became
chaos.
Carol
Sentinel
is
ta
with
the
hex
key
ID
and
the
final
one
which
we've
settled
on
his
case.
Kay
Sentinel
is
ta
and
then
a
five
digit
decimal
key
for
folk
who
would
like
she
like
to
see
how
it
works.
The
slide
deck
has
many
more
slides
in
it
feel
free
to
flip
through
and
or
talk
to
one
of
the
authors.
H
I
H
H
We
must
any
first
off
apologies,
but
secondary,
please
remind
us,
come
along
and
let
us
know
that
we
missed
your
comments,
but
we
believe
that
it's
all
good
and
up-to-date-
and
you
know
thirteen
closed
PRS
I-
do
not
believe
we
have
any
open
issues
and
I.
Think
we've
been
good
at
scrubbing
the
mailing
list.
A
H
A
The
yes
I
can't
meaning
or
oh,
are
you
seeing
the
you
seen,
Matt
Larson's
talk
over
and
over
again
and
and
David
Connor.
It's
going
to
talk
about
it
Thursday
afternoon
in
the
working
group.
Chores,
lunch
I
think
so
because
they
just
can't
stop
talking
about
it.
Yeah
actually
I
think
it's
the
Thursday.
G
R
Briefly,
we
wanted
to
cover
the
purpose
and
fate
of
the
a
named
draft.
A
name
is
a
solution
to
the
long-standing
Apex
ename
problem.
Everybody
wants
to
be
able
to
have
seen
aims
at
their
apex,
so
they
can
take
advantage
of
CDN
optimizations
not
currently
possible,
because
cname
can't
change
can't
share
a
node
with
the
with
the
other
ro
types
at
the
origin.
This
has
a
great
deal
of
demand
in
the
industry.
There
are
five
or
six
different
implementations
from
different
DNS
implementations
and
and
our
DNS
hosting
services.
So
it's
time
for
a
standard.
R
The
existing
draft
has
been
around
for
about
a
year.
It
went
due
to
a
lack
of
attention.
It
expired
and
has
been
brought
back
to
life.
It's
not
really
ready
to
proceed
forward,
though.
Yet,
however,
because
there
are,
in
the
first
place,
issues
with
the
with
the
recursive
side
of
the
protocol
that
we're
proposing
that
turned
out
to
have
been
inadequately
thought-out,
educators
involving
DNS,
Eck
validation
and.
R
Sorting
that
out,
although
we
do
have,
we
do
have
ideas
for
how
to
sort
it
out
trying
to
write
it.
We
ran
into
a
bit
of
a
wall
because
the
recursive
and
authoritative
sides
are
somewhat
intertwined
in
the
draft.
So
we
would
like
to
propose
splitting
the
draft
that
we've
written
into
two
separate
ones,
one
covering
the
authoritative
behavior
or
the
other,
covering
the
recursive
behavior
and
the
authoritative
one.
We
think
can
probably
progress
quickly
and
the
recursive
one
is
going
to
be
more
controversial
than
take
longer.
A
But
sorry
you
know:
when
do
you
think
you'll
have
just
the
author
ocean
of
the
draft
sort
of
probably
within
a
month
and
the
the
other
thing
you
failed
to
mention,
as
use
cases
is
having
having
that
at
the
having
something
sort
of
standardized
allows
extra
to
work?
Oh,
yes,
yes,
yes!
Yes,
you
forgot
that
so
across
bender,
so
I'd.
A
A
S
Mathias,
making
I
think
it's
a
very
sane
idea
to
split
the
documents,
because
it's
very
pro-american,
pragmatic
could
focus
on
one
thing:
ship.
It
focus
on
next
thing.
If
you
keep
them
combined,
I
fear.
There
is
much
more
discussion
and
will
take
a
long
time
to
get
something
out
the
door,
so
nothing
controversial,
I
think
it
I
think
it's
a
good
idea.
I
also
have
some
thoughts,
because
the
draft
says-
and
as
you
mentioned,
there
are
different
implementations
by
different
vendors
and
they
like
to
this.
This
draft
would
like
to
replace
all
of
them.
S
Sort
of
everyone
is
using
hanging,
so
I'm
not
sure
if
currently
a
name
will
cover
all
the
use
cases
that
people
implementing
seen
in
flattening
alias
whatever
its
called.
So
maybe
it's
a
good
exercise
to
get
together,
maybe
one
on
one
and
see
what
features
we
actually
want
out
of
aiming
so
not
that
we
get
a
draft
in
the
end
that
nobody
is
going
to
implement
because
hey
these
features
is
missing
a
name,
so
we
still
use
more
version.
So
that's
a
fault.
T
Sam,
either
edge
cases
are
painful
and
often
they
are
interleaved,
so
I
I
see
danger,
interleaved
of
the
client
and
server
side,
and
so
I
see
splitting.
This
is
probably
unwise.
You
might
find
educators
and
one
to
have
to
get
fixed
in
the
other.
J
Hi
I'm,
Andrew,
Sullivan,
so
I
I
would
not
say
it
is
crazy.
Just
with
this,
because
I
understand
what
the
goal
would
be
but
I'm
trying
to
understand,
you
know
if
you're
an
implementer
what
you
do
in
that
case,
you've
got
a
document
that
you
know
tells
you
what
this
RR
type
does
in
an
authoritative
server
and
then
a
different
document
that
tells
you
how
that
our
our
type
works
in
in
other
contexts,
and
that
is
that's
a
little
weird.
Very
please.
Can
I
the.
R
Behavior
of
the
resolver
is
optional
in
the
case
of
a
name
where
we're
specifying
a
behavior
that
authoritative
servers
will
engage
in
where,
if
you
have
a
name
specified,
you
receive
an
address.
Query
you'll
return,
the
a
name
and
the
and
the
address
that
you
resolved
from
the
am
target
right,
a
resolver
that
doesn't
implement
a
name
we'll
be
able
to
use
the
address
that
the
authoritative
server
returned,
but
a
resolver
that
does
implement
a
name.
Optionally
may
improve
that
answer
by
requiring
by
itself.
That's
really
two
different
things.
D
R
J
Understood
the
intention
and
I
mean
I
I,
see
that
case,
but
I'm
just
I
I
guess
maybe
it's
the
same
thing
that
Sam
was
saying
about
edge
cases.
One
thing
that
particularly
terrifies
me
about
this
is
the
potential
for
there
to
be
drift
between
the
authoritative
case
and
what
happens
there
and
then
what
there
were.
You
know
what
a
recursive
server
or
something
like
that
does,
and
I
I.
J
You
know:
sort
of
slouching
towards
architectural
change
without
having
a
kind
of
architectural
view
and
I
threatened
to
write
a
document,
but
never
did
because
I
decided
the
thing
that
John
cleansin
wrote
was
good
enough,
and
now
it
seems
that
birds
gonna
do
the
other
half
of
that,
and
it
seems
to
me,
though,
that
this
is
the
kind
of
thing
where
I
worry
about
that
a
little
bit
right,
we're
really
stretching
stretching
the
meaning
of
an
RR
type.
J
If
you
could
have
literally
a
different
meaning
for
for
recursive,
it
can't
be
literally
a
different
meaning.
It's
got
to
be
the
same,
meaning
right
that
the
basically
the
the
nameservers
side
sort
of
has
to
work
the
same
way
for
a
recursive
and
I
guess
I'm,
just
a
little
nervous
that
we
could
introduce
a
some
pain
there.
So
so
that's
the
reason
that
I'm
uncomfortable
with
it.
But
it's
not
crazy.
A
U
Tony
Finch
I,
put
me
in
the
crazy
camp
I
think
that
there's
a
risk
of
if
the,
if
the
behavior
of
a
name
is
not
thought
through
from
end
to
end
of
missing
edge
cases,
as
others
have
already
said
so.
I
have
one
other
point
which
I'm
willing
to
help
with
wording
and
and
authoring
and
stuff.
If
you
want
me
to.
V
Wes
Verdugo
USC
I,
say
so:
I
flipped
my
opinion
twice
in
line.
I
was
gonna
start
off
by
saying
you
know
what
it's
a
check:
okay,
if
they
were
split
documents
with
one
caveat,
which
is
that
they
must,
with
a
capital,
u
be
put
together
forward.
In
other
words,
you
can
advance
one
in
front
of
the
other
because
of
all
the
educationist
people
were
just
mentioning,
but
the
reality
is
is
then
I
kind
of
realized.
V
The
problem
is
that
if,
if
future
working
groups
like
only
do
AB
is
on
one
of
them,
then
then
they
may
leave
out
education.
So
I'm
back.
You
know,
since
the
big
it
back
of
the
line.
I'm
now
back
in
my
original
frame
of
mind,
which
is
no,
they
should
stay
together
and
really
you're
just
doing
it
for
documentation
or
convenience
and
I
think
we
have
section
numbering
for
that.
R
X
The
happy
to
help
you
to
help
here
also
because
of
the
authoritative
we
are
very
well
in
other
labs.
I,
also
think
that
the
offline,
it's
implicitly
in
the
document
but
offline
case
case
of
offline
signing
kind
of
the
scenario-
should
be
well
thought,
maybe
very
explicit,
but
it
should
be
made
pasa
clear
that
it
is
possible
still,
it's
not
only
dynamic
sign
for
lang,
syne,
ok,
thanks
but
I'm
happy
to
provide
text
or
whatever.
Z
John
Levine,
you
know
I
agree.
We
all
know
this
is
a
problem
we
need
to
solve
because
you
all
solved
it
badly
and
in
keeping
with
the
tradition
of
solving
keeping
with
the
tradition
of
solving
it
badly.
I
wondered
if
you
had
considered
having
a
name
return:
the
original,
a
and
quad
a
record
for
the
original
name
and
the
original
signature
and
I
have
no
idea
how
many
resolvers
would
say.
Oh
yeah,.
Y
Z
An
a
record
you
know,
sort
of
like
a
cname
and
how
many
would
barf,
because
if,
if
the
three
solvers
were
happy
with
that,
I
think
you
could
spend
that
sort
of
that
finesse
is
the
DNS
SEC
problem
because
you've
got
the
original
signatures.
It
finesses
the
authoritative
versus
cash
problem,
because
you
can
do
that.
You
can
do
that
same
gimmick
both
places
and
you
know
I
think.
R
Ultimately,
what
we're
gonna
have
to
do
not
to
get
off
into
technical,
weeds,
but
I
think
what
we're
gonna
have
to
do
is
pass
along
the
original
AM
quad-a
to
the
client
regardless
yeah,
and
improve
the
answer
and
send
the
improved
answer
and
the
additional
section
only.
That
seems
to
be
the
only
way
that
we
can
provide
the
improved
information
without
risking
validation
problems
in
the
case
of
a
of
a
stub
that
is
validating
but
is
not
am
aware.
Yeah
I
mean
I.
Z
S
S
So,
but
if
the
consensus
is
that
these
things
should
be
shipped
together,
you
could
still
I
guess,
move
forward
by
tackling
first
alternative
and
then
once
you
have
that
you
sort
of
reduce
the
scope
for
recursive
and
then
you
can
focus
on
the
optional
improvement
for
any
mini
recursive.
So
that's
another
thought.
A
So
Evan
I
think
I
mean
it
sounded
like
you
had
some.
You
know
the
intertwining
of
the
often
resolver
in
the
document,
so
I'm
I'm,
hearing
that
folks,
like
Sam
and
Wes,
are
signing
up
to
actually
help
you
sort
of
untangle
that
in
the
draft.
So
it's
a
little
so
you
can
it
maybe
split
it
out
a
little
more
clear,
so
I,
so
I've
just
put
your
name
on
something
Sam,
so
no
problem,
I,
yeah,
I,
think
that
would
help
you
I
think
help
you
guys
as
well
sure
yeah.
What.
G
R
Knew
that's
definitely
the
case.
The
reason.
The
reason
for
splitting
the
documents
is
number
one.
We've
got
the
authoritative
behavior
pretty
well
worked
out
in
our
heads.
I.
Think
the
recursive
behavior
is
the
one
that
we're
that
we're
still
discussing
number
two
rewriting
the
document
in
such
a
way
as
to
make
it
less
tangled.
Yes,
would
be
harder
than
writing
two
documents,
so
it
but
okay,
we'll
do
the
extra
work
I
will
take.
The
I
will
take
the
extra
time
to
beter,
sir
well.
G
But
also
for
the
room.
This
is
a
good
example
of
a
situation
where
we've
got
work
that
people
want
to
do,
but
we
need
people
to
sort
of
commit
and
bear
down.
So
what
we
need
for
the
next
phase,
for
you
is
people
that
are
committed
to
reviewing
new.
You
know,
propose
new
text
participating
and
the
github
or
whatever
you're
doing
and
we'll
be
able
to
really
help
make
the
next.
The
next
version
more
understandable,
along
the
lines
of
what
we're
talking
about
here.
I
A
A
G
A
This
sort
of
came
up
discussing
the
5011
stuff.
You
know
it's
that's
a
fairly
contentious
sort
of
the
process,
but
something
that's
come
up
sort
of
in
the
operational
world.
Sort
of
my
daily
thing
is
its
Ken
reroll,
Keys,
faster
right
and
so
or
are
there
different
ways
of
doing
it,
then
the
5011
method
and,
and
so
I
Joe
wanted
to
resurrect
these
traps,
which
I
think
is
complementary
to
what's
going
on
on
that
side
that
the
best
way
to
put
it.
Yes,
that
sounds
I'm
standing.
M
Up
here,
because
it's
higher
and
I
can
see
the
slides,
so
here's
a
history
lesson
because
nobody's
heard
anything
about
the
KSK
for
such
a
long
time.
Now
the
when
we
signed
the
thing
in
in
2010,
we
published
a
trust
anchor
in
various
ways
and
at
the
time
I
don't
think
this
was
the
most
interesting
part
of
the
process
and
people
generally
ignored
it,
but
we
did
eventually
document.
M
It
was
an
internet
draft
and
languished
forever
and
then
somebody
very
kindly
rescued
it
and
shepherded
it
through
the
final
steps
and
it's
seven,
nine
five,
eight
and
that
describes
how
to
retrieve
a
trust
anchor
as
I
can
publishes
it.
It's
an
XML
document,
there's
various
other
formats,
there's
HTTP
URLs
that
are
stable,
there's
ways
of
retrieving
the
trust,
anchor
and
I
think
outside
unbound
anchor,
which
is
a
tool
that
ships
with
unbound
I.
M
Don't
think
anybody
does
this
and
I
think
that's
kind
of
a
problem
has
obvious
typo
in
the
slide,
but
we're
gonna.
We
were
going
to
roll
what
we
I
keep
saying
week.
Well,
it
is
we
where
they
with
the
general
community.
It's
us
and
I
can
in
our
slaves,
and
so
we
were
going
to
roll
the
KSK
last
October.
M
Then
we
didn't,
because
maybe
there
was
a
problem
or
something
and
I'm,
not
gonna.
Try
and
channel
Matt
Matt
lassen,
who
was
on
the
jabber
cringing
right
now,
but
so
it
was
postponed
until
this
year
in
October.
That's
the
current
public
comment
open
that
I
can,
if
you
have
an
opinion,
Matt
would
really
like
I'm
sure
for
people
to
go
and
say
yes
or
no.
This
plan
is
good.
M
M
However,
I
think
we've
all
become
a
little
bit
too
fixated
on
5011
and
whether
fifty
11
is
good
and
how
its
implemented
and
whether
they've
been
regressions,
in
particular
resolvers
about
fifty
eleven
and
it's
all,
fifty
eleven
fifty
1150
eleven
and
everybody's
forgotten
that
that's
actually
not
the
way
that
we
publish
trust
anchors
and
we
publish
trust
anchors
in
a
different
way.
This
is
a
a
mechanism
for
maintaining
a
trust
anko
once
you
already
trust
one,
but
we
actually
have
complication
methods
that
mean
you
can
go
and
fetch
a
fresh
one.
M
Now
I
sense
that
some
people
have
forgotten
this
and
they're
so
fixated
with
whether
fifty
11
works
or
not
they've
forgotten
that
the
original
bootstrapping
was
supposed
to
be
different.
So
I
don't
think
it's
necessarily
all
that
fair
to
make
this
icons
problem.
To
be
honest,
I
think
this
started
off
as
a
project
that
was
designed
by
a
small
number
of
organizations
with
lots
of
community
input,
but
it's
kind
of
ten
years
on
now
we
have
as
a
10
years
on
not
quite
eight
years
on.
M
We
have
the
opportunity
to
actually
sort
of
decide
in
the
ITF
how
we
do
some
of
this
stuff
and
I
think.
Maybe
we
should
I
think
we
should
take
some
responsibility
for
how
these
mechanisms
are
supposed
to
work.
So
it
turns
out,
with
a
great
deal
of
prescience,
back
in
2011,
Dave
night
and
I
wrote
a
dry
sorry
for
the
alarming
visual,
by
which
I
mean
that
we
have
a
Phileas
and
new-style
author
on
the
same
draft.
M
But
we
wrote
this
draft
back
in
in
2011
and
I,
just
revved
it
and
sent
it
in
and
because
Dave
and
my
email
addresses
Mike
and
haven't
worked
for
a
long
time.
We
had
to
change
the
name,
so
I
changes
something
very
different
from
validated
bootstrap
to
bootstrap
validator
and
it's
the
same
text.
All
I
did
was
change
one
reference
and
add
a
zombie
joke
at
the
end
in
case
anybody's
reading.
But
that's
it
apart
from
that.
M
It's
exactly
the
same
draft
and
it's
not
actually
too
bad
I,
don't
think
it's
ready,
but
I
think
it's
it's
actually
reasonable
and
it
describes
things
like
synchronizing
clocks.
First,
before
you
decide
to
validate,
because
that
seems
like
a
good
idea,
it
talks
about
different
ways.
You
can
pull
the
trust
anchor
it
talks
about
when
you
can
validate
when
you
shouldn't
I
think
it
gets
reasonable
advice.
I,
don't
know
that
it's
detailed
enough.
Some
of
it
might
need
to
be
revved
because
time
has
moved
on,
but
I
think
generally.
M
M
So
that's
it
I
submitted
it
yesterday
or
something
I
mean
no
doubt
you
all
remember
it
with
vivid
clarity
from
2011
when
you
reviewed
it
diligently
then,
but
you
know
you
might
want
to
refresh
your
memory,
but
in
any
case
open
question
to
the
chairs.
I
guess
is:
do
you
think
we
should
pick
this
up?
If
you
do
I'm
very
happy
to
continue
working
on
it,
so
is
Dave
what.
M
Run
off
okay,
yeah,
but
no
Dave's,
more
reliable
than
I
am
so.
What
do
people
think
this
is
a
draft
about
how
to
bootstrap
trust
for
a
validator
in
the
situation
where
either
50:11
is
not
working
for
you
or
you,
don't
have
an
opportunity
to
do
50:11
because
you're,
just
starting
for
the
first
time,
and
you
have
no
trusted
excellent
right.
Key.
V
M
AA
M
AA
AB
AC
AD
Jeff
Houston
I
supported
two
for
subtly
different
reason.
Fifty
eleven
always
assumes
continuity
of
integrity
in
a
key
if,
for
any
reason,
the
current
key
becomes
unobtainable
unusable
or
compromised
in
any
way
we're
back
to
square
zero
with
nothing
and-
and
this
at
least
is
an
alternative
way
of
looking
at
that
and
might
come
in
handy
at
some
vague
and
indefinite
point
in
the
future,
so
I'd
encourage
it.
Thank
you.
Excellent.
Y
I'm
gonna
point
out:
we
had
this
pretty
much
roughly
the
same
discussion
back
when
this
first
thing
him
up
main
problem.
Well,
we're
getting
good
at
there's
a
discussion,
but
again
all
this
is
doing
is
pushing
off
the
trust
into
some
other
space.
Y
You
have
to
trust
a
see
a
key
before
you
can
trust
the
trust
anchor
key,
which
means
you
now
have
to
select
a
set
of
CAS
that
are
going
to
be
valid,
make
sure
everybody
has
them
and
hope
they
don't
go
dead
because
again
same
problem,
so
I
this
is
just
an
off
pile.
This
is
you
know.
Solving
the
problem
by
in
indirection,
50:11
was
designed
to
deal
with
the
existing
trust
anchor
set,
which
had
to
be
established
manually
because
we'd
never
done
it
before
and
to
carry
it
forward.
I.
M
Think
that's
a
good
point.
I
should
point
out
that
the
mechanisms
that
this
refers
to
this
draft
is
based
on
the
other
draft,
which
describes
how
I
can't
publish
this
thing's.
No
doubt
I
can
publish
things
in
a
different
way
in
the
future,
and
no
doubt
this
draft
could
change
and
I'm
more
interested
really
in
the
general
concept.
I
think
you
know
before
you
can
trust
something.
As
you
say,
you
need
a
manual
configuration.
AE
Nick
Johnson
aetherium
foundation,
like
the
previous
commenter,
it's
unclear
to
me
that
we
can
trust
a
see
a
search
for
longer
than
we
can
trust.
Okay,
as
Kay
and
I'm
also
concerned
that
for
validators
with
resource
constraints,
requiring
them
to
be
able
to
do,
HTTP
requests
and
validate
cas
is
a
significant
additional
burden,
and
I
wonder
if
there
isn't
a
simple
proposal
around
having
a
longer
lived
KSK
that
is
better
protected
and
gives
you
a
equivalent
security.
M
Thanks
I
would
encourage
people
not
to
fixate
on
the
fact
that
there
are
certificates
mentioned
in
this
document,
because
it's
that's
just
mapping
what
I
can
decided
to
do.
I
believe
that
I
can
thinking
at
the
time
was
there
are
people
who
distribution
the
form
of
software
updates
that
are
signed
with
a
key
if
you
trust
that
code,
because
you
trust
that
key,
perhaps
that's
also
a
useful
path
of
trust
to
trust
in
the
trust
anchor.
That's
my
recollection
of
other
people
at
the
time.
Don't
shoot
me
for
that.
M
That's
the
decision
that
was
made
at
the
time.
This
document
here
is
really
concerned
with.
How
do
we
start
trusting
something
it
could
be
manual
or
it
could
be
automatic
and
I
think
the
observation
during
this
key
role
process
if
it
was
something
some
alternate
method
of
that
was
automatic,
that
might
help
us
roll
the
key.
M
J
Name
is
andrew
sullivan.
I
every
time
this
topic
comes
up.
I
think
mike
was
quite
correct
that
we've
had
this
conversation
before,
but
every
time
this
conversation
comes
up,
it
seems
to
me
that
what
we're
trying
to
do
is
find
the
one
true
way
that
you're
going
to
get
this
key
and
that's
just
the
wrong
plan,
there's
lots
of
different
ways
that
you
could
bootstrap
this
trust.
This
is
a
way,
and
it
seems
that
this
is
a
way
that
actually
has
the
benefit
that
it
maps
onto
something
that
people
are
already
doing.
J
So
you
know
it
seems
good
to
me
to
write
it
down
and
have
this
this
mechanism.
That
doesn't
mean
that
you
know
this
is
the
right
way
for
everyone
or
it's
the
right
way.
You
know
for
every
context
or
anything
like
that,
but
a
lot
of
people
already
have
a
set
of
CAS
that
they
trust,
and
so
it
doesn't
seem
to
me
to
be
weird
to
say,
and
if
you
already
trust
that,
then
you
know
you
can
trust
this
too
and
I
think
that's
it.
J
That's
the
sort
of
way
that
we
have
to
have
to
approach
this
I,
don't
believe
that
there
is
one
true
way
to
do
this
and
I
think
that
it
has
been
a
mistake
that
the
DNS
community
has
occasionally
made
that
we
try
to
do
that.
We
try
to
make
it
always
in
the
protocol,
because
it
doesn't
always
work
for
everybody's
case
Thanks.
AF
Hi
runs
for
a
sixer
fit
first
of
all,
I
support.
This
is
a
good
idea
to
do
to
do
this.
I
think
two
remarks
so
I
think
Microsoft
DNS
also
pulls
those
trust
anchors
from
that
proposer.
He's
not
just
unbounded.
Does
that
and
for
those
people
that
don't
trust,
CAS
I
can
print
these
and
distribute
them
at
the
workshop
in
Madrid
last
year.
This
is
actually
a
really
good
way
to
bootstrap
stuff.
AF
N
AF
Am
actually
serious
because
there
are
I
mean
this.
The
the
ICANN
case
case
show
has
been
going
around
the
world
and
they've
been
presenting
everywhere.
There
are
people
from
I.
Cannot
have
this
D
s
up
on
slide
every
time
it
is
really
really
hard
to
spoof
that
you
just
look
up
five
videos
and
if
they
have
the
same,
the
S
on
it.
M
AG
Belong
to
orb
and
helmet
lobs
I
work
on
a
Philadelphia
step,
resolver
called
cattiness
and
its
intent
is
to
be
used
for
Dane
validation,
for
example.
So
the
semantics
are
very
different
than
those
of
a
running
visual
for
validating
this
over
you
don't
know
when
applications
will
need
validation,
then,
when
they
are
started
by
the
user,
and
there
could
be
a
period
of
more
than
30
days
in
which
application
is
not
used
and
also
those
applications
winning
user
space.
AG
AG
V
Where's
her
car
USC
ASI
and
can
I
suggest
a
way
forward
from
this
discussion
that
I
think
that
there's
a
lot
of
people
in
this
room
that
have
been
thinking
about
this
problem,
lately
I'm
betting,
the
person
behind
me
I'm
betting,
a
large
number
of
people
from
ICANN
staff,
I'm
betting.
You
know
myself
I'm
betting,
a
ton
of
protocol
experts
have
been
thinking
about.
Where
do
we
go
next?
V
This
to
me
sounds
like
a
complete
session
in
say
some
IETF,
possibly
Montreal,
where
we
give
people
some
time
to
write
up
various
ideas,
and
then
we
talk
about
them,
because
this
is
not
gonna,
be
a
10
minute
discussion
about
one
draft.
This
is
gonna,
be
a
lot
of
dress.
That
really
ought
to
all
be
considered
with
lots
of
brainstorming
ahead
of
time,
so
that
we
can
make
a
informed
decision
about
what
the
right
path
forward
is.
So.
M
Y
Two
things
are
see:
sorry
Michael,
st.
John's,
14,
IRC,
49
86
was
actually
the
basis
for
our
C
50
11
and
why
it
got
the
way
it
was.
This
particular
thing
was
talked
about
before
as
part
of
that
requirements
document.
Anybody
should
go
and
take
a
look
at
that
one
before
throwing
everything
under
the
bus
second
thing
about
it.
Does
your
protocol
include
a
protocol
for
updating
the
original
CA
trust
anchor?
No.
M
Y
I'm,
saying
here
is
that,
if
you're
pushing
off
the
problem
to
someone
else-
okay,
that's
we
just
need
to
acknowledge
that
and
go
forward
with
it
and
I'm
fine
with
that.
Well,
not,
finally,
that
I
think
it's
actually
a
bad
idea,
but
but
just
hiding
it
by
indirection
isn't
actually
solving
the
problem,
because
you
still
have
thousands
tens
of
thousands
of
boxes
with
the
CA
public
key
in
it
that
somehow,
if
that
goes
bad,
you
need
to
be
able
to
figure
out
how
to
fix
that
right.
That's.
M
If,
if
we
expect
the
key
role
to
happen
regularly
in
the
future
like
every
year
or
something
you
don't
have
to
sit
in
the
warehouse
for
that
long
before,
whatever
you've
got
installed
a
new,
is
it
accurate
and
you
have
to
have
some
way
of
bootstrapping
from
the
network?
So
I
don't
know
what
the
answer
is,
but
I
think
there
is
a
gap
again
I
think
describing.
What
we
do
right
now
is
has
some
value
and
Michael.
You
can
blame
me
because
I
told
him
to
to
put.
U
My
name
is
inigo
montoya.
So
what
do
you
think
about
pre
signing
pre
signed
the
next
pre
signed
the
reification
key
get
out
there,
while
your
current
key
is
active,
an
assertion
of
what's
coming
next,
to
allow
people
to
build
into
shelf
units
an
assertion
of
the
future
state
for
some
time
window
doesn't
fix
every
problem.
It
increases
the
buffer
size
that
you
have
less
to
worry
about.
What
do
you
think
well
I,
which
is
an
idea
Russ
Housley
recently
raised
in
the
crypto
working
groups
and
the
explicit
idea
for
CAS
III.
M
I
have
opinions
about
this,
but
I
don't
think
this
is
the
right
place
to
share
them.
I
think
I
think
there's
a
wider
discussion
that
no
doubt
I
can
will
convene
at
some
point
about
the
evolution
of
how
they
manage
the
KSK
and
publish
new
ones,
and
that
would
be
great
for
that
venue.
But
I
don't
think
it's
it's
directly.
What
I
took
to
this
mic.
U
Tony
Finch
regarding
Roland's
idea
of
getting
trust
from
lots
of
artists
stations
from
lots
of
people
about
four
years
ago,
I
wrote
up
a
draft
that
was
based
on
that
idea,
but
as
a
protocol,
that
draft
was
not
was
over
complicated,
but
I
have
ideas
for
simplifying
it.
The
advantage
of
this
is
that
it
gives
you
a
certain
degree
of
resilience,
because
you
don't
have
a
single
point
of
failure.
U
So,
if
you're,
some
of
your
witnesses,
some
of
the
people
who
are
talk,
who
are
saying
this
key,
is
the
right
one
disappear
off
for
whatever
reason
you
might
still
have
a
quorum,
that's
big
enough
to
establish
trust
from
from
that.
But
the
idea
is:
there's
no
single
point
of
failure.
You're
not
just
in
directing
to
some
other
route
of
trust,
so
I
think.
M
M
G
M
I
can
take
another
hack
at
this
zero.
Zero
I
think
that
meanness.
This
just
definitely
not
be
my
idea.
I'm
not
qualified
to
design
this,
but
I'm
happy
to
be
an
editor
I
think
it's
something
that
working
group
could
work
on.
Yeah
yeah,
so
I
mean
it
first
thing
a
question
is:
is
it
a
working
group
document
and
then
we
invite
commentary
or
is
it?
Is
it
a
private
thing
that
we
decide
later
whether
to
adopt
an
argument?
There
are
some
folks.
A
There
are
several
folks
who
came
up
to
the
mic
and
you
know,
including
couple
I
think
at
one
or
two
I
can
people
who
said
you
know
this.
Is
they
support
kind
of
looking
at
some
of
this?
It
may
not
be
adopted,
but
it
definitely
you
know.
I
know
I
want
to
turn
this
into.
Let's
make
Mike
st.
John
sad
working
group,
so
Mike
I'm,
sorry
about
that,
but
sometimes
you
know,
but
it
I
heard
enough
interesting
people
supporting
it
that
it's
at
least
eight,
let's,
let's
sort
of
think
about
it.
G
A
So
and
if
someone
wants
to
assist
Joe
cuz
I
have
a
feeling
he's
gonna
Bennett
run
away
on
me
again.
I
think
Joe
liked
that
as
well.
So,
okay,
thanks
so
before
we
get
to
the
real
fun
part,
just
sort
of
some
recap,
some
stuff
there's
a
couple
drafts.
It
looks
like
we're.
Gonna
do
working
group
last
call
will
probably
kick
off
this
week,
so
you
probably
see
a
spate
of
stuff
coming
through
the
mailing
list.
Do
not
panic!
A
You
know
that
looks
like
session
signaling
refused
any
and
KSK
role
as
long
as
they've
all
sort
of
addressed
their
sort
of
comments
that
have
come
up
on
the
middle
of
this
in
the
past
couple
days,
sort
of
things
so
and
also
the
call
for
adoption
on
the
T
cig
bids,
one
which
we're
very
happy
to
sort
of
move
that
along
so
great.
So
this
is
what
you're
all
been
waiting
for.
I
know.
So
what
Byrne
approached
us
I
was
as
an
Operations
person.
I
was
like.
A
N
AH
It
has
been
pointed
out
to
me
that
the
camel
is
a
very
worthy
animal
and
can
survive
in
harsh
climates
and
with
little
sustenance,
and
indeed
this
is
true.
The
camel
is
a
very
impressive
animal,
but
the
story
also
goes
that
that,
once
you
overload
the
camel
a
single
straw
can
break
its
back
and
that
that's
the
analogy.
I
was
aiming
for
I'm
I'm
Betty
Bear
I'm
from
power
DNS.
We
are,
we
write
open
source
software.
AH
We
are
very
much
an
open
source
company.
We
are,
however,
also
a
24/7
on-call
service
provider
with
service
level
agreement
back
support
and
we
are
on
the
line
for
millions
of
euros
in
penalties.
We
don't
solve
your
problem
at
3:00
a.m.
when
it
breaks.
This
gives
us
a
sort
of
interesting
perspective
on
new
standards.
I
found
this
glorious
lists
on
the
ISC
website
is
anyone
present
who
made
who
recognizes
the
list
and
who
made
it?
It's.
AH
AH
It's
amazing:
it's
also
twice
the
size
of
the
C++
programming
language,
the
fourth
edition
it
is
well
known
as
the
standard
in
document
and
everything.
This
is
a
ton
of
stuff.
Of
course
this
was
a
naive
edition
of
185
RFC,
so
some
of
them
are
historical.
Some
of
them
are
maybe
not
super
relevant.
However,
the
list
is
also
incomplete,
so
we
could
probably
stay
the
good
claim
that
the
DNS
specification
is
now
around
3000
pages
or
a
bit
less.
AH
AH
And
now
that
we
have
a
little
bit
of
time
on
the
party
in
as
web
site,
we
also
have
a
list
of
compliant
RFC's
and
we
put
RFC
1925
in
there,
the
12
fundamental
networking
truth,
which
is
an
April
1st
RFC
yeah,
but
it's
a
very
good
one.
It
tells
you
a
lot
of
fundamental
things
about
the
internet,
which
you
should
all
know
about,
and
we
put
it
as
a
funny
joke
in
our
compliance
table
and
it
ended
up
in
the
official
procurement
document,
and
so
we
said
we're
compliant.
So
that's
good.
AH
AH
What
does
this
code
do?
Let
me
first
tell
you
how
we
discovered
it.
We
did
a
big
migration
to
parity
in
us
and
all
of
a
sudden,
a
few
percent
of
a
subscriber
customers
base
could
no
longer
use
the
internet.
They
simply
vanished
and
we
tried
to
do
with
TCP
dump,
but
figure
out
what
was
going
on,
because
no
more
DNS
was
coming
out
of
this
customers.
AH
AH
AH
This
is
a
lot
like
how
I
implemented
BGP
recently,
which
is
also
turns
out
to
be
easier
to
implement
from
Wireshark
than
from
you.
I've
sees,
but
anyhow,
this
is
the
operational
reality.
This
stuff
is
in
the
field,
so
we
can.
We
can
write
thousands
of
pages
of
standards
and
then
we
end
up
with
this.
AH
This
is
a
graph
I
like
graphs.
This
is
the
complexity
of
DNS
over
time
when
I
first
got
interested
in
DNS,
a
6
and
binary
labels
are
still
a
thing,
and
we
thought
this
stuff
is
too
complex.
No,
no
one
is
gonna,
get
it
and
remember
some
of
you
may
remember:
we
did
a
6
because
we
thought
ipv6
addresses
were
too
long
to
fit
in
512
bytes
UDP
packets.
So
we
made
a
sort
of
standard
right.
If
you
put
a
whole
bunch
of
ipv6
addresses
in
there,
you
could
compress
them
against
each
other.
AH
It's
nice,
and
but
it
was
widely
derided
as
too
complex
and
too
difficult.
We
had
a
tea
sake.
We
added
the
in
a
sec
and
at
an
SEC
3,
a
joke
among
implementers
were
that
the
three
and
SEC
three
stood
for
the
number
of
people
that
really
understood
it,
and
then
people
came
to
me.
They
said
bet
it's
not
that
hard.
It's
not
that
hard.
AH
You
just
complaining,
because
you
have
to
implement
that
stuff
and
you
add
the
NS
track
and
it's
2018
and
we
are
still
having
conferences
with
the
good
people
of
ISC
and
not
a
noun
that
labs
to
figure
out
corner
cases,
so
the
complexity
of
DNS
went
up
enormously
around
that
time.
A
DNS
client
subnets
was
added.
I
was
in
favor
of
a
DNS
client
subnet,
because
I
thought
it
was
a
good
idea
and
it
turned
out
to
be
a
horrible
idea.
AH
We
add
queue.
Name,
minimization,
which
is
Stefan
has
pointed
out,
is
not
a
DNS
protocol
feature,
but
is
something
that
should
work
if
everyone
followed
the
standard,
except
that
that
you
have
to
work
very
hard
to
make
it
work
for
the
people
that
did
not
follow
the
standard.
So
you
see
the
complexity
of
the
protocol
go
up
over
time.
An
interesting
exercise
for
the
reader
is
to
take
the
glorious,
IEC
RFC
list
and
plot
the
number
of
lines
of
specification
as
an
actual
factor
of
time
see
when
it
happens.
AH
What
is
the
object
of
this?
This
is
the
future.
So
this
this
I
scroll
I.
This
is
the
present
and
I
zoomed
a
bit
to
the
right.
What
more
is
on
the
horizon?
So
this
is
a
quick
scan
of
drafts
that
are
being
discussed
right
now
and
and
they
will
not
do
anything
to
reduce
the
complexity
of
the
NSA
or
DNS.
So
it's
not
it's
not
getting
any
easier.
Okay,
fine.
AH
We
have
some
very
smart
people
here,
exceptionally
smart
people-
and
this
is
the
number
of
people
that
can
get
the
complexity
of
the
image
and
the
big
watershed
moment
was
Dina
sec.
When
we
added
the
in
a
sec,
we
lost
Mara
DNS,
we
lost
my
DNS,
we
lost
a
whole
bunch
of
name
servers
that
were
not
able
to
find
the
bandwidth
to
keep
up
and
implement
this
standards.
AH
So,
okay,
you
can
say
these
people
did
not
have
enough
time
anyhow
or
they
deserved
to
get
kicked
out
of
the
fields,
but
hey
we
lost,
we
lost
so
further
and,
as
we
add
more
and
more
stuff,
eventually,
we
will
be
left
with,
like
20
people
that
really
get
it.
Okay.
Is
that
a
problem?
This
is
the
quality
graph,
and
this
is
known
to
anyone
that
has
ever
done.
A
product
management
in
software
quality
goes
down
when
you
rapidly
add
new
complexity
and
then
over
time
the
quality
recovers.
AH
So
the
advent
of
DNS
SEC
saw
a
huge
increase
in
the
number
of
software
vulnerabilities
in
the
DNS
products.
It
was
a
while
that
every
DNS
vulnerability
that
was
found
was
related
to
a
DNS,
SEC
record
type
or
validation,
or
an
incest
or
whatever.
This
goes
for
all
software
plans.
Eventually
we
recovered
when
DNS
SEC
was
old
enough.
Eventually,
we
shook
out
all
the
bugs
and
we
founded
and
quality
recovered.
AH
AH
How
does
this
kind
of
thing
happen
whenever
a
protocol
or
piece
of
software
or
generally
whatever
evolves
it
evolves,
because
there
are
forces
pulling
on
it?
So
we
have
DNS
implementers
that
have
certain
ideas
where
the
DNS
should
be
going.
We
have
operators
that
have
feelings
about
where
the
DNS
should
be
going.
AH
We're
actually
doing
this
for
people
that
use
the
internet,
but
usually
in
other,
where
that
they're
using
DNS,
so
they're
they're
not
much
of
a
voice
at
the
table
and
then
our
standardizes
that
sit
here
and,
for
example,
as
in
the
previous
two
presentations
ago,
where
people
say
well,
we
have
this
alias
and
a
name
and
several
competing
implementations,
and
then
the
standard
values
together
say
well.
We're
gonna
make
a
standard
okay.
So
these
four
forces
on
DNS
are
interesting
implementers.
AH
We
should
be
awed
by
the
quality
of
the
implementers
of
DNS
right
now
and
I'm
completely
honest
about.
Is
there
there
I,
don't
think
there
is
any
Internet's
relevant
protocol?
It
has
search
quality
implementations
right
now.
You
can
you
go.
You
can
download
freely
superb
software
right
now
and
we
should
all
be
super
proud
about
that.
I
was
in
another
working
group
here
a
few
hours
ago,
and
they
were
all
begging
for
people
to
please
implement
this
stuff.
We
do
not
have
this
problem.
AH
Everyone
is
implementing
all
that
stuff
and
they're,
extremely
smart
people
so
good
stuff.
Sometimes
these
programmers
underestimate
how
smart
they
are
in
the
sense
that
they
are
actually
a
lot
smarter
than
they
themselves
to
think.
This
is
unusual.
This
leads
to
statements
like
insec.
3
is
not
difficult.
AH
These
are
also
people
that
solve
quantum
mechanical
constraints,
while
bicycling
some
of
them
actually
do
by
the
way.
So
so
far
the
implementation
community
has
been
able
to
keep
up
with
all
the
standards
easily
enough.
They
say:
ok,
you!
You
wrote
this
massively
complicated
thing,
we're
on
it
and
we'll
do
a
hackathon
and
afterwards
it's
there,
and
it
has
been
tricky
for
the
implementation
community
ourselves
and
myself
included
has
been
tricky
for
us
to
say
no,
because
it's
it's
sort
of
sort
of
embarrassing.
AH
If
you
have
to
say
that
yeah,
you
wrote
this
and
sec
5
and
it's
too
difficult
for
me.
I
tried
it
and
I
I
spent
the
whole
week.
Reading
on
pseudo-random
functions
and
stuff
and
I'm
still
lost
it's
difficult
to
say:
I,
don't
get
this
and
you
when
that
happens.
That
is
when
the
orange
line
goes
down,
because
there
are
people
that
say:
look
I,
just
I
have
to
check
out
because
I
don't
understand
and
sec
12.
AH
The
second
one
is
one
of
the
other
implementations
will
do
it.
So
whenever
one
implementation
says
well,
we
don't
really
feel
like
doing
RFC
5
five
one
zero
zero,
because
we
think
it's
it's
too
difficult
and
brittle.
That's
what
we
said
and
everyone
says:
well
all
the
other
ones.
Did
you
have
to
do
it?
You
simply
must
do
it,
there's
huge
peer
pressure
for
everyone
to
implement
everything
and
see.
Of
course
it's
a
lot
of
fun
to
work
on
new
stuff.
AH
So
if
you
have
a
book
tracker
with
200
issues
in
there,
and
some
of
them
are
fast
books
from
festering
users
and
then
there's
a
fun
new
feature,
we
get
on
it.
So
as
implementers,
we
do
not
have
well-developed
product
management's,
so
you
come
up
with
a
new
feature.
I
know
some
developers
here
are
just
sitting
here
like
I.
Can't
wait
to
check
this
in
to
make
this
happen,
so
we
do
not
provide
as
implementers.
We
do
not
provide
solid
pushback
when
someone
invents
something
new.
AH
In
fact
we're
like
bring
it
on
operators,
so
in
I'm,
normal
I
am,
of
course
we
write
software,
but
we're
very
deeply
involved
with
the
operational
DNS
resolver
community.
So
these
are
the
people
that
have
20
million
customers
and
get
measured
by
their
governments
on
their
performance.
They
are
on
call
24/7.
AH
They
are
being
judged
by
the
availability
and
performance
of
their
name
server
and
by
nothing
else.
So
if
you
say,
I
enabled
this
privacy
enhancing
feature,
but
all
your
lookups
are
now
one
millisecond
slower.
No,
it's
not
going
to
fly
there
and
in
fact
governments
specifically,
the
UK
government
performs
measurements
on
DNS
latencies
and
they
publish
them
as
tables
and
they
order
them
by
performance.
AH
And
everyone
jumps
on
that
of
course,
which
means
that
if
you
say
I'm
gonna
do
DNS
SEC
validation,
you
will
fall
to
the
bottom
of
the
table
immediately
and
you
might
get
a
footnotes
that
says
what
we
commend
provider
extra
doing
the
intersect
but
you're
in
the
slow
lane.
It
was
a
look
this
provider
that
the
12th
in
the
nation
in
terms
of
performance,
I'm,
sorry.
AI
B
AA
AH
These
people
are
resource
constraints,
so
we
get
Comcast
here
and
they're
wonderful
people
and
they
say
look.
We
have
a
small
DNS
team,
it's
21
people,
all
my
customers
combined,
have
a
DNS
team
of
21
people,
but
most
big
service
providers
have
one
DNS
person
for
3
million
subscribers
and
they
do
not
have
a
lot
of
bandwidth
for
any
any
fancy.
Interesting
things.
The
interesting
now
is
that
these
operators,
they
should
be
a
limiting
factor
under
the
development
of
DNS.
They
they
should
say.
Look
you
made
this
complex.
This
is
2
operationally
difficult
for
us.
AH
We're
not
going
to
do
it.
So
please
reconsider
make
this
simpler.
Okay,
the
problem
is,
these
people
are
not
in
the
room.
The
service
providers
DNS
that
use.
They
typically
ask
us
to
say
a
few
things
on
their
behalf,
because
they're
not
authorized
by
their
their
bosses
to
actually
comment
because
they're
they're
not
allowed
to
get
up
here
and
say
our
DNS
is
a
mess.
It's
a
difficult
thing.
So
these
people
should
provide
the
push
back,
but
they're,
not
authoritative
and
resolver
I
will
say,
but
briefer
about
this
one.
AH
It
is
quite
easy
to
add
features
to
an
authoritative
server
because
it
turns
out
you
can
turn
off
an
authoritative
server
for
whole
days
before
anyone
notices,
an
authoritative
server
has
no
probing.
It
has
no
state,
it
just
serves
data,
it
sits
there.
That
means
that
if
you
have
an
operative
server
mindset
and
it's
quite
easy
to
think
up-
features
like
a
DNS
client
subnet,
because
the
e
DNS
client
servlet,
is
you
get
the
question?
You
provide
an
answer?
That's
it
it's
not
that
hard
to
do.
AH
If
someone
doesn't
want
an
e,
DNS
client
sub
that
question.
He
should
not
send
you.
Sorry.
If
someone
doesn't
want
any
DNS
client
submit
answer,
he
should
not
send
you
an
Adina's,
subnet
client
question,
so
it's
quite
easy
from
the
authoritative
site,
because
authoritative
servers
can
be
down
for
days
before
anyone
notices
the
dot,
NL
infrastructure.
We
had
a
server
that
was
down
for
a
whole
day.
The
belgian
ccTLD
has
had
a
server
that's
unreachable
by
half
of
the
internet.
AH
For
half
a
year
now-
and
apparently
this
is
all
fine-
you
can
see
these
on
the
right,
the
investment
by
the
way.
The
interesting
thing
is
the
authoritative
server
the
ccTLD
people
are
well
represented
here,
so
they
can
provide
feedback.
They
can
say,
don't
do
this.
Do
that.
Do
this?
Do
this
the
pcap
compression
format
we
were
discussing
earlier.
That
comes
straight
from
their
operational
experience,
so
the
authority
server
people
are
well
represented.
The
the
DNS
service
provided
people
not
standardized,
are
welcome
hello.
AH
You
are
also
among
the
smartest
people
in
the
world,
and
congratulations
on
that,
and-
and
indeed
no
challenge
is
too
too
hard.
If
n
SEC
is
not
good
enough,
we'll
come
up
with
an
SEC
3
and
if
an
SEC
3
is
not
good
enough,
we'll
come
up
with
an
SEC,
5
and
I
was
around
when
n
SEC
3
happens,
and
people
said
we
cannot
solve
this
problem.
There
is
no
solution
to
this
problem
and
they
in
the
standardising
community
and
Roy
and
other
people
went.
We
will
show
you
what.
AI
AH
Do
and
that's
really
impressive
and
honestly
and
the
standardizes
are
on
a
mission
to
improve
the
internet
and
they
think
full
time
we
have
a
whole
roomful
of
top
quality
brains.
Thinking
right
now
about
how
to
improve
the
internet,
the
standardizing
people.
However,
there
is
no
such
thing
as
24/7
Standardization
SLA.
So
it's
rarely
that
someone
goes
up
at
3
a.m.
and
says:
I
need
a
standard
right
now,
there's
an
errata.
It
needs
to
go
out
before
noon.
AH
This
gives
a
slightly
different
mindset
in
terms
of
complexity
because
to
a
standardization
person,
actually,
it's
sort
of
fun
to
work
on
really
complex
puzzles
and
and
and
we
feel
that
you
master
all-
that's
got
those
complexities,
but
typically
as
a
standardized
err.
You
don't
have
to
think
about
that.
3:00
a.m.
call
that
says
what
just
crashed,
because
yeah
you'll
hear
about
that
in
the
morning
as
a
standardized
ER
or
maybe
a
bit
later.
AH
Standardized
are
also
in
some
sense
optimists
that
they
think
that
look.
We
made
this
complexity
and
if
we
thought
it
out
pretty
well
and
now,
people
will
type
it
in
ok,
but
simultaneously,
standardized
errs
are
pretty
distrustful
because
they're
sure
that
if
they
don't
specify
everything
that
the
implementer
swore,
of
course
stupid
will
mess
it
up
now.
This
is
also
in
the
forces
model
who
is
determining
what
happens
with
DNS.
AH
The
standardized
errs
are
under
appreciative
of
operational
24/7,
on-call
Trados,
and
this
leads
to
one
of
the
biggest
points,
I'm
hoping
to
make
the
unexpected
interaction
of
features.
Every
time
you
add
a
new
feature
to
DNS,
it
interacts
with
all
the
other
existing
features
of
DNS,
often
in
unsurprising,
of
in
surprising
ways
in
ways
which
end
up
bloating
the
code
base
of
resolvers
tremendously.
So,
for
example,
you
have
D
name
and
DNS
SEC
theoretically
unrelated
features.
AH
However,
it
turns
out
they
collide,
so
you
must
special
case
D
name
and
DNS
SEC
EDS
client
subnet
sounded
like
a
great
idea.
It
turned
out
that
in
production
it
led
to
0%
cache
hit
rates
because
the
Assumption
the
operational
assumption,
how
big
service
providers
would
lay
out
their
networks
with
maybe
/
16
subnet.
Here
and
a
/
12
subnet,
there
turned
out
to
be
completely
wrong.
AH
Actual
service
providers
have
slashed
24
subnets,
which
means
that
they
have
65,000
bins
for
a
DNS
client
subnet
answers,
which
means
that
you
need
whole
new
CPUs
to
deal
with
this
trivial
feature.
I
didn't
see
that
coming
and
the
authoritative
server
people
also
did
not
see
it.
Coming
later,
I
spoke
to
a
bunch
of
people
that
work
at
service
providers.
They
did
see
it
coming,
but
they
somehow
did
not
find
their
voice.
AH
Every
new
feature
that
leads
to
probing.
You
should
see
the
state
machine,
that's
in
a
name
server
right
now
and
a
resolver
that
needs
to
figure
out.
Ok,
I'm,
not
getting
a
response.
What's
that
packet
loss
or
did
the
other
side
simply
not
understand
my
question
I'm
getting
a
bogus
response
was
that
because
they
misinterpreted
my
DNS
option
or
not
every
time
we
add
a
new
feature,
we
complicate
the
outgoing
machinery
for
the
probing
and
it
adds
on
and
on
and
on
there's
one
notable
exception
to
that.
You
sometimes
have
orthogonal
features.
AH
So,
for
example,
if
you
add
a
new
record
type,
it
doesn't
bite
anything
else.
As
long
as
that
record
type
just
sits
there
and
provides
answers.
You
can
add
as
many
record
types
as
you
want,
unless
they're
called
dname
or
unless
they're
called
a
name
so
in
general,
stay
away
from
features
called
something
name
like
cname,
so
the
addition
of
features
is
not
does
not
lead
to
a
linear
increase
of
complexity.
Some
individual
features
can
lead
to
a
doubling
of
the
complexity
of
everything,
because
now
everything
needs
to
be
read
twice:
the
net
result.
AH
There
is
a
push
from
the
DNS
standards
community
to
evolve
DNS
because
there
are
always
something
to
fix.
The
implementation
community
says
bring
it
on,
because
we
like
doing
that
stuff,
the
commercial
operational
community
that
actually
has
to
answer
the
phone
call
at
3:00
a.m.
when
it
breaks
is
not
in
this
room.
So
let
me
do
a
small
experiment,
who
is
on
call
for
a
multi-million
DNS,
resolver
installation,
how.
A
A
AH
The
the
the
the
point
of
view
of
the
operational
community
would
often
say:
please
keep
this
simpler
and
and
after
a
second
iteration
it
would
say:
can
you
still
make
it
simpler?
But
this
we
do
not
to
hear
these
people
because
they
for
a
variety
of
reasons.
They
don't
show
up
here.
A
lot
of
features
therefore
end
up
being
accepted
and
being
implemented
because
of
peer
pressure.
Everyone
does
it
and
for
now
this
has
been
going
pretty
well,
we
have
recovered
from
the
NSF.
AH
So
this
has
been
a
long
wine,
so
these
are
do
I
have
a
proposal.
I
would
recommend
everyone
before
we
invent
a
new
feature.
We
think
long
and
hard
who
wants
this
feature
and
who
would
benefit?
That's
one
part,
the
other
part
who
bear
the
costs
of
this
new
feature.
So,
for
example,
when
we
say
what
we
would
like
to
send
a
query
that
has
an
A
and
a
quat
a
query
in
it
in
one
go,
it's
obvious
who
benefits
the
end.
AH
User
gets
better
latency,
the
costs
are
borne
by
name
servers,
resolvers
and
I
have
to
figure
out.
If
everyone
understands
that
feature.
Ok,
the
development
community,
including
myself,
should
develop
a
little
bit
of
spine
and
also
say:
look.
You
know
how
difficult
this
is
and
I
know
it
requires
some
practice,
because
we
think
we
can
do
everything.
But
it's
legitimate
to
say
this
feels
like
a
lot
of
work
and
I
worry
about
this,
and
I
would
love
for
more
operational
people
to
be
involved.
AH
The
people
that
actually
run
this
stuff
and
have
a
could
have
told
us
in
time
that
Adina's
client
subnets
would
it
would
be
a
disaster
and
that
we
also
try
to
listen
to
them
because,
of
course,
I
have.
To
be
honest,
the
commercial
community
always
says
that
is
too
difficult
and
that
they
don't
want
it.
So
that's
is
not
gonna
be
easy.
There
are
some
reasons
why
they
don't
show
up,
and
maybe
we
should
work
on
that
and
see
if
we
can
make
it
easier
with
that.
Thank
you
for
listening
to
my
rant.
AH
In
a
sense,
I'm
advocating
a
DNS
diet,
yeah
I
think
that
was
the
question.
I
think
we
should
think
long
and
hard
whenever
we
add
something
new
me
even
on
Twitter
today
propose
that
whenever
you
write
a
new
DNS
RFC,
you
have
to
deprecate.
One
I
agree
with
that.
Then
there's
enough
to
choose
from
so
I
would.
AB
Indeed,
suggest
putting
it
on
a
diet
and,
as
somebody
who's
worked
hard
at
getting
some
of
these
big
bumps
and
complexity
into
the
standard,
I
apologize
and
I
think
it's
really
time
that
we
take
a
look
at
some
of
those
and
throw
them
out
like
and
sex
3
just
kill
it.
It
doesn't
work,
it
doesn't
do
what
people
they
get
us
a
client
subnet.
AB
It
doesn't
benefit
anybody,
but
a
few
people
who
are
willing
to
pay
for
it,
but
they
shouldn't
pay
everybody
for
to
implement
it,
but
I,
don't
like
it
I,
don't
think
I
would
like
you
to
die.
There
are
dname
it.
So
it
was
an
okay
idea,
but
nobody
uses
it.
So
maybe
it's
time
to
throw
it
out.
I
could
go
down
the
list,
a
name.
AB
S
Mattias,
making
yeah
thanks
for
the
very
amusing
presentation,
but
also
you
I,
think
you
erase
Adela's
concerns.
I
do
indeed
not
disagree
with
this.
Some
of
your
points,
however,
first
going
to
say
that
three
hundred
thousand
lines
of
code
RFC's
there's
a
lot
of
boilerplate-
probably
it's
a
half
of
it,
but
okay,
still
a
lot.
I
have
so
many
things
to
say,
I'm
trying
to
be
coherent
here,
but
you
triggered
a
lot
of
I,
don't
reactions.
S
For
example,
you
said
here's
something
like
an
SEC
free.
We
did
an
SEC
3,
it
was
complex
and
it
is
complex
yeah
because
even
for
me,
I
read
the
error
of
C
and
I
think.
Why
are
these
things
and
that's
why
I
meet
Kevin
and
I
came
up
with
just
an
information
on
document?
I
think
it
would
be
very
valuable
for
the
community
have
more
information
document
to
to
explain
why.
First,
certain
responses
are
there
why
certain
decisions
were
made.
Historic
context
is
very
hard
to
grasp
in
in
these
working
groups.
S
Also
I
already
saying:
well,
we
come
up
with
a
standard
and
then
we're
going
to
implement
that
and
turns
out
to
be
very
hard.
I
must
be
the
other
way
around
right,
we're
here
to
make
a
standard
to
get
implemented,
but
before
we
making
it
sound
that
it
should
be
reference
implementations,
ideally
even
more.
Maybe
we
should
focus
more
on
that
workflow
again
so
because
if
you
do
that,
you
will
have
less
of
those
unexpected
results
yet,
on
the
final
slide,
so
it
shouldn't
be
I
implemented
our
team
to
implement
it.
S
So
it
would
be
great
if
you
could
do
that,
have
a
reference
implementation
she's,
don't
throw
it
in
production
immediately,
but
figure
out
those
unexpected
results
before
we
write
it
down
or
maybe
kill
a
feature
because
it
makes
it
too
hard
and
my
still
coherent,
I
don't
know.
Okay,
you
also
headed
up
a
peer
pressure.
I
think
Oliver
touched
on
this
a
little
bit.
You
don't
have
to
implement
everything.
If
you
don't
think
it's
a
good
idea,
don't
do
it.
S
Yeah,
if
there's
no
money
in
it,
don't
do
it
whatever.
If
you
don't
feel
like
it,
if
you're
in
grumpy
mood,
don't
do
it
and
at
least
by
all
means
don't
do
it
halfway
done.
Definitely
don't
do
it
halfway
and
yeah,
and
maybe
we
should
indeed
focus
on
killing
some
things,
because
one
thing
I
do
agree
with
you
is
that
if
you
introduce
something
new
there's
a
lot
of
other
things,
you
have
to
take
into
account
before
otherwise
you
may
break
stuff,
but
that
also,
if
you
do
a
reference,
implementation
may
be
able
to
catch.
AJ
Learned
round
I
would
like
to
push
back
a
little
bit
on
your
idea
of
putting
DNS
on
a
diet.
I
think
the
problems
that
describes
are
real,
but
they
are
not
only
limited
to
DNS.
This
is
something
that
we
observe
in
the
industry
for
all
big
piece
of
software
when
I've
worked
with
large
vendors
and
operating
system,
routers
and
I
work
with
colleagues
in
other
places
similar
and
essentially
all
the
same
problems
we
never
duplicate.
Any
features,
never
happened,
it's
just
too
complex.
You
don't
know
what
you're
going
to
break.
AH
Agree
fully,
but
one
also
been
in
industry
for
a
while.
The
really
strange
thing
about
our
industry
is
that
features
are
free,
so
you
invent
something
new
and
everyone
will
rush
to
implement
it.
This
does
not
happen
when
you
build
routers
switches
because
they
say
you
want
this,
you
got
to
pay
for
it
and
that
provides
a
natural.
AJ
AH
AJ
But
the
point
I
think
the
point
I'm
trying
to
make
here
we
were
talking
about
the
price
of
success
earlier
on
of
the
beginning
of
a
working
group.
This
is
a
price
of
success
of
a
protocol.
People
wants
to
use
it.
People
have
new
ideas
of
using,
and
people
always
come
with
new
ideas
on
how
to
do
things.
AJ
So
I
think
that
direction
should
not
be
to
go
on
a
diet
and
say
no
to
new
feature,
but
the
direction
should
be
to
have
better
processes
for
vendors,
to
integrate
and
develop
new
features
so
that
it's
some
a
streamline
and
doesn't
break
things,
and
they
are
better
quality
control
and
better
processes
for
people
that
operate
so
that
they
are
better
tools
to
debug
the
network
and
to
get
back.
The
implementation
actually
be
a
better
direction.
I.
AH
AJ
Something
that
happens
in
the
discussion
with
vendors
of
software.
Typically,
you
have
a
list
of
25
features
and
you
can
implement
10
choose
the
10
right,
but
the
finger
I'm
saying
it
you
if
it
should
come
with
a
price
tag,
which
is
we
have
to
find
the
processes
associated
with
those
features.
I
understand.
AH
AG
AK
Butterscotch
chicks
is
I
think
thank
you,
embed
for
opening
the
kind
of
forums
you
were
talking
about
the
standards
and
we
have
to
mention
that
standards
are
not
the
thing
which
is
happening
on
the
vine
right.
We
have
like
plenty
of
workarounds
for
all
different
crap,
which
is
out
there,
and
so
you
was
talking
about
the
ants
on
diet.
AK
So
let's
try
this
see
that
Nick,
together
with
poverty,
NS,
I,
see
and
aniline
and
Labs,
which
basic,
which
basically
means
them
four
main
open-source
vendors
of
DNS
resolvers,
are
going
to
remove
some
idns
workarounds
starting
next
year.
So
we
have
some
press
releases
about
this
out
there
already
so
either
catch
me
or
Google
for
a
DNS,
workaround
removal
and
let's
see
if
the
diet
works.
Thank
you
for
bringing
up
thank.
G
You
and
John
cleanser
in
the
Java
room
says
for
the
microphone
there's
actually
another
issue
with
returning
to
record
types
for
a
single
query
like
a
and
quad
a
see.
The
discussion
of
the
original
male
parent
RC
8320
for
more
due
to
craig
partridge
than
to
john
and
my
personal
note,
I'll,
add
that
RFC
83
24
is
actually
worth
reading
as
a
complementary
approach
to
what
Bert
has
been
discussing.
Wait,
there's
a
pretty
good
argument
to
be
made
there
weren't
a
pretty
deep
hole
here.
People.
AH
D
David
Lawrence,
yeah
I,
don't
think
that
there's
actually
anybody
in
the
room
that
disagrees
with
the
assertion
that
we're
in
a
pretty
deep
hole
and
that
it's
not
kind
of
nuts,
where
we
are
what
is
not
been
entirely
clear
to
me
even
with
your
closing
slide,
is
what
exactly
is
the
call
to
action?
I
mean
you
say:
okay
go
on
if
I
push
back
like
are
we
talking
about
a
reach
are
during
that
specify
is
really
what
type
of
you
know
how
to
give
the
pushback
that
we
need
to
push
back.
D
D
You
know
how
can
implementers
get
together
and
and
have
these
workshops
to
identify,
what's
good
and
what's
bad
and
then
the
one
other
historical
note
I
wanted
to
observe
was
that
Andrew
was
part
of
an
effort
a
while
ago
to
have
this
like
Omnibus
reconciliation
of
185
RFC's
and
it
it
went
badly
because
it's
a
horrible,
ugly,
awful
thing
to
try
to
do,
but
it's
also
perhaps
an
important
necessary
something
we
need
to
do
like.
If
you,
you
know,
look
at
the
tax
code
or
whatever
they
they
reconcile
what
they
strike
out
the
portion.
D
So
you
can
just
read
the
portions
that
you
need
to
read
and
you
know
like
maybe
it's
time
to
finally
do
this
harmonization
and
say
as
a
working
group.
This
is
an
important
thing
to
do
because,
as
an
implementer,
you
can't
go
through
185
different
documents
and
trying
to
figure
out
how
implemented
dns
correctly,
and
on
that
note,
when
the
straw
breaks
the
camel's
back,
you
know
because
you
have
a
paralyzed
camel.
D
How
do
you
know
when
the
DNS
straw
has
broken
the
camel's
back
and
that
weak,
but
clearly
we're
not
paralyzed
and
we're
still
moving
forward
or
sideways
or
downward,
or
whatever
direction
we're
moving
in
and
and
to
the
extent
that,
like
you
know,
I
know
the
names
consortium
has
been
working
on
trying
to
figure
out
like?
Are
we
moving
towards
different
identifiers?
Do
we
need
DNS
v2,
like
perhaps
we
need
to
identify
what
metric
is
going
to
finally
say
you
know,
DNS
is
not
something.
That's
gonna
sustain
us
into
the
next
century.
J
Hi
there
my
name
is
Andrew
Sullivan
and
I'm.
Also
here
to
say
yeah
sure
I
agree
with
you,
but
but
thanks
butBut,
the
IAB
a
number
of
years
ago
wrote
a
document
about
what
makes
a
successful
protocol
and
one
of
the
things
that's
in
that
document
is
this
description
of
success
and
then
wild
success
and
wild
success
sounds
like
a
good
thing.
J
But
if
you
read
that
document
carefully,
it
warns
you
while
success
is
not
always
what
you
want,
because
you
you
lose
the
ability
to
do
things
that
you
didn't
want
to
do
with
that
protocol,
because
people
are
now
using
it
for
stuff.
You
didn't
want
and
somebody
somebody
I
suspect
in
this
room
published
a
number
of
years
ago.
You
know
a
t-shirt
and
a
set
of
greeting
cards,
and
so
on
that
you
could
get
that
was
about.
You
know
how
we
hold
these
truths
to
be.
J
You
know
self-evident
or
whatever
rough
code,
consensus
and
running
code
and
scribbled
it
all
out,
and
you
know
screw,
that
put
it.
The
VNS,
yeah
and
I
I
have
a
set
of
these
by
the
way.
If
people
have
lost
them,
I
can
mail
them
to
you.
So
I
think
that
there's
an
important
thing
about
this
that
we're
overlooking
there
are
all
these
features
that
are
here.
But
you
know,
if
you
think
about
oh
I,
don't
know
EP
P
or
another
bespoke
protocol
like
that.
J
Nobody
is
demanding
weird,
you
know,
stand
on
one
foot
and
scratch
your
head
extensions
to
the
to
the
protocol.
The
way
say
a
name
works,
and
the
reason
for
that
is
because
it's
a
bespoke
protocol
that
is
tightly
bounded,
but
this
is
the
database
that
everybody
has
on
the
internet
and
they're
sure
they're
gonna
be
able
to
get
to
it's
the
one.
So
we
got
a
wild
success
problem
and
if
you
want
to
fix
this,
we've
got
to
come
up
with
something
that
that
solves
that
problem.
J
In
order
to
get
people
to
stop
jamming
it
into
this
thing,
I
don't
know
how
to
do
that,
because
I
don't
know
how
to
tell
the
rest
of
the
Internet
nope
nope
they're,
not
using
our
protocol
for
that
they're
gonna.
Do
it
anyway,
I
mean
my
employer.
Did
it
right?
That's
that's
what
we
do,
and
so
it
seems
to
me
that
if
we
don't,
if
we
want
to
solve
this
kind
of
problem,
then
we
need
to
come
up
with
something
else
that
is
shiny
enough,
that
people
will
go
and
follow.
J
AH
J
So
I
would
I
would
say
slightly
further
than
that.
You
may
be
about
to
get
what
you
want
right,
and
that
is.
It
could
be
that
that
the
the
doe
working
group
is
step
one
in
the
end
of
the
DNS
and
that
we
be
able
to
replace
the
under
the
underlayment
layer
after
you've
got
this
this
top-level
interface,
that's
a
possibility,
but
I
think
we
ought
to
think
about
it
rather
than
let
it
just
happen.
Thanks
just.
AH
AL
Stay
in
York
and
Andrew
I'd,
let
you
move
ahead
of
me
and
you
stole
my
joke.
Cuz
I
was
gonna
comment
about
Warren
and
his
shirt.
You
know
which
you
frequently
wears
about
just
stick
it
in
DNS
yeah.
You
don't
you're
not
wearing
that
one
today
I
think
you've
got
something
else,
but
okay,
I
can't
tell
Burt
I
just
would
say.
Thank
you
for
coming
and
cataloging
this
in
a
very
humorous
way
on
a
very
serious
subject.
AL
I
think
the
challenge
to
echo
what
what
what
introduced
said,
though,
is
that
we
are
a
victim
in
the
success
we
are.
You
know.
Dns
is
this.
You
know
well
database
that
everybody
can
access
and-
and
you
know,
I'm
in
more
places
and
people
are
saying
well
yeah.
We
can
just
use
DNS
for
that.
I
mean
look
at
how
various
different
records
have
been
used
in
ways
that
nobody
ever
thought
they
would
be
in
so
many
different
ways
and
I.
AL
Think
one
of
the
challenges
we
have
is
that
it's
nice
to
say
we're
gonna
slim
down
and
get
rid
of
some
things,
but
at
the
same
time
we
are
all
very
actively
working
here
to
go
and
add
more
features
in.
If
we
look
at
all
the
DNS
privacy
work,
which
is
so
excellent
in
so
many
ways,
but
it's
going
to
add
in
you
know
more
aspects
to
that
and
more
different
ways
to
do
that.
So
I
don't
know
how
we
get
there
I.
Thank
you
for
bringing
this
there
I
think
yeah
Andrew.
AL
You
know
you
missed
a
word,
though,
because
you
mentioned-
or
you
mentioned,
JSON
right
or
a
REST
API.
Now,
if
we
also
and
we've
got
HTTP,
we
also
need
to
throw
in
an
other
word.
People
starts
with
ABI
watch-chain,
yes
yeah.
If
we
can
do
that,
and
everything
will
be
shiny
and
it
will
be
awesome
okay,
so
somebody
just
has
to
go
put
that
together
that
okay,
they
want
people
just
watch
a
joke.
Here's
a
joke!
It's
a
joke!
Joke!
It's
a
joke!
Yes,
joke
joke!.
AL
A
AL
Anyway,
I
just
want
to
say
I
think
you're.
Right,
though,
on
the
last
part
about
it,
is
a
challenge
to
involve
the
operational
community.
We
do
need
to
do
that.
I
would
love
to
talk
to
people.
Who've
got
ideas
around
how
we
can
do
more
of
that,
because
that
is
something
that
we
do
need
to
to
figure
out
a
better
way
to
bring
more
people
here
or
not
even
bring
them
here,
but
to
interact
with
them.
You
know
and
to
help
people
understand.
AL
I
gave
a
talk
last
year
at
the
at
the
ISC
to
security
Congress,
which
was
to
a
bunch
of
enterprise
people
about
DNS
and
about
DNS
privacy
and
stuff,
and
a
lot
of
those
folks
were
selling
like
whoa
wait,
you're
doing
this
DNS
privacy
stuff,
that's
gonna,
break
the
query.
You
know
the
stuff.
We
do
to
monitor
queries
on
our
local
networks,
you
know,
and
so
they
were
suddenly
very
unaware
of
all
of
the
stuff
that
we're
doing
here.
So
it
is
the
fact
that
we
are
making
these
changes
that
do
have
these
broader
impacts.
AL
X
X
We
did
made
some
decisions
and
we
thought
it's
not
well.
We
we
think
it's
not
good
to
implement
this,
but
to
be
fair
through
the
years
we
we
did,
listen,
of
course,
to
the
users
and
you
to
make
a
decision.
Indeed
to
do
you
want
to
be
relevant.
Do
you
want
to
have
this
diversity
in
the
DNS
software?
We
implement
these
kind
of
features,
and
so
it's
more
a
personal
observation
for
me
to
share
with
you
not
a
question,
not
a
remark,
not
advice,
but
yeah.
Y
G
G
F
Hi
this
is
Jerry
and
I,
see
speaking
about
going
or
some
spine
I
think
we
did
grow
some
spine
with
de
DNS,
workarounds
and
I
think
this
is
like
growing.
Some
spine
is
like
both
face.
F
But
it's
also
about
saying,
if
you,
if
we
implement
your
own
DNS
server,
and
you
don't
give
a
about
what
we
need,
then
we
will
not
talk
to
you,
so
we
probably
should
because
the
list
of
the
RFC's
you
you
have
shown
is
it's
quite
a
long,
but
I
think
that
if
we
define
as
like
the
smallest
minimum
set
that
people
should
know
that
must
implement
in
their
implementations
for
us
to
speak
to
them,
because
it's
causing
development
cost
is
causing
operational
costs.
Do
all
that.
AH
F
To
to
other
people
here,
I
think
that
the
well
that
seasonique
I
see
a
Leonard
labs
and
power
DNS.
Ours
are
speaking
all
together,
even
without
these,
like
IITs
and
other
venues.
So
so
we
we,
we
are
doing
something
to
like
coordinate
what
probably
should
not
be
accepted.
If
there's
something
really
weird
coming
away,
so
we
speak
to
speak,
we
fight
each
other
and
even
though
we
are
competitors
in
in
a
nature,
we
are
also
friends
indeed,.
A
AM
Yes,
so
in
comparison
to
the
BGP
working
group
in
IETF,
the
implementers
have
their
own
working
group
IDR
and
one
of
the
strict
requirements
is
that
nothing
can
progress
to
our
see
if
there
are
not
a
number
of
proven
interoperable
implementations
of
whatever
whatever
is
proposed
in
IDR
its,
but
maybe
DNS
needs
to
afford,
if
recursive,
and
to
stop
libraries
like
raise
the
bar
and
that
all
maybe
create
the
diet's
you're
looking
for,
and
this
does
impose
significant
cost
on
everybody
involved
because
you
might
be
spending
hours
on
something.
That's
not
gonna
live
on.
AM
The
flipside
I
do
think
that
IDR
compared
to
other
ITF
working
groups
does
produce
quite
quality
products
and
I'm.
Funny
enough,
I
DRS
kept
in
check
by
a
different
working
group,
namely
grow
which
the
operators
you
I
grow
functions
as
a
sort
of
customary
customer
advisory
boards
to
IDR
and
even
as
charted
quite
broadly,
to
sometimes
step
in
and
say.
No.
AH
AM
AH
AM
W
When
did
you
meet
it
yeah?
So,
first
of
all,
thanks
for
the
presentation,
it's
very
inspiring
and
overall
I
agree
with
your
point.
Our
DNA
is
getting
more
complicated
and
we
should
be
careful
about
adding
new
features,
and
on
top
of
that,
I'd
like
to
make
a
comment
as
an
implementer
I'm,
an
implement
of
DNS.
Am
I
deaf
Jovie,
there's
always
to
increment
things
on
DNS
and
I.
W
Thank
you
that
I,
don't
like
it
so
at
the
participant
of
the
ITF
I,
generally
think
about
proposal
as
an
implementer
and
if
I
think
I
still
complicated
is
concerned.
From
that
point
of
view,
and
actually
in
this
working
group,
many
our
participants
are
also
implementers
and
I
often
see
the
canopy
rock.
W
So
I
guess
the
station
is
not
as
bad
as
you
present
it
and
but
again
still
I
also
see
the
current
station
is
too
complicated
and
we
could
make
it
better,
so
I
definitely
see
some
points
to
improve,
but
the
I
would
like
to
point
out
that
they
implement
that.
Probably
not
that
thought
of
you
might
think
I
think.
AH
AN
This
is
a
Puneet
from
Google,
so
I'm
new
to
DNS
and
I'm,
going
through
some
of
the
problems
you
described
here,
because
I'm
new
to
DNS
Google's
product
has
been
around
for
a
while,
but
I
see
these
problems,
so
the
thing
I
would
say
is
I
would
second
the
suggestion
which
is.
We
should
have
implementations
when
we
have
RFC's
without
a
reasonable
implementation.
It's
hard
to
say
how
good
these
standard
is.
So
that's
something
I
think
we
should
definitely
focus
on.
AN
Similarly
writing
down
a
set
of
minimal
RFC
someone
new
to
the
protocol
as
an
implementer
implementer.
That
would
be
nice,
so
you
know
it
has
the
20
you
read
instead
of
the
hundred
which
are
out
there
and
on
that
same
note,
another
thing,
given
the
complexity
of
implementation,
I
think
the
community
needs
to
do
some
work
on
having
protocol
validators,
which
are
available.
So
you
should
be
able
to
say
here's
my
resolvers,
here's
a
validator
which
goes
who
say
thousand
points
of
DNS
behavior
and
you
run
it
against.
AN
AH
W
D
G
D
I
historically
follow
up
on
jobs,
comments.
Who
was
the
three
eyes
that
independent
interoperating
implementations
was
a?
It
was
a
basic
tenet
of
the
IDF
as
a
whole
and
I'm
wondering
when
that
fell
by
the
wayside
for
various
groups
and
would
support
actually
bringing
it
back
as
a
hard
requirement
before
RFC
publication.
I
would
also
on
the
DNS
ops,
ops,
I'd.
D
You
know
again.
Historically,
we
had
the
NSX
and
it's
unclear.
You
know,
I,
don't
think
this
problem
would
have
been
really
improved.
All
that
much
in
theory
having
protocol
worked
on
in
DNS
off
with
meant
that
ops
considerations
were
taken
into
consideration
right
and
to
the
extent
that
that's
happened
to
made
any
difference.
D
AF
V
AF
In
the
book,
yeah,
no
no
I'm
not
going
to
comment
on
the
coda,
because
that's
just
plain
horrible
I
used
to
work
for
for
a
vendor,
a
very
small
vendor
that
dates
smartcard
software
and
if
you're,
a
very
small
vendor,
and
you
have
to
interoperate
with
products
that
are
made
by
really
big
vendors.
Then
it
is
very
natural
to
even
if
you
think
it's
not
your
mistake
to
fix
it.
You
are
another
small
vendor,
your
big
four
right,
the
big
open-source
vendors.
AF
AF
Why
you
do
it,
but
I
I
think
that
the
point
Andrey
raised
about
having
a
subset
of
our
a
minimal
subset
of
RFC's,
that
everybody
who
does
dns
is
supposed
to
implement
and
if
they
don't,
then
you
don't
have
to
interoperate
with
them
is
as
I
mean,
if
that
is
on
your
public
tender
list
right
this.
This
public
procurement
thing
that
you
should
comply
with
this
RFC.
That
says,
if
you
don't
do
this,
we
don't
have
to
interoperate
with
your
product
that
might
go
some
way.
AH
AF
AH
AF
But
it
may
be
a
lot
easier
to
do,
but
if
this,
if
this
stuff
is
in
CPE
equipment-
and
you
are
working
for
for
this
operator-
who
wants
to
use
your
product
wants
to
pay
for
support,
you
should
have
a
serious
conversation
about
their
procurement
of
CPE
equipment.
I,
frequently
have
serious
conversations
about
procurements.
They
often
involve.
AH
AO
Bert
I'm
Shane
Kerr
yeah,
it's
cool
presentation
from
my
point
of
view,
I've
been
think
about
this
for
a
while
and
I
do
think
that
as
a
DNS
community,
there
seems
to
be
a
groundswell
of
support
for
some
fundamental
changes
for
dealing
with
this
kind
of
big
pile
of
that
we're
all
dealing
with
every
day.
I
think
that,
in
order
to
progress
beyond
that,
I
think
putting
these
measures
in
place
about
making
it
more
difficult
to
get
standards
written
or
these
kind
of
things
they
can
help.
AO
But
I,
don't
think
they're
gonna
address
the
fundamental
problem,
which
is
that
we've
got
a
protocol.
That's
really
really
old
and
has
been
pushed
well
past.
Its
expected
service
life
and
I.
Don't
think
we
can
just
replace
it.
Even
if
we
have
awesome
Jason
interfaces
to
do
stuff.
Legit
I
think
that
what
we
should
be
working
to
as
a
community
is
to
try
to
find
a
way
to
evolve
our
protocol
in
ways
that
we
can
actually
remove
things
that
we
can
do.
AO
Refactoring
I
mean
imagine
if
you
had
a
code
base
that
you
weren't
allowed
to
change
into
the
old
functions
and
just
had
just
like
layer
on
top
of
it,
you'd
end
up
with
something
that
looked
a
bit
like
this
yeah.
So
that's
where
I
think
we
should
go
and
I'm
happy
to
work
with
people
and
try
to
move
in
that
direction.
Okay,.
AP
Peter
called
Enoch
first
of
all,
half
adult,
or
thank
you
for
that
presentation
just
for
historical
reference,
I
guess
that
was
in
San
Diego,
maybe
in
the
year
2000,
when
Randy
Bush
gave
a
presentation
overloading
the
Saddleback's
of
an
old
horse.
Now
the
horse
evoluted
in
a
in
a
camel.
It
is
interesting
to
compare
these
two
and
to
look
at
what
the
problems
were
then
and
what
the
problems.
AP
What
promise
you
identify
today
I
would
be
saddened,
though,
if
the
solution
to
the
list
of
problems
you
came
up
with
would
be
yet
another
RFC
that
lists
the
list
of
the
other
other
RFC's
that
are
important,
declaring
the
others
not
so
important,
because
then
you
just
go
or
the
community
just
would
go
back
to
square
one
right,
I
think
there's
two
issues
here:
one
is
purpose
of
standardization.
We've
often
heard
that.
Well,
we
need
to
standardize
this
because
people
are
going
to
do
this
anyway.
Yeah,
please.
AP
Let
them
do
that,
but
don't
force
people
to
implement
things
by
giving
it
the
ITF
seal
of
approval
and
and
by
the
way,
I
I
sense
that
some
of
the
solutions
proposed,
but
probably
a
bit
incompatible
incompatible
with
your
analysis.
It
doesn't
appear
to
me
that
we
have
too
many
RFC's
that
aren't
implemented.
It
sounded
more
like
we
have
too
many
RFC's
that
are
actually
isolated
because
they
add
features
that
are
brought
forward
by
by
a
small
or
pretty
much
small
use
cases.
AP
The
bigger
issue,
though,
is
one
of
architectural
oversight,
and
that
is
something
that
sounds
nice
in
academic
environments
and
so
on
and
so
forth.
Maybe
it's
hard
in
reality,
but
one
of
the
problems
is
that,
and
we
see
that
in
the
political
as
well
in
the
technical
space
too
much
is
diverted
to
the
identifier
layer,
there's
too
much
done
with
the
DNS
that
would
belong
elsewhere
and
maybe
the
ship
has
sailed
or
the
horse
has
left
the
barn
or
whatever
the
image
in
your
favorite
languages.
But
this
needs
to
be
pushed
up.
AP
E
E
A
A
But
I
appreciate
you
doing
this
and
I
do
think
you
know
we
do
think
about
this.
The
TCP
folks
have
been
trying
to
approach
this
by
sort
of
redoing
793,
but
very
slow,
piecemeal,
but
it's
not
sexy.
It's
like
no
one
gets
any
like
you
know
lauded
for
that
right.
It's
just
like
it's
the
most
ungrateful.
You
know,
unappreciative
work,
sort
of
thing
and
we
kind
of
I've
always
sort
of
wondered.
Is
that
what
DNS
has
to
do
at
some
level
and
nobody's
going
to
want
to
do
it
right?
A
They'd
rather
go
build
something
new,
because
that's
kind
of
cool-
and
you
know
I-
really
loves
you
sort
of
thing
so
yeah
I
appreciate
that
I.
Thank
you
for
this
and
I
think
people
did
enjoy
this,
and
so
thanks
for
sort
of
sort
of
you
know,
humoring
me
I
guess
in
some
ways
and
humoring
you
as
well,
so
thank
you
Bert.
It
was.
S
Matthias
making
it's
a
good
presentation,
I
felt
that
in
the
room
a
lot
of
people
agreed
with
some
of
the
points,
maybe
more
points
and
others
I
was
just
wondering
what
is
now
the
follow-up
action.
Are
we
just
leaving
it
here
or
is
there
maybe
some
force
that
we
can
resolve
some
of
the
issues?
I
think.