►
From YouTube: IETF101-ThursdayLunchSpeakerSeries-20170322-1230
Description
THURSDAYLUNCHSPEAKERSERIES meeting session at IETF101
2017/03/22 1230
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
We
are
the
Ayana
functions
operator
and
the
reason
that
we're
involved
in
this
is
because
rolling
the
KSK
for
the
root
zone
is
part
of
the
Ayana
names
function
in
back
in
2010,
with
the
help
of
some
people
who
actually,
in
this
room,
hello,
Joe,
we
actually
rolled
the
key,
are
created
key
for
the
first
time
and
promised
the
community
that
after
five
years,
we
would
roll
the
key
and
we
proceeded
to
wait
a
little
longer
than
five
years.
You
know
say
after
five
years,
so
it
was
sort
of
after
five
years.
A
We
also
with
the
community
developed
the
KSK
rollover
plan.
We
actually
dragooned
a
bunch
of
the
community,
some
usual
suspects
from
the
DNS
technical
community
to
help
us
develop
the
KSK
rollover
plan
and
have
since
been
sort
of
executing
that
plan.
We
began
rolling
in
October
of
2016
because
of
the
way
we
do
things
with
the
route
KSK.
We
could
only
touch
it
on
quarter
boundaries,
so
every
quarter
we
would
do
something
new
and
just
before
we
were
about
to
use
the
new
KSK
and
anger,
we
decided
that
maybe
that
wasn't
the
best
idea.
A
I
can
does
a
few
other
things
you
might
have
heard
about
the
new
gTLD
program,
which
I'm
sure
is
incredibly
popular
within
this
community.
We
developed
eld
policy.
We
had
credit,
are
those
friendly
folks,
the
registrar's
we
actually
create
new,
our
our
IRS,
although
I
don't
think
new
continents
have
been
discovered,
so
the
chances
that
a
new
rir
will
be
created
or
is
probably
relatively
small.
A
We
do
allocate
blocks
of
addresses
to
the
our
IRS
and,
in
the
case
of
addresses
that
are
being
used
for
protocol
purposes.
We
allocate
it
directly
to
the
IETF
we
administer
the
protocol
parameter
registries
are
almost
2,000
of
them.
Cem
is
that
right,
like
2,000
ish
protocol
parameter
registries
yeah
there,
the
IETF
creates
them
and
we
administer
them.
On
behalf
of
the
IETF,
we
attempt
to
herd
the
cats
known
as
the
root
server
operators
through
an
organization
called
RS
sac.
A
We
have
no
control
over
the
root
server
operators
except
the
one
we
operate
in,
sometimes
I
wonder
about
that.
But
we
do
facilitate
the
discussions
among
the
root
server
operators
to
try
to
help
coordinate
the
root
server
system
and
a
few
other
things
I'm,
actually
not
going
to
talk
about
any
of
that.
More
than
all
I've
just
said,
the
accounts
ecosystem
were
actually
sort
of
three
parts.
There
is
the
community
which
I'm
sure
you
will
be
excited
to
know.
You
are
considered
part
of
the
ICANN
community.
A
There
is
the
organization,
the
folks
who
actually
do
stuff
and
the
board
the
folks
that
actually
tell
us
in
the
organization
to
do
stuff,
the
communities
so
they're
a
bunch
of
them.
This
I
charted
impends
to
create
very
interesting
presentations
that
you
can't
read.
So
I
will
try
to
explain
this,
so
it's
basically
a
set
of
different
parts
of
the
community
that
include
businesses,
government
and
governmental
organizations,
academia,
internet
users.
We
actually
have
we
attempt
to
provide
a
way
in
which
standard
everyday
Internet
users
can
provide
input
into
ICANN
policies.
A
Civil
society
is
that
domain
name,
businesses,
technical
communities
as
well-
and
all
of
these
are
folks
that
we
asked
to
provide
input
into
pretty
much
everything
we
do.
These
communities
actually
shape.
I
can
policies.
We
try
to
the
organization,
actually
tries
to
describe
these
policies
to
all
parts
of
its
community
so
that
they
can
participate
in
developing
the
policies
and
modifying
them
and
beating
us
over
the
head
with
them.
A
Predictably,
this
can
result
in
some
entertaining
discussions.
If
you
enjoy
watching
sort
of
demolition
derbies,
the
DNS
SEC
work
that
I
can
has
been
on
is
almost
entirely
community
driven.
We
have
had
extensive
community
input
on
signing
the
route
developing
the
jnanis,
a
policy
statement,
the
DPS
that's
used
for
the
route
we
have.
These
things
called
the
trusted
community
representatives.
They
are
folks
who
ensure
that
the
key
ceremonies
that
we
perform
are
done
in
a
way
that
everyone
can
trust.
A
As
I
mentioned,
we
have.
The
community
helped
us
extensively
on
the
development
on
the
KSK
rollover
plan
and
what
is
this
technical
community?
Well,
it's
folks
who
participate
in
the
DNS
op
working
group
here
at
the
IETF
folks
who
participate
in
DMSO
arc,
the
dns
operations
in
the
research
center,
I,
believe,
operation,
analysis
and
Research
Center.
A
There's
this
thing
called
the
DNS
SEC
deployment
mailing
list
that
has
been
in
an
operation
now
for,
like
a
decade
plus
has
a
bunch
of
usual
suspects
on
it.
The
various
DNS
SEC
related
workshops
all
over
the
planet
and
I
cans,
technical
advisory
committees,
including
the
security
and
stability
Advisory
Committee
and
the
root
server
system.
Advisory
Committee.
We
also
have
gotten
input
from
the
government
advisory
committee
and
the
at-large
Advisory
Committee
that
last
one
had
being
the
one
that
tries
to
present
the
views
of
Internet
users.
A
With
regards
to
DNS
fact,
most
of
the
input
we've
received
is
perhaps,
unsurprisingly,
coming
from
the
technical
community.
We
have
received
input
related
to
DNS
hack
from
business
community,
sometimes
and
others,
but
by
far
the
majority
of
input
comes
from
people
who
actually
pretend
to
understand
what
it
is
they're
commenting
on.
A
So
how
did
we
get
to
where
we
are?
The
route
has
been
signed
since
2010.
If
you
remember
way
back
when
a
guy
named
Dan
Kaminsky
came
out
with
a
really
cool
way
of
being
able
to
poison
caches,
the
DNS
SEC
would
actually
prevent.
So
there
was
a
mad
rush,
and
after
a
bit
of
screaming
and
pulling
out
hair,
we
ended
up
coming
up
with
a
way
of
signing
the
root
zone.
A
We
were
able
to
sign
it
in
July
of
2010,
after
which
I
promptly
resigned
and
went
into
death
valley
for
a
couple
of
days,
because
what
else
would
one
do
when
one
signs
the
route
things
went
along
reasonably
normally
and
in
2013
we
actually
started
the
process
of
developing
a
plan
to
roll
the
KSK,
the
truss
tanker
that
was
generated
when
we
signed
the
route.
A
slight
intermission
occurred,
something
called
the
transition
of
the
IMF
functions,
which
sort
of
took
the
oxygen
out
of
pretty
much
everything
that
I
can
did
for
a
couple
of
years.
A
But
after
the
the
transition
was
finished
and
September
30th
of
2016,
we
sort
of
jumped
back
into
the
KSK
rollover
and
proceeded
to
develop
through
community
input
a
plan
and
started
the
roll
over
in
October
of
2016
in
February
of
2017.
We
actually
installed
the
newly
generated
KSK
in
both
of
the
key
management
fills
facilities.
That
I
can
operates.
One
on
the
east
coast
of
the
US.
A
The
other
on
the
west
coast
of
the
US
in
April
of
2017
interesting
document
was
published,
RFC
81
45,
which
has
described
a
way
in
which
resolvers
could
inform
the
route
of
what
keys
were
actually
configured
for
the
KSK.
That
would
become
interesting
later
on.
In
July
of
2017,
we
published
the
new
KSK
into
the
route
for
the
first
time
the
packets
got
bigger,
nothing
broke.
Surprisingly.
Some
folks
figured
that
when
we
grew
the
size
of
the
DMS
response
from
the
route
that
bad
things
would
happen
turns
out.
No
one
really
even
noticed.
A
As
far
as
we
know,
we
didn't
see
anyone
screaming
an
outrage.
So
that's
how
we
assumed
success
when
we
don't
get
yelled
out
in
19th
of
September
2017,
the
DMS
K
response
increased
from
the
root
servers
and
then
on
27
September.
We
decided,
maybe
this
KSK
rollover
neat
thing
needed
to
be
stopped
for
a
little
while.
A
Why
did
we
do
that?
Well,
I
mention
81
RFC,
a
art
see
81
45
that
was
published
by
doing
Wessels
back
in
April
people
started.
Implementing
it
buying
had
had
done
an
implementation
based
on
the
draft
and
unbound
implemented
April
and
in
May
Duane
started.
Collecting
data
and
sort
of
something
interesting
happened.
Things
happen
the
way
they
should,
according
to
fifty
eleven
and
the
way
that
the
yeah
they
forgetting
the
word
when
we
transition
the
keys.
A
That's
not
the
right
word
but
that'll
work
for
me
now
and
we
notice
that
things
were
going
along
as
they
probably
should
have,
except
that
little
space
there
at
the
end
where
the
red
line
is
above
the
blue
line
indicated
that
not
everybody
was
migrating
over
to
the
new
key.
It
meant
that
some
folks
still
had
only
the
old
key
configured
and
that
blue
line
is
actually
even
weirder.
A
That
means
that
people
were
pre
configuring,
the
new
key,
even
though
it
wasn't
in
use,
which
meant
that
their
resolvers
would
fail
everything,
because
the
new
key
wasn't
actually
being
signed.
But
you
know
it
happens.
It's
the
internet.
We
I'm
surprised
everyday
when
it
I
wake
up
and
it
still
works,
but
that
percentage
there
where
things
were
not
where
they
should
be,
where
it
was
above
zero
and
did
not
seem
to
be
going
down
made
us
a
little
nervous.
Of
course,
I
was
planning.
A
You
know
when
I
signed
the
route
I
went
off
to
Death
Valley
after
that,
I
was
actually
planning
to
be
on
vacation
after
we
said
rolled
the
key
because
I
don't
want
to
be
around
when
breaks,
but
I
was
actually
in
the
O'hare
lounge
United
lounge
at
O'hare
and
I
called
up
folks
at
ICANN
and
said
you
know,
maybe
maybe
it's
best.
If
we
do
not
do
this,
this
ksk
roll
right
now
and
instead,
let's
just
postpone
it
for
a
while
and
see,
what's
actually
happening
and
figuring
out.
A
There
we
go
so
when
you're,
faced
with
an
unknown,
there's
sort
of
three
options
you
can
take
one
is
you
run
around
with
the
air
on
fire,
which
we
did
a
little
bit
of
to
stay
the
course
which
some
people
suggested.
We
do
and
three
try
to
figure
out
what
was
going
on
in
general
running
around
with
her
on
fires,
not
the
best
idea.
A
I've
tried
it
many
times
doesn't
seem
to
come
out
very
well
and
staying
the
course,
given
that
I
really
didn't
want
to
appear
on
CNN
and
time
and
that
sort
of
stuff
seemed
like
a
bad
idea.
So
we
decided
to
try
to
figure
out.
What's
going
on,
we
postpone
the
roll
over.
We
don't
aren't.
We
didn't
sign
with
20
the
KSK
2017,
yet
we
didn't
pull
it
out.
So
it's
still
there.
It's
still.
A
We
can
use
it
at
any
time,
modulo
a
test
that
I
happened
on
quarters,
but
we
decided
to
try
to
replicate
Duane's
results
and
we
did
so.
We
decided
to
further
replicate
goings
as
well
try
to
figure
out
exactly
what
was
going
on,
and
we
wanted
to
try
to
understand
why
so
many
resolvers
at
that
time
was
between
4
&
8
percent
of
the
resolvers.
We're
not
migrating
to
the
new
key
figured
we'd.
A
You
know,
informally,
consult
with
the
community,
develop
a
new
plan
to
allow
the
key
to
move
forward,
get
our
actual
approval
from
you
know,
sort
of
the
community
one
way
or
another,
because
in
the
previous
incarnation
we
had
sort
of
said
well.
We
agreed
to
roll
the
key
after
five
years
when
we
signed
in
2010
NTIA.
The
US
government
at
the
time
said
well.
That
means
that
you've
agreed
to
do
the
roll
over
after
five
years.
So
you
don't
need
any
additional
permission.
A
A
A
So
the
findings
that
we
got
back
from
our
from
our
friends
was
that
only
20%
of
the
IP
addresses
that
were
showing
up
in
these
80
145
announcements
could
be
tracked
down
and
60%
of
those
were
found
in
dynamic,
address
pools
which
doesn't
make
a
whole
lot
of
sense.
You
know
if
it's
a
resolver,
then
you
know
either
it's
serving
the
person
on
the
laptop
that
just
got
the
dynamic
address
or
it's
something
else
going
on
that
it.
We
didn't
fully
understand
and
it
looked
like
about.
A
25%
of
the
addresses
were
forwarding
from
other
resolvers,
which
meant
that
there
was
a
layer
of
indirection
that
would
be
very
hard
for
us
to
peek
through
we
didn't
find
a
smoking
gun
single
cause.
We
did
run
identify
a
couple
of
bugs
and
a
couple
of
resolver
implementations,
and
as
a
result
of
that,
we
didn't
really
have
a
clear
path
forward.
A
Since
we
didn't
have
a
path
forward,
we
decide
you
know
to
do
what
I
can
the
organization
does
when
we're
confused?
We
go
and
ask
the
community
hopefully
get
someone
to
tell
us
what
to
do
so.
We
actually
did
an
informal
collection
of
input
using
a
mailing
list
that
had
been
set
up
when
we
first
started
discussing
doing
the
KSK
rollover
cask
a
rollover
at
ICANN
org.
That
mailing
list
still
exists
if
you're
interested
in
these
sorts
of
things,
I
recommend
you
jump
on
it.
A
A
Results
of
the
discussion
on
that
informal
mailing
list
was
that
there's
no
real
way
to
measure
how
many
users
are
going
to
be
impacted
by
rolling
the
root
KSK.
The
information
we're
getting
is
sort
of
a
sample
of
resolvers
and
those
resolvers
are
actually
early
adopters,
because
the
only
code
that
has
the
8480
145
announcements
is
very
new
code.
A
It's
likely
that
better
measurements
will
come
along
in
the
future,
something
called
KSK
Sentinel,
which
is
wandering
its
way
through
the
DMS
op
process.
Right
now
does
look
like
it
could
provide
us
with
information.
That's
actually
from
the
end
users
perspective,
and
that
would
be
very
helpful,
but
that's
going
to
take
a
little
while
the
consensus
on
the
mailing
list
was
that
we
should
just
roll
the
key.
A
You
know
we
acknowledge
that
some
resolvers
are
going
to
have
issues,
but
you
know
that's
what
happens
on
the
internet
stuff
breaks
and
then
you
just
adjust
and
move
on,
but
in
order
to
try
to
minimize
the
amount
of
stuff
that
breaks
we
going
to
aggressively
outreach
and
do
these
kinds
of
talks
and
go
into
even
other
places
to
talk
about.
You
know
how
the
KSK
role
was
going
to
happen
and
all
that
sort
of
thing
and
all
the
same
time
we'll
continue
to
collect
data
so
on
the
topic
of
collecting
data.
A
So
these
trust
anchor
reports
right
now
we
have
access
to
data
from
almost
all
of
the
root
servers
ABCDEF
I
j
k,
l,
m
m
and
the
you
know
the
initial
analysis
that
we
had
done
came
from
BDNF.
The
initial
analysis
that
Dwayne
had
done
was
from
a
and
J,
but
all
of
the
the
statistics
were
more
or
less
sort
of
the
same.
We're
using
some
software
that
Dwayne
has
actually
developed.
It's
actually
really
nice,
and
you
know
that
gives
you
an
idea
of
sort
of
what
we're
looking
at
in
terms
of
the
data.
A
But
what
are
we
actually
seeing?
Well,
so
this
is
from
September
and
you'll
notice
that
there
was
a
bit
of
a
spike
and
that
spike
seems
to
have
studied.
You
know
around
20,
ish
percent
I'm
a
little
higher
than
that.
The
black
line
is
the
percentage.
The
red
and
green
lines
are
the
numbers.
If
you
look
on
the,
what
is
that
that's
dyslexia
is
a
joyful
thing
on
the
left
side
of
the
scale,
and
you
know
so.
A
You
know
it
went
up
from
about
4
to
8
percent
upwards
of
20
plus
percent,
which
is
also
a
bit
disturbing,
because
that's
the
wrong
way.
This
should
be.
You
should
be
going
down
not
up
why
the
jumpin
in
January
our
best
hypothesis,
is
that
there
was
a
completely
unrelated
security
fix
that
went
into
a
DNS
server
implementation
that
caused
people
to
update
their
DNS
server
invitation
and
that
resulted
in
more
80
145
announcements
because
it's
default
on
and
that
resolver
and
the
same
with
fine.
A
A
Well,
we
don't
know
one
of
the
thoughts
is
that
they're,
a
bunch
of
ephemeral,
virtual
machines
that
are,
you,
know,
sort
of
statically
configured
they
they
get
booted
up
and
they
have
the
old
configuration,
and
you
know
that
may
be
one
reason:
we're
seeing
all
these
2010
only
type
things.
But
you
know
we
don't
really
know
another
interesting
bit
of
data.
So
these
are
the
unique
IPS
added
per
day.
A
The
odd
bit
about
this
as
the
number
sort
of
stabilizes
yeah,
more
or
less
plus
5,
plus
or
minus
5
of
10
percent,
but
that
doesn't
make
a
whole
lot
of
sense.
Right
I
mean
you
know.
These
are
resolvers
that
people
are
sort
of
adding
you
know
when
they
go
and
update
software
and
something
like
that,
but
they're
sort
of
stabilizing
in
the
14th.
What
is
it
1415
K
per
day
of
new
IP
addresses,
and
that
is
odd,
because
it's
consistent,
it's
not
you
know
it's
not
going
up
and
down
enough
it's
not
going
up.
A
It's
going
anyhow.
So
another
thing
we
don't
fully
understand
cumulative
IP
addresses
over
time
and
that
you
know
that
line
there.
The
green
line
you
know
sort
of
in
a
very
nice.
Even
growth
is
weird
it.
You
know
it
shouldn't.
Do
that
really
there's
so
many
things
we
don't
understand
about
the
internet,
but
we're
talking
about
actually
a
pretty
good
chunk
of
unique
IP
addresses
at
this
stage.
We're
up
to
about
700
thousand
unique
IP
addresses
that
are
announcing
80
145,
and
we
recently
enough
about
a
third
of
those
are
reporting
only
KSK
2010.
A
Why
don't
know
it
could
be?
Forwarders
could
be?
You
know,
VMs,
as
we
mentioned
there
were
a
couple.
You
know
relatively
speaking,
1500
that
went
from
one
KSK
2010
only
to
2010
plus
2017,
which
is
the
right
thing
to
happen,
but
it's
actually
not
a
whole
lot.
It's
only
1500
out
of
seven
hundred
and
thirty
thousand.
So
that's
also
disturbing.
A
B
A
A
Okay,
so
these
are
folks
who
are
announcing
only
the
2010
KSK,
which
means
that
when
we
roll
the
key
these
folks,
these
resolutions
are
going
to
start
failing,
and
these
are
you
know
in
many
cases
these
are
customers
of
ISPs
right.
So
you
know
we
have
Comcast
they're
at
9,000,
unique
IP
addresses
this
isn't
Comcast
itself,
you
know
Comcast,
you
know
they're
operated
by
some
really
intelligent
folks
and
do
a
really
good
job.
It's
folks
behind
Comcast,
you
know
people,
you
know
business
clients,
presumably
or
something
yeah.
You
know.
A
A
C
C
D
A
Okay,
yes,
that
that
is
a
known
aspect.
I,
don't
say
flaw,
but
an
aspect
of
81
45
that
there
is
no
mechanism
by
which
we
can
assure
these
aren't
spoofed,
and
it
could
be
very
well
be
some
four
hundred
and
pound
person
and
their
back
basement
sending
80
145
queries
for
the
road
just
to
screw
with
us.
That
would
really
depress
me,
though
so
what's
happening
next,
we're
gonna
continue
to
try
to
figure
out
what's
going
on,
but
we
do
have
very
limited
data.
This
has
been
a
real
challenge
for
this
exercise.
You
know.
A
You
know
they're
not
a
lot
of
good
communication
channels
into
this
community,
because
they're
resolver
operators
and
anyone
and
everyone
can
run
a
resolver
I
use
droid
on
we're
on
one
on
my
laptop
and
if
you
know
some
weirdo
called
me
up
and
said
you
know,
what's
your
your
trust,
anchor
I'd
probably
get
very
nervous.
So
this
is.
This
has
been
a
on
going
challenge,
but
we
are
you
know.
What
else
can
we
do
we're
going
to
get
continued
to
try
to
figure
out?
A
A
It's
part
of
the
I
can
process,
the
advisory
committees
represent
parts
of
the
community
and
they
will
provide
us
with
formal
they'll,
actually
provide
the
board
with
formal
advice
and
those
include
the
security,
stability,
Advisory
Committee
and
the
route
service
system,
Advisory
Committee,
and
then
we
are
going
to
request
formal
approval
from
icons
board
to
move
forward.
You
know
we
will
provide
them
a
briefing,
including
the
formal
advice
from
the
advisory
committees
and
all
the
data
that
they
are
able
to
eat.
One
of
the
interesting
aspects
of
this
is
I.
A
Can't
board
is
not,
as
perhaps
it
not
surprising,
fully
technical.
We
do
have
some
quite
technical
folks
on
ICANN
board,
but
we
also
have
non-technical
folks
and
ultimately,
it
will
be
icons
board
that
will
be
making
the
decision,
because
this
you
know
obviously
can
have
impact
on
both
the
internet
as
a
whole
and
I
can
as
an
organisation,
and
they
have
a
fiduciary
responsibility
to
the
organization.
So
they
get
to
take
the
bullet
on
this
community
assistance.
A
Only
ksk
2010,
the
folks
we've
been
speaking
to
are
the
regional
internet
registries
and
icons,
internet
service
provider
and
connectivity
provider
constituencies,
which
represents
some
number
of
fairly
large
telcos
and
ISPs,
and
you
know
we're
hoping
to
get
those
folks
to
work
with
their
customers
and
their
participants
to
update
the
systems
that
support
the
the
KSK
2017
and
try
to
tell
us.
You
know
why
things
are
happening.
The
way
they
are
because,
honestly,
it's
a
bit
confusing
we're
trying
to
figure
out
how
we
can
make
this.
A
A
As
part
of
the
informal
discussions
we
weren't
able
to
identify
any
measurable
by
criteria
by
which
we
would
say
yes
or
no,
so
we're
just
gonna
say
yes,
because
that's
what
we
do
we're
going
to
continue
doing
extensive
outreach.
You
know
as
much
as
we
can.
We
will
continue
to
publish
more
observations.
You
know
as
much
data
as
we
can
get,
and
you
know
if
people
have
ideas
on
how
to
interpret
that
data
or
other
ways
in
which
we
can
obtain
data.
We're
looking
forward
to
hearing
from
you.
A
Most
importantly,
we
have
a
public
comment
going
on
part
of
the
Ikon
process
is
that
we
write
up
stuff
and
then
we
throw
it
to
the
community
for
a
actual
public
comment
period,
sort
of
somewhat
equivalent
to
a
last
call
within
the
ITF
and
saying
you
know,
please
tell
us
what
you
think
provide
that
input.
So
we
are
in
the
process
of
that
public
comment
period.
It
ends
on
April,
2nd
and
I
strongly
strongly
request.
I
beg
I'm
begging
here
to
please
provide
input.
A
Is
the
plan
so
on
April,
2nd
that
the
kiss
came
with
sorry?
The
public
comment
will
end
we're
gonna
write
a
report
sort
of
trying
to
interpret
those
comments
and
we
will
in
May,
actually
asked
the
board
for
a
resolution
to
ask
s
that,
because
the
way
I
can
works,
you
gotta
ask
the
board
to
ask
folks.
A
We
can't
just
have
some
folks
directly
because
it's
like
him
and
our
sec
yeah,
sorry
that
was
an
accident
left
out,
so
we're
going
to
do
another
session
at
the
ICANN
meeting
in
Panama
trying
to
get
more
community
input
through
a
workshop.
Presumably
sometime
around
there
s
act
will
be
able
to
pry
the
input
back.
We
will
publish
a
final
plan
and
the
message
that
the
world
is
contingent
on
that
final
plan.
You
know
the
board.
We
will
tell
the
board.
A
Implications
well
so
in
on
October
11th
of
2018,
assuming
the
plan
doesn't
get
modified.
We
know
we
know
100%
certainty,
that
some
resolvers
are
going
to
break
them,
that
the
data
is
very
clear.
Resolvers
are
going
to
only
that.
Only
have
our
KSK
2010
when
they
trying
to
validate
stuff
that
signed
with
KSK
2017
are
not
going
to
work.
Even
I
know
that
currently,
that
number
is
between
20
and
30%,
but
we
don't
know
what
that
means,
because
we
don't
know
how
many
users
are
buying
those
resolvers.
A
We
believe
and
I
think
the
technical
community
believes
that
the
vast
majority
of
users
who
are
being
subjected
to
DNA
SEC
validation,
are
behind
very
large
resolvers
like
Google's,
Public,
DNS
or
Comcast
or
quad
9,
and
are
those
votes,
and
we
have
no
fears
about
things.
These
votes
are
are
actually
operated,
they're
not
going
to
screw
up
the
KSK
role.
We
believe,
but
that's
just
a
belief.
A
We
don't
actually
have
concrete
data
to
prove
that
at
this
stage,
just
as
an
aside
to
the
IETF
as
you're
developing
protocols
that
have
impact
on
say,
critical
infrastructure
and
be
really
good
to
have
measurement
points
within
those
protocols,
so
that,
when
you're
in
a
point
where
you're
actually
going
to
be
mucking
with
the
critical
infrastructure,
they
can
actually
measure
things.
So
just
as
a
future
aside,
that
would
actually
be
something
that
would
be
nice
to
think
about.
Instead
of
how
we've
done
it
with
the
NSF,
which
is
added
later
really
I.
A
Don't
need
that
now
keep
getting
these
announcements
on
my
computer.
It's
a
final
decision
by
ICANN
board
will
be
non-technical
because
we
don't
have
the
data
to
give
the
board
to
make
a
technical
decision,
and
if
it
was,
if
we
did
have
the
data,
then
they
wouldn't
need
to
make
the
decision,
because
the
technical
data
would
say
what
we
should
do.
So
the
board
will
be
doing
a
risk
benefit
analysis
on
limited
data.
A
One
of
the
reasons
the
public
input
is
so
important
is
they
the
board
is
going
to
need
to
take
in
the
input
from
the
community
to
help
in
their
decision
making
processes,
so
how
you
can
help
if
I
haven't
terrified
you
with
the
idea
of
DNS
SEC
validation,
be
really
helpful.
If
you
would
turn
it
on
making
sure
that
you
support
KS
k
wall
really
and
tell
your
operator
network
friends,
you
know,
maybe
in
a
sec,
is
a
good
thing
to
turn
on
validation.
A
It'll
all
work
out
just
make
sure
you
support
that
in
KS,
k,
2010
2017
provide
input
to
icon
on
this
public
comment
associated
with
KS
k
role.
It's
been
open
now
for
about
20
days,
25
days,
something
like
that
month
and
a
half
a
while.
It
closes
on
April,
2nd,
so
they're
11
days
left
to
date.
We
have
seven
count
them
seven
comments
and
I.
Think
most
of
them
are
in
this
room.
A
Yes,
they're
all
in
this
room,
I
think
so
it
would
be
useful
to
have
more
or
input
you
know
and
if
you're
repeating
stuff
that
other
people
have
said
and
that's
fine,
that's
helpful.
That
neo
shows
that
there's
more
people
than
just
the
usual
suspects
who
believe
the
KSK
world
should
continue.
If
you
think,
maybe
it
shouldn't
continue.
That's
really
useful
information
as
well.
I
do
know
that
some
folks
are
going
to
come
out
against
the
KSK
role.
That's
fine!
We
just
need
that
input
and
that
again
is
the
URL.
A
E
A
F
Lost
Lehmann
from
that
note,
I
have
a
few
questions.
You
know
that
one
actually
came
in
later
slides
you
talked
about
dynamic,
ad
versus
and
use.
You
saw
queries
coming
from
dynamic
addresses.
Could
they
possibly
be
coming
from
homes
which
are
dynamically
allocated
on
cable
systems
or
fiber
systems
will
have
you?
A
G
This
works,
I
use
a
manual
and
we
we
got
them
in
two
ways.
One
is
the
unique
number
of
addresses
per
day.
So
basically,
we
literally
look
at
the
as
the
query
lakh,
who
were
dreams
and
range
to,
since
all
this
data.
To
that
query,
log
contains
all
the
unique
chart
contains
all
the
addresses
who
basically
counted
the
unique
addresses
per
day
could
and
we
a
community.
We
accumulate
over
all
letters
so
and
the
second.
The
second
thing
is
we
do
we
also
do
the
accumulated
part
where
we
have
a
day.
F
B
Thank
you
very
much
for
this
Jason
ITF
diversity
and
height
issues.
Thank
you
for
that.
One
possible
community,
David
I,
don't
know
if
I
can
speed
anything
about
beach
to
the
operating
system,
vendors
and
the
looks
destroy
people,
because
I
suspect
that
some
of
these
trust
anchors
are
being
embedded.
B
A
We
have
we
actually
very
early
on.
We
made
contact
with
the
guy
who
maintains
DNS
mask,
which
is
actually
the
most
commonly.
As
far
as
we
can
tell
embedded
DNS
related
thingy,
that's
put
into
CPE
he'd
indicate
he
said,
he's
never
gonna
support
50
11,
but
he
does
have
sort
of
a
separate
daemon
that
sits
there
and
goes
and
polls
to
see
if
the
root
ksk
has
changed
on
the
Ayana
website
and
then
pulls
it
down.
A
That
in
and
of
itself
makes
me
a
little
nervous
because
the
idea
of
millions
of
CPE
going
on
polling,
I
Anna's
website,
maybe
but
you
know
whatever
works
right.
So
at
this
stage
the
CPE
have
some
confidence
in
most
very
few,
as
far
as
I
know
actually
enabled
in
a
sec.
So
you
know,
obviously,
if
you're
not
doing
the
DMS.
A
call
of
this
talk
is
completely
meaningless
to
you.
A
With
regards
to
operating
system
vendors,
we
have
been
in
contact
with
the
number
of
Linux
distribution
folks
in
Red
Hat,
for
example,
the
pub
leader
was
actually
on
the
community
team
that
was
doing
this
yeah
and
he's
sitting
right
over
there
and
it
by
and
large
they've
been
supportive.
We
have
not,
to
my
knowledge,
interacted
with
sort
of
the
commercial
OS
vendors.
A
B
H
Paul
Hoffman,
co-author
of
81
45
81
45,
says,
don't
send
the
data
if
you're
not
doing
validation.
Now
we
don't
actually
know
that
they're
doing
validation,
but
we
know
that
there
was
a
chunk
of
code
that
was
hard
to
implement
that
if
they
were
doing
that,
they
shouldn't
have
done
it
if
they
weren't
validating.
Oh.
H
Yeah
so
you're
correct.
We
don't
know
that
in
we
did
actually
do
a
fair
amount
of
research
on
the
open
source
software
and
we
didn't
see
any
that
would
send
the
81
45
data
if
it
was
not
validating.
But
that
doesn't
mean
there
isn't
a
funny
configuration
because
we
did
find
some
funny
configurations
that
were
politely
not
called
bugs,
but
they
were
bugs
before,
and
so
there
could
be
something
like
that.
That's
not
what
we're
sort
of
assuming
gonna
have
to
close.
I
But
in
fact
the
architectures
changed
theirs
before
run
out.
This
carry
a
great
great
knack.
There's
a
general
workloads,
there's,
there's
all
kinds
of
overloading
of
addresses
and
services
that
there's
no
way
to
see
past
this
data
and
find
out.
So
the
fact
that
you
see
a
linear
increase
in
the
number
of
addresses
reporting
doesn't
necessarily
mean
that
you
see
a
linear
increased
number
of
resolvers.
It
could
be
the
same
population
of
resolvers.
Just
migrated
in
theory
has.
B
I
J
A
J
Have
second
account
the
privacy,
extensions
and
so
the
the
second
second
observation
is
regarding
this.
Those
IP
addresses
that
we
have
investigated
if
they
are
validating
or
not.
We
we
we
look
at
for
those
same
IP
address
his
overs
asking
for
DNS
keys
or
DS
records,
or
how
we
did
that
the
investigation
I
mean
it's
basically
for
Paul.
He
said
quick.
H
J
J
A
Yeah,
that
is
one
of
the
the
interesting
aspects
of
this
is
we're
getting
indications.
That
cannot
be
true
right.
So
clearly
the
data
as
I
said
the
more
we
look
into
that
data,
the
more
we
realize
that
that
data
isn't
actually
telling
us
anything,
that's
helpful,
and
that
is
the
sort
of
the
consensus
of
the
sort
of
the
expert
opinion
that
led
us
to
say:
okay,
we're
just
going
to
roll
the
key
on
18
on
11
October
2018,
regardless
of
what
the
80
145
data
says,
and
it.
C
So
thanks
Steve
for
coming
out
and
giving
providing
this
level
of
information
and
doing
this
kind
of
thing,
I
think
that's
really
important.
There
I
I
guess
I'd
have
two
things.
One
is
just
putting
my
marketing
communications
kind
of
hat
on
I
would
say:
I
would
encourage
you
to
look
at
how
to
focus
on
like
a
landing
page.
C
Like
you,
I
didn't
see
anywhere
in
there
you've
got
a
great
URL
I
can
dot
org,
slash,
KSK
roll,
which
drops
you
in
a
landing
page,
is
a
whole
bunch
of
stuff
and
I
encourage
you
to
push
that
rather
than
the
long
ones
that
go
across
there,
that
my
old
eyes
can't
even
read
on
some
parts
of
that.
So
I
encourage
you
to
do
that.
The
other
piece
is
I.
Think
the
one
of
the
things
so
last
fall.
I
gave
a
presentation
at
the
ISC
to
security.
Congress.
C
Talking
about
this
and
I
had
been
big
letters.
What
are
you
doing
on
October
11th?
It
was
great
and
it
was
the
day
before
you
announced
the
delay.
So
then
I
had
to
kind
of
go.
Oh
sorry,
but
the
there's
a
lot
in
the
enterprise
space
I
think
who
don't
they
had
no
idea
about
it
much
of
this
and
when
I
was
talking
to
them
and
they're
all
operating
large
private
networks
that
they
do
their
own
deus,
dia,
dns
lookups.
A
Okay
now-
and
we
have
tried
on
several
occasions
to
gothe
yeah
through,
like
the
CTO
forum,
the
CIO
forum
and
those
sorts
of
organizations
to
try
to
get
more
access
into
the
enterprise
communities,
but
that
is
a
very
large,
very
diverse
community
and
it
has
been
challenging.
But
thank
you
yes
and
just
roll
the
damn
thing
well,
yeah!
Well,
it
yeah
I've
heard
that
before
again,
thank
you
very
much
for
taking
the
time
and
listening
to
me,
ramble
on
just
you
know,
provide
input.
Please
thank
you.