►
From YouTube: IETF100-DNSOP-20171113-0930
Description
DNSOP meeting session at IETF100
2017/11/13 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
Still
a
little
tired
myself,
so
thanks
for
thanks
for
showing
up
for
Dina,
stop
in
Singapore,
it's
a
much
smaller
crowd,
but
I
kind
of
I
think
we
kind
of
expected
that
so
I'm
Tim
and
that
Suzanne
we
need
a
jabber
scribe.
If
so,
if
someone
wants
to
sign
up,
usually
mr.
York
is
really
great
at
that,
but
he's
not
here
so
if
someone
could
sort
of
own
up
to
some
responsibility.
So
no
so
I
have
to
find
somebody
I'm,
gonna,
Joe,
Thank,
You,
Joel,
short-hair
Joel
will
be
JavaScript.
A
So
we
thank
you
for
that
so
and
mr.
Hoffman's
taking
minutes.
So
he
may
ask
you,
for
your
name
or
for
better
spelling.
Do
you
use
the
etherpad?
No,
he
does
not
okay,
you
know!
Well,
since
it's
Monday
I
guess
you
haven't,
may
not
have
seen
the
note
well,
there
should
be
the
new
improved
one.
Please
take
a
look.
A
And
the
blue
sheets
are
going
around.
You
know
that
so
please
sign
fill
those
in,
so
they
know
how
many
people
we
need.
So
this
is
good.
It's
a
scurrilous
people
showing
up
I,
knew
they'd
all
show
up
like
9:45,
there's,
Jeff
and
Joe.
This
is
perfect,
so
yeah,
some
of
the
gender
bashing,
some
document
updates.
We've
got
some
current
business
and
some
some
new
working
group
business
to
go
through
since
our
last
meeting.
Basically,
the
one
thing
that
sort
of
came
out
was
the
TLD
problem
statement.
A
Draft
got
published,
which
was
sort
of
a
long,
arduous
process
and
I
seem
to
have
a
I
seem
to
have
a
great
preview
fail
there.
So
in
working
group
last
call
we
have
two
documents
that
basically
are
expired,
but
we're
waiting
on
the
author's
to
update
their
drafts,
the
all
TLD
one
there
are
some
stuff
that
they
have
to
get
and
to
refuse
any
draft
which
Joe
has
promised
me
twice
already
this
that
he's
going
to
have
an
update
this
week,
he's
gonna
fill
all
the
comments
in
we're.
Gonna
have
a
new
version.
A
Those
will
probably
do
like
another
1
week.
Short
working
group
last
call
too
just
to
deal
with
all
the
comments
to
get
the
new
stuff
page
back
in
that
would
be
for
both
of
those,
but
we
know
you're,
but
we
know
that
authors
are
busy,
so
we're
not
pushing
too
hard
next
on
the
workings
of
last
call
this
we're
kind
of
thinking,
one
of
the
things
it's
the
session
signaling
drafted,
which
they've
done
a
big
update
to
it's
got
a
lot
of
changes.
A
There's
been
a
lot
of
you
know
so
I
think
we'll
probably
need
some
folks
have
will
have
to
sit
down
and
really
do
some.
You
know
I
was
looking
at
the
diffs
and
most
of
it's
just
textual,
but
I
think
you
know
it's
gonna.
Take
us
some
want
to
sort
of
go
through
that
during
working
good
last
call
and
the
outer
leaf
draft
mr.
A
Crocker
I
know
is
not
here,
but
he
has
assured
me
that
once
he
folds
in
the
comments
he's
gotten
from
the
application
folks
he's
gonna
resubmit
it
and
get
it
back
in
the
in
the
queue
and
I
think
that
one's
ready
as
well.
So
he
just
said
it
was
busy
other
things
that
we
have
adopted
that
were
current,
probably
not
going
to
talk
about
today.
First
of
the
a
name
draft
which
got
a
lot
of
good
discussion
in
Chicago
and
even
in
Prague
I
think
there
are
a
few
outstanding
items.
A
I
think
the
big
thing
is
that
is
the
online
signing.
Is
the
sort
of
Deena
stuck
issue
the
TCP
requirements
draft
which
people
seem
to
like
we're
gonna,
have
to
sort
of
push
that
a
little
bit
to
see.
If
we
can
get
some
comments
and
we've
talked
to
were
to
talk
to
the
author
about
maybe
spending
a
new
version,
but
that
may
be
pretty
close
as
well
and
service
Dale
David
has
sort
of
folded.
A
A
We're
not
too
alarmed
by
this,
because
we
definitely
we're
dealing
with
a
backlog
initially,
and
we
know
that
authors
get
busy
right.
We
all
have
jobs
and
we
also
reduce
stuff
and
I,
take
August
off
and
that's
just
the
way
it
goes
so
we're
will.
Probably
this
is
the
time
here
we
start
to
get
some
more
spun
back
up
on
stuff,
so
you'll
probably
see
a
lot
more
stuff
getting
pushed
through.
A
B
A
Here
all
week,
exactly
though,
and
of
course,
I
Paul's
been
keeping
our
document
list
up
to
date,
I'm
turning
to
what
we're
working
on
and
we're
sort
of
he's,
keeping
us
on
track
so
current
stuff
for
the
current
working
group
business
when
I
talk
about
Paul's
got
some
good
updates
and
turn
ology
Biss,
because
I
think
we're
really
starting
to
get
close
to
working
group.
Last
call
on
that
as
well.
A
The
local
host
guys
aren't
here
the
the
ACP
people,
but
we're
just
going
to
sort
of
talk
about
it.
Briefly.
I
think
the
big
thing
there
is
I
think
the
big
thing
there
is
Adina
SEC
issue
and
Ray
wants
to
talk
about
xpf
briefly,
but
he
has
no
slide.
So
it's
okay,
some
new
stuff
fujiwara,
is
initial
additional
answers,
draft
which
is
kind
of
falls
into
the
whole
bin
of
multi.
You
know,
there's
a
big
pile
of
these
multiple
answer
type
things
and
it's
we're
gonna
have
to
I.
Think
that's!
A
Gonna
be
one
of
the
big
things
we're
gonna
have
to
sort
of
address
which,
which
way
we
go
and
I
went
back
and
I
was
looking
at
the
96
minutes
in
Berlin.
What
we
sort
of
talked
about
some
of
this
stuff,
and
it
seemed
that
we,
what
we
got
out
of
the
group
was
the
group
liked
asking
for
stuff,
rather
than
the
server's
telling
you
stuff.
That
seemed
to
be
the
big
consensus
right.
They
want
the
clients
to
ask
rather
than
a
service
to
push.
A
So
this
sort
of
that
seems
to
be
sort
of
the
guiding
principle
genie,
SEC
validated
requirements.
Jeff's
got
a
band.
The
KSK
role
that
looks
interesting.
Francis
has
the
update
for
2845
think
that's
something
that
will
probably
end
up
discussing
as
a
candidate
for
adoption.
There
I
was,
you
know
in
that
pipeline
and
Warren's
got
some
little
song-and-dance.
He
wants
to
talk
about
so
so
I
think
what
we'll
do
here
is
now
that
we've
covered
all
that
stuff.
It's
time
for
mr.
Hoffman
and
I
can
take
notes
for
you,
while
you're
talking.
C
Slide
edge,
yep,
okay,
so
hi
I'm,
Paul,
Hoffman
I
am
presenting
for
both
Andrew
and
cousin
Horry
terminology.
Biz
has
been
around
for
a
while
next
slide.
I
have
the
power
which
of
course,
the
first
thing
I
did
was
point
at
this
screen,
because
I
guess
I
could
do
this,
which
would
be
just
equally
as
dumb,
so
I
think
pretty
much.
Everyone
here
is
familiar
with
the
document,
we're
keeping
it
going.
We're
sort
of
hoping
that
at
some
point
we
can
finish,
we
did
the
O
7
draft
in
October.
C
What
has
been
happening
in
the
last
few
drafts
is.
We
will
get
one
or
two
people
to
say.
Oh
and
I
want
you
to
add
this,
or
can
you
change
this
one
little
thing?
We
do
it,
but
we're
not
really
hearing
much
from
the
working
group,
and
so
some
of
this
may
be.
Ok,
we're
all
tired,
let's
finish
it,
and
so
what
we
want
to
do
today
is
introduce
some
things
to
do.
One
last
push
and
then
go
to
working
group
last
call.
What
I
would
hate
to
see
happen
is.
C
C
We
would
like
to
get
this
one
out
so
that
they'll
have
something
even
better
because,
as
you
know,
this
is
a
fair
expansion
of
77
19,
so
anyways
with
that
here
is
a
list
and
you
don't
have
to
read
it,
but
here's
a
list
of
all
of
the
terms
that
have
either
been
added
or
significantly
expanded.
Since
we
started
the
this
work,
there's
a
bunch
of
them
and
it's
you
know
it's
easy
to
find
them.
This
is
a
shorter
list
of
things.
C
We
would
like
folks
to
focus
on
today
or
in
the
next
say
six
weeks
before
we
go
to
working
group
last
call
these
are
the
ones
that
have
changed
and
I'll
go
through
these
on
next
slide,
but
this
is
sort
of
again
we're
trying
to
get
focus
on
the
ones
that
we
think
people
might
actually
say.
Oh
yeah,
you
said
this,
but
I
want
you
to
change
it
this
way,
and
things
like
that,
so
Global
DNS,
private
DNS,
was
the
one
that
was
added
at
the
beginning
of
this
year.
C
One
of
the
questions
people
have
always
been
saying
is
well
what
is
the
DNS?
What
do
you
mean
by
the
DNS?
This
was
a
way
of
trying
to
give
focus
to
really
when
people
say
the
DNS,
which
they
really
mean
the
the
global
DNS.
What
is
that
and
for
those
who
people
who
didn't
want
to
talk
about
global?
Yes,
they
were
talking
about
a
private
DNS,
and
so
the
way
we
did
this
is
we
added
a
whole
bunch
of
facets
for
what
is
a
naming
system
and
then
said
for
the
global
DNS.
C
This
is
what
you
fill
in
those
facets.
There
was
a
lot
of
good
discussion
in
January
and
February
when
we
did
it,
because
we
sort
of
missed
on
a
few
things,
but
it
really
has
stabilized,
since
we
would
love
to
see
more
discussion
on
this,
because
no
one
has
bothered
to
really
describe
what
is
the
DNS
once
this
document
is
finished.
We
believe
that
this
this
one
or
this
pair
of
turns,
is
going
to
be
used
in
places
way
beyond
the
ietf.
So
let's
get
this
right
in
July
we
talked
about
the
in
Bailey.
C
What
can
out
of
bailiwick
stuff
and
bailiwick
confuses
a
whole
lot
of
people.
So
the
fact
that
we
changed
the
description
from
77
19,
anyone
who
has
ever
had
to
fight
with
baileywick
stuff.
Please
read
our
current
definitions
and
make
sure
that
they're
correct
in
the
last
version
of
the
document,
people
had
asked
us
to
revise
the
description
of
QED
nein
and
we
have
this
script
discussion,
because
cue
name
is
actually
never
really
defined,
and
it's
done
by
example,
and
in
1035
and
then
later
there
were
different
examples
and
people
had
different
reasons.
C
So
we
want
to
make
sure
we
got
that
right,
the
term
recursive
resolver
the
way
we
had
used
it.
Originally
we
changed
at
the
beginning
of
the
year
and
we
hope
that's
right,
because
people
do
use
that
term
a
lot
just
a
couple
months
or
a
year
ago
we
defined
split,
DNS
split
DNS
is
a
funny
one,
because
many
people
would
say
there
is
no
such
thing
as
a
split
DNS.
The
DNS
is,
you
know,
always
one
way
or
the
other,
and
yet
many
people
have
products
that
use
split.
C
You
know
the
term
split
DNS
for
something
or
it
or
something
else.
So
we
want
to
make
sure
that
we
have
that
one
right,
because
split
DNS
is
something
that
customers
get
really
confused
about.
So
let's
make
sure
that
that
what
we're
saying
if
they
come
to
the
you
know
the
terminology
document
that
come
to
say
trust
anchor.
A
topic
I
could
start
talking
about
again,
but
you
don't
want
me
to
because
we
postponed
that
topic.
C
We
added
that
beginning
a
year.
People
still
have
some
issues
with
trust
anchor
being.
Is
that
the
key?
Is
it
not?
So
please
look
at
that
definition
and
then
validating
resolver,
the
last
one
on
the
list
we
just
added
a
few
months
ago.
So
these
sets
of
this
list
and
this
list,
if
any
of
those
tickled
your
fancy,
like
oh
yeah,
I've,
been
thinking
about
that.
Please
please
spend
time.
Look
in
the
current
draft
make
sure
we
got
it
right.
Editorial
comments.
Are
you
know,
given
that
this
is?
Is
a
document
of
definition?
C
Editorial
comments
are
really
really
appropriate.
I
mean
big
picture
comments
are
as
well.
You
yeah
please
go
ahead.
No,
oh
finish
your
slides,
okay,
so
I've
got
like
two
more
slides,
so
one
other
thing:
Tony
Finch,
when
we
were
discussing
RC
77
19,
wanted
us
to
add
a
couple
of
terms,
we're
about
ready
to
do
that
as
well,
and
these
are
terms
that
are
sort
of
have
been
danced
around
a
lot,
but
so
we're
gonna.
Do
that
and
then
here's
my
last
slide.
C
So
what
what
our
intention
is
is
discussion
today
and
such
like
that
we
will
put
out
a
new
draft
really
soon,
there's
no
reason
not
to
put
out
a
draft
in
the
middle
of
IETF
week
we're
going
to
start
threads
on
these
I'm,
not
sure
exactly
how
we'll
do
that
I
mean
well.
I
know
how
we'll
start
threads
I,
don't
know
if
we're
gonna
do
them
all
at
once
or
keep
them
separate,
but
I
want
I
want
to
have
everyone
have
an
opportunity
to
at
least
do
these?
B
D
B
D
C
So
one
thing
on
what
Suzanne
just
said
is:
if
you're
intimidated
by
looking
through
the
whole
document,
many
people
here
have
assistants
or
colleagues
or
bosses
who
think
they
know
a
little
bit
about
the
DNS,
but
should
know
more
any
of
those
people
really
could
read
the
entire
document
with
a
red
pen
in
their
handset,
even
on
one
saying,
I
have
no
idea
what
this
is.
That's
fine,
there's
lots
of
things
to
do.
C
E
Likes
me
over
Nick
today,
tea
two
things:
one
thing:
I'm,
volunteering
to
review
the
whole
document.
Thank
you
and
I'm,
trying
to
figure
when
I
get
a
colleague
to
do
that
as
well
and
the
second
one
something
that
I've
heard
is
a
term
a
couple
of
times,
and
it
confuses
a
lot
of
people
is
local.
Annie
casts
see,
is
local
any.
C
C
C
F
Wasn't
with
the
way
you
presented
the
name
issue,
because
there
was
a
poor
definition
of
true
name
in
the
original
RFC.
The
problem
is
that
it
was
changed
later
by
RFC
2308
on
the
discrepancy
between
the
two
was
noticed
only
long
time.
After
so
now,
we
have
to
decide
whether
we
walk
back
to
the
original
definition,
which
was
more
or
less
what
RFC
77
19
did
or
if
we
try
to
acknowledge
that
we
have
two
competing
definition
and
we
try
to
explain
that
there
is
this
on
that,
so,
basically
for
mm.
C
And
what
what
the
discussion
on
the
list
came
up
with
is
that
not
many
people
are
actually
using
the
new
definition
that
much
they
really
are
using
the
original.
So
do
we
say
oh
there's
a
new
one
and
and
try
to
get
everyone
to
use
it,
or
do
we
actually
define
it
the
way
that
most
people
using
it
and
acknowledged
that
some
people
are
using
this
new
one
as
well?
C
So
let's
try
to
get
the
words
right
on
that,
because
this
isn't
the
only
one
that
we
have
where
there's
a
situation
like
that,
where
there
was
a
definition,
there
was
a
refinement,
but
people
didn't,
you
know,
really
use
the
refinement.
We
can't
reject
it.
We
have.
We
really
should
talk
about
it,
but
we
should
be
honest
to
the
reader
that,
if
you're
reading
something-
and
it
looks
like
this-
understand
that
many
people
still
think
about
it,
this
way
yeah
great.
Thank
you
other
thoughts.
C
G
Hello
Paul:
this
is
Bill
Manning.
The
comment
that
I
will
make
here
is
that
terminology
like
language
is
not
static,
and
so,
as
you
try
and
pour
concrete
over
this,
it's
going
to
slip
out
from
underneath
you
and
people
will
come
up
with
new
terms
and
new
definitions.
As
things
go
and
people
are
going
to
point
back
and
you're
going
to
start,
you
will
not
start.
G
H
Co-Author,
my
name
is
Andrew
Sullivan
I
am
one
of
the
other
Stuckey's
for
this
and
in
response
to
Bill
I
I.
Don't
think
anybody
thinks
we're
pouring
concrete
here
right,
but
I
mean
what
you
just
described
bill
is
the
problem
of
writing
dictionaries
and
the
fact
is
that
we've
got
lots
of
dictionaries
despite
the
fact
that
the
language
evolved
so
I,
don't
think
there's
anything
different
here.
I
think
this
is
therefore
a
useful
thing
to
do,
even
if
it
does
change
afterwards
and
I
can't
tell
whether
you're
disagreeing
with
that
or
not
yeah.
C
So
and
again
we
already
have
77
19
and
we're
working
from
that
we
haven't
had
anyone
say
to
us:
you
shouldn't
have
done
77
19,
because
you're,
you
know
concretizing
anything,
one
of
the
things
that
that
we
want
to
emphasize
and
if,
as
you're
going
through
either
these
highlights
or
just
picking
a
term
when
we
quote
from
original
original
documents,
we
always
point
to
them
so
that
a
reader
might
actually
go
back
and
see
more
than
the
two
sentences
or
whatever
that
we're
doing.
Hopefully,
that's
that's
good
enough.
So
and.
A
The
main
team's
informational,
this
one
is
actually
trying
to
adjust
things,
I
think
you're
right,
I'm,
sorry,
I
mean
really
yeah.
Okay,
so
I
just
want
people
should
remember
that
sort
of
thing
right.
Also
you
put
January
15
through
that
I
think
is
a
very
good
day
sort
of
a
very
good
time
frame
to
basically
kick
off
a
working
group
last
call
yep.
C
So
yeah,
that's
our
goal:
we're
happy
to
delay
it
due
to
too
much
activity
on
the
mailing
list
and
again
that
would
be
a
working
group
last
call
which
could
take
a
while.
But
at
this
point
so
we
will,
we
will
start
threads
on
this
I.
My
guess
is
I'm
just
gonna
pull
a
number
out
in
my
hat
two
threads
a
week
or
three
threads
a
week
of
things
like
that.
But
if
this
talk
has
has
inspired
you
at
all
to
be
going
and
looking
go
ahead
and
start
without
us
right.
J
B
J
J
We'll
talk
about
in
a
minute
a
couple
of
quick
things:
edy
Lewis
provided
a
for
strong
comments,
one
of
which
was
that
he
doesn't
actually
think
the
documents
should
be
published
because
the
audience
of
the
document,
namely
the
operators
of
I,
can
have
not
participated
in
the
review
of
the
document,
not
really
sure
what
I
can
do
about
this.
Once
I've
had
a
lot
of
discussions
with
I
can
staff
and
I
know
they're
at
least
aware
of
the
document
whether
they
have
the
ability
to
review
or
no
not.
J
That's,
that's
a
different
sort
of
subject
that
I
can't
fix
right.
They
know
it
exists
and
they
can
review
trust
anchor
uses
just
incorrect.
I
agree
with
him.
Absolutely
it
was
incorrect.
I
went
through
and
looked
at
every
instance
of
the
word
trust
anchor
and
made
sure
that
it
was
used
and
changed
in
some
terminology.
So
it's
no
longer
trust
anchor
publisher,
for
example,
as
a
PEP
publisher,
which
is
I,
always
forget
what
PEP
means.
J
That's
the
standard
terminology,
it's
the
bit
in
the
DNA
SEC
key,
the
document
gettin's
to
co-mingle
validation
with
trust
anchor
management.
He
was
absolutely
right
about
that
too.
I
cleaned
up
that
terminology
really
well
on,
went
through
and
looked
for
every
word
of
the
word
validation
and
made
sure
that
they
they
applied
correctly
and
might
responds
back
to
him,
which
I
haven't
actually
sent
to
the
list
yet
will
be.
Please
tell
me
if
I
got
it
wrong
and
then
finally
not
worth
our
time.
J
One
of
the
things
about
this
document
is
that
there's
sort
of
a
low
return
on
investment,
as
he
said,
because
it's
it's
a
very
narrow
scope,
and
so
one
of
the
questions
that
will
come
up
to
in
a
minute
is
you
know,
is
this
important
it's
hard
math,
it's
not
exactly
easy
to
fully
understand.
Isn't
it
did
I
love
the
Mike
Harrods
back
hello?
It.
J
Well,
no
I
mean
I
was
I,
didn't
move
that
much
I,
think
it
clipped
out,
maybe
the
battery's
dying
anyway.
So
his
question
is:
is
it
worth
our
time
considering
it's
a
very
small,
you
know
target
and
in
our
view
it
was.
It
is
worth
the
time
because
it's
clarifying
an
important
detail
of
the
of
the
specification
that
people
don't
want
to
get
wrong.
J
He
thought
it
actually
looked
good
and
we
may
or
may
not
want
to
add
another
section
clarifying
whether
we
do
math
based
on
a
timer
kind
of
approach
or
a
wall
clock
based
approach.
The
current
document
not
yet
published
because
I
didn't
make
the
cutoff
actually
has
both
in
it.
So
I
think
that
that's
sort
of
the
right
consensus
to
come
forward
that
hopefully,
will
make
anybody
that
wanted
to
be
on
both
sides
of
the
equation
outcome
and
then,
finally,
there
is
comments
from
Mike,
st.
J
John's
timing,
one
you
know
when
is
it
safe
to
revoke
the
oldest
trust,
anchor
keys
and
sort
of
there's
a
there's,
a
timing
question
of?
Do
you
measure
it
from
now,
as
if
I'm
trying
to
do
a
sleep
until
that
right
time
or
do
you
measure
it
from
Purdue?
You
define
it
as
a
wall
clock,
in
other
words,
at
this
date
in
this
time.
So
now
the
current
document
not
yet
published
contains
both
the
and
then
the
the
other
big
question,
and
this
is
one
of
the
questions
I
have
for
you
today.
J
We
don't
have
a
lot
of
time,
so
I'm
only
asking
really
two
high
level
questions,
one
of
which
the
second
one
is
there
is
this
notion
of
network
delays
and
retries
and
failures
cause?
You
know
the
time
period
that
you
must
wait
to
be
longer,
and
so
the
question
is
the
math
gets,
of
course,
more
fuzzy.
When
you
add
in
this
you
know
flexible
time
and
there's
the
the
current
document,
you
know
has
a
two
times
an
hour
type
thing,
plus
a
little
bit
well,
that'll,
be
later
Mike
st.
J
John's
suggested
a
much
more
complex
thing
based
on
the
retry
integral
from
50
11,
which
ends
up
being
an
e,
did
I
lose
it
again,
come
on
hello.
No,
it's
not.
It
has
nothing
to
do
with
that.
I
haven't
moved,
it's
the
Mike
doing
so
now.
I
can
nope
that
one's
not
working
either
we
lost
all
the
audio
entirely.
Oh
there
we
go
yeah,
that's
not
good,
and
so
somebody
might
want
to
notify
the
audiovisual
crew,
because
something's
definitely
broken
anyway.
So
Mike
st.
J
John's
has
a
fairly
complex,
even
more
complex
bit
of
math
to
base
it
on
based
a
safety
factor
on
the
retry
integral
from
50
11,
and
do
so
many
retry
intervals
depending
on
you
know
how
many
resolvers
are
out
in
the
world
and
you
know
whole
log
end
kind
of
approach.
I
won't
go
into
the
math,
but
that
it
actually
made
sense
I
understand
why
he
picked
it.
The
end
result
is
the
wreath
at
the.
The
safety
factor
could
go
up
to
something
like
28
days
and
in
the
minimum
case.
J
If
you
went
with
that
approach
so
really
quickly,
one
of
the
things
I've
done
is
I
restructured
the
document.
So
this
is
the
old
version
and
all
of
the
timing
is
in
there
and
there's
all
these
math
and
so
to
talk
about
the
the
piece
where
I
broke
down.
The
document
into
the
math
terms
are
now
at
the
top,
and
then
there
are
different
sections
for
the
wall.
Timer
the
wall.
Timer
I
can
do
this
really
the
wall
timer
based
calculation
and
the
wall
clock
based
calculation.
Excuse
me
the
weight
timer
and
the
wall
clock.
J
J
So
here's
the
real
question
in
my
mind,
big
question
number
one:
should
this
be
published
at
all
so
during
last
call,
but
so
it
was
adopted
by
you
know,
with
fairly
good
consensus
at
one
point,
as
time
has
gone
on,
the
math
looks
ugly
right.
It
actually
got
worse
as
we
realize
that
there
was
more
problems
than
your
original
thought.
There's
more
terms
that
had
to
go
into
the
math,
and
so
during
last
Karl,
Paul
Hoffman
said
yes.
Mike
st.
John's
gave
a
lot
of
comments
that
even
made
at
one
point.
J
You
know
a
suggestion
that
this
brought
some
new
concepts
into
his
eyes
that
he
hadn't
thought
of
before,
but
didn't
actually
say
whether
what
his
opinion
was,
and
that's
just
fine,
you
don't
have
to
have
an
opinion.
Ed
Lewis
is
very
much
against
it.
He
thought
it
was
actually
authored
by
the
wrong
people
was
sort
of
one
of
his
kin
census
points
and
then,
of
course,
the
authors
and
I
agree
that
it
should
be
published.
One
and
I
think
it
should
be
published.
J
K
George
Michaelson,
ap,
Nick
I
think
this
is
a
useful
slide
to
leave
up.
While
we
have
a
conversation
because
he
it's
a
talking
point
that
I
think
should
not
be
just
brushed
away.
This
was
the
stopping
point.
Yes,
I
I
have
sympathy
with
some
of
where
Ed
is
coming
from,
but
there
is
a
moment
in
my
heart
where
I'm
thinking,
if
you've
got
a
document
adopted
in
a
working
group,
the
hands
on
the
pen
are
much
less
important
than
the
voices
speaking
or
writing
words
for
submission
I
can't
take
seriously.
K
It
complained
that
the
wrong
hands
had
editorial
ship
I
can't
he
has
to
be
saying:
I
wanted
different
words
for
that
to
have
substance
and
then
we're
back
in
the
conversation.
Well,
what's
the
substantive
difference,
so
it
feels
like,
if
he's
really
saying,
no,
it's
not
about
the
hands
on
the
pen.
It's
about
the
nature
of
the
materials
in
the
document.
That's
got
to
be
the
matter
of
substance,
or
this
is
just
a
ludicrous
observation.
K
All
right.
Thanks
very
much
for
this
I
I
have
a
second
one.
Please
anything
you
can
internet
process
technology.
That's
about
the
cluster
of
things
that
are
talking
to
some
central
agents,
frequently
measured
in
thousands
of
events
per
second.
That
then
has
complex
mathematics,
defining
timing,
boundaries
that
are
measured
in
days,
multiples
of
8,
6,
4,
double
o
seconds
multiplied
by
double
digits.
I
struggle
with
the
complexity
of
the
maths
you
need
to
set
a
number
there
frankly
pick
one
and
see
is
as
good
as
a
complex
mathematical
formula.
J
So
before
you
walk
away
because
I
want
to
clarify
that
rate,
which
was
that
it
was
written
as
defining
the
minimum
point,
so
it's
not
a
recommendation.
It's
written
as
a
lot
of
people
were
getting
this
wrong
when
they
were
talking
about
it
and
they
were
actually
picking
time
less
than
the
minimum.
So
it's
that's
why
it's
not
written
as
a
recommendation.
The
recommendation
and
maxing
Jones
can
talk
to
in
a
minute.
Is
you
shouldn't?
You
should
have
multiple
keys
and
you
should
be
doing
it
for
nine
months
and
longer.
This
is
talking
about.
K
L
I'm
a
little
concerned
for
his
chair
stability
I
also
very
much
think
that
we
need
this,
that
it
should
be
advanced.
We
have
a
lot
of
very
recent
operational
experience
of
the
things
that
can
go
wrong
with
people
that
thought
they
were
doing
501
one
right,
and
so
it's
surprising
to
me
that
this
is
even
a
question
that
we
wouldn't
be
seeking.
Greater
clarity
in
it
and
I
also
have
to
concur.
I
mean
I
love.
L
J
M
Thank
you
for
your
opinion.
Joe
Joe,
ably
so
I
also
think
this
should
be
published
because
I
think,
even
though,
as
it
turns
out,
we
probably
only
really
care
in
the
grand
scheme
of
things
about
fifty
eleven
with
one's
own
in
the
entire
DNS.
We
also
know
it's
kind
of
a
pain
in
the
ass
when
people
really
can't
tell
what
people
are
doing
or
implementations
might
behave
differently,
so
I
think
it's
important
to
specify
I
assume
you
have
other
big
questions
on
subsequent.
J
M
Safety
margin,
and
so
it
should
be
included
in
I,
have
an
on
number
big
question
comment,
which
is
that
you
took
something
that
is
complicated
and
in
response
to
Mike's
and
John's
comments,
you
now
have
kind
of
made
it
more
complicated
by
duplicating
it
into
different
in
two
different
senses.
Two
different
visualizations
one
wall
clock
went.
All's
that
to
me,
is
worse
than
choosing
one
of
them,
because
now
you
have
two
different
things:
that
there
are
bound
to
be
corner
cases
where
they
disagree,
and
then
you
can't
tell
which
is
normative,
I
think
it's
better.
M
M
O
It
scares
me
I'm,
gonna,
say
this,
but
neo
channeling,
heed
I'd
suspect
the
his
main
concern
was.
He
believes
that
operators
should
have
more
input
on
this,
as
opposed
to
Adina's
protocol
geeks,
so
I
I
believe
it
should
be
published.
You
know,
despite
the
fact
that
works
for
somebody
who
works
for
me,
but
I
think
it
would
be
helpful
if
more
folks,
who
are
directly
involved
in
the
operations
of
this,
would
actually
be
able
to
weigh
in
and
say,
Edie
you
ignorant
or
something
along
those
lines
and
I
class
myself.
J
P
So
I
actually
believe
this
should
be
published
at
some
point
along
the
way.
I
just
wanted
to
get
right.
The
route
did
two
things
that
I
didn't
contemplate
when
I
wrote
fifty
eleven
and
one
of
them
was
the
single
trust,
anchor
steady
state
and
the
second
one
was
something
that
came
up
as
we
were
going
through
this
last
iteration
of
early
public
of
early
signatures
of
things
that
might
actually
make
it
into
the
wild
turns
out.
J
P
P
J
P
J
No
I
made
sense
to
me
that
the
tricky
part
for
me
is
whether
we
should
include
some
sort
of
factor
or
not,
and
you
know
whether
you
deal
with
network
delays
and
retries
or
not
I've
heard
opinions
on
both
sides.
I
honestly,
don't
care
I
just
want
to
do
what
the
community
wants
and
I
I've
heard
both
sides.
So
consensus
has
been
hard
so
far,
Eric
Eric.
Q
Eric
Osweiler,
so
I
just
want
to
sort
of
really
quickly
pollen
I
think
this
is
really
good
to
publish
I
think
if
nothing
else
documenting
what
people's
ideas
and
perspectives
are
on
different,
rolling,
timers
and
semantics,
just
as
a
publication
is
really
useful.
You
know
like
looking
back
at,
like
all
the
cue
rollers
that
happened.
It's
nice
to
be
able
to
say:
oh,
this
guy
must
have
been
thinking
this
way
that
Gore
must
been
thinking
that
way.
Q
J
Thank
you
very
much,
yeah
from
a
from
a
historical
perspective,
I
like
publishing
stuff,
so
that
people
making
new
work
based
on
fifty
eleven
you
know
has
sort
of
the
math
behind
it.
So
the
last
question
I'm
going
to
say
that
we
can
go
to
the
list
if
everybody
could
open
their
mail
readers
and
just
write
to
the
list
as
to
whether
you
think
there
should
be
a
safety
margin
factor
or
not,
there's
not
exactly
a
clear
understanding
of
whether
people
want
that
or
not
so
you
don't
have
to
look
at
the
math.
J
A
J
Sort
of
weigh
in
on
that
as
well
right.
So
speaking
with
my
root
operator
hat
on,
we
published
the
data
from
I
Anna
and
to
a
large
extent,
because
of
that
we
don't
necessarily
concern
ourselves
with
the
timing
associated
with
what
I
can
actually
and
I
Anna
work
together.
So
they
may
have
opinions,
but
it
doesn't
actually
hit
them
over
the
head
as
much
as
you
might
think.
Okay,.
J
All
right
so
either
both
mics
go
out
at
once
or
on
either
all
right.
So
next
up
is
extended
errors,
and
so
we
brought
this
up.
It
got
approved
after
I
think
after
Chicago
or
now
after
Prague
as
a
as
a
working
group
document,
this
one
should
be
a
quick
one
to
push
through
the
group,
there's
not
a
whole
lot
to
put
in
it
other
than
possibly
a
list
of
errors.
J
You
know
that
we
could
publish
about,
but
the
reality
is
is
that
I
Anna
can
handle
that
fine
and
it
doesn't
necessarily
need
to
be
in
the
initial
document
as
we
as
we
go
forward.
I
did
not
even
try
and
alphabetize
those
name,
so
that's
actually
a
random
order
of
names
and
bubbled
in
my
head
is
a
random
sort,
so
just
ignore
the
ordering
there.
J
So
we
we
sent
it
a
question
to
the
working
group
a
while
back
about
one
of
the
things
we
heard
back
during
the
call
for
adoption.
Is
people
wanted
ranges
of
error,
codes,
kind
of
like
HTTP,
like
everybody
knows
you
know,
404
and
and
that
that
leading
number
in
HTTP
indicates
a
different
type
of
error.
So
we
took
that
and
thought
about
it.
J
But
the
thing
is:
is
that
DNS
adds
a
little
bit
of
complexity
to
it,
because
we
already
have
a
return
code
type
or
a
and
art
the
our
code
actually
already
gives
some
sort
of
error
and
then
so
the
question
is:
do
we
align
the
secondary
error
code
with
the
art
code
or
not,
and
things
like
that?
So
here
are
four
options
that
we
spelled
and
we
got
no
feedback
on
the
mailing
list.
J
So
first
question
to
you
today
is:
what
do
you
think
so
the
choices
are
basically,
we
could
do
individual
codes
for
the
existing
draft,
in
other
words
sequential
one.
Two
three,
four
five,
six
based
on
you
know,
codes
that
we
come
up
with
number
two
and
the
draft
was
existing
Li
defined
as
DNS
SEC
bogus
and
then
to
support
error
code
ranges
like
we
heard
feedback.
We
had
three
options,
and
this
is
where
either
you
give
us
feedback
or
we'll
pick
one
how's,
that
one
is
a
32-bit
code
filled
with
integer
ranges.
J
Oh,
so
you
know
it
was
a
great
suggestion
going
forward
and
then,
when
we
actually
tried
to
put
it
in
an
implementation,
it
looked
a
little
bit
more
messy,
so
32-bit
code
field.
Number
three
is
the
other
option.
Where
there's
a
sixth,
where
we
copy
the
16-bit
our
code
into
the
e
DNS
zero
spot
and
then
add
another
16-bit
sub
code,
so
that,
for
example,
0
0,
0
2,
which
is
again
serve
fail
straight
copy
and
0
0
0
1
becomes
DNS
SEC
bogus
and
you
combine
those
together
and
you
get
some
very
long
integer.
J
But
the
hex
looks
clean
and
then
finally,
as
a
16-bit
code,
which
is
basically
the
same
thing
as
that,
what
I
just
talked
about,
but
you
leave
the
ER
code
where
it
is,
and
the
error
code
has
to
be
a
subtable
from
the
our
code.
So
you
know
our
code
would
still
be
0.
0
2
and
the
the
error
code
would
be
0.
0
0
1
serve
fail,
DNS
tech
bogus,
but
only
when
the
our
code
is
0
0
2.
J
So
you
can
see
that
that
great
suggestion
turned
into
like
a
a
mess
of
options,
and
so
this
is
my
question
to
you.
What
do
you
want
to
do
about?
You
know
this
set
of
choices
and
does
anybody
you
know,
or
maybe
more
people
think
that
we
should
go
back
to
sequential,
because
it
gets
really
messy.
When
you
start
thinking
about
our
codes.
C
Paul
Hoffman
wearing
my
HTTP
hat.
The
whole
idea
of
the
first
number
means
something
and
the
subs
underneath
failed
miserably
over
and
over
people
got
it
wrong.
People
would
spend
months
arguing
whether
this
new
error
was
supposed
to
be
under
400
or
500.
Subs
like
that,
just
ignore
that
it
like
it
was
a
cute
idea
and
I
would
say
that
at
least
3/4
of
HTTP
people
would
say
it's
been
a
harmful
waste
of
time.
People
look
just
to
the
number
so
to
me
that
would
go
towards
4
and
as
excellent
feedback
from
that
group.
So.
F
Maya
I
think
he
did
someone
try
to
see
for
all
the
possible
error
code
if
there
were
specific
to
us,
given
our
code
or
not
today
in
the
draft
are
things
like
this
extended.
Our
code
should
be
used
only
with
self
l,
but
is
it
really
a
case
where
you
can
have
an
extended
error
code
that
as
a
knowing
for
different
possible
errors,
I,
don't
think
so,
and
then
it
would
not
necessary
to
put
the
code
in
the
extended
well.
J
So
there
are
certainly
some
errors
that
cross
multiple.
Our
codes.
I,
don't
know
whether
sir
fail
is
one,
for
example,
but
and
so
yeah
you're
gonna,
run
into
issues
where
there's
there's
a
collision.
This
fall
was
just
saying
we're
you
know
some
errors
might
need
to
be
in
both.
So
maybe
you
reserved
zero
zero.
Two
four
you
know
for
both
serve
fail
and
for
other
stuff,
but
so
I
know
I.
Have
we
haven't
done
a
huge
amount
of
work
in
that
area?
M
M
J
R
E
E
My
suggestion
is,
we
could
think
about
adding
to
the
IANA
registry,
where
we
have
T
extended
our
codes
to
add
a
list
of
allowed
our
codes.
We
switch
that
extended
arrow
can
be
used,
which
in
turn
means
that
we
will
probably
change
at
least
as
soon
as
we
introduce
a
new
our
code
each
time.
But
it's
sort
of
like
a
little
bit
between
can
I
use
this
with
that
and
avoid
come
that
don't
make
much
sense.
Yeah
it's
a
little
bit
of
middle
between
30
and
completely
independent,
extended
our
codes
right.
J
Yeah
so
you're
you're,
basically
proposing
a
list
of
our
codes
or
a
list
of
error
codes
combined
with
what
our
codes
are
usable
under
and
if
you
get
something
that
doesn't
match.
That
combination,
which
was
just
brought
up
a
second
ago,
then
then
that's
a
different
error
right.
There's
an
error
error
amid
error,
yeah
all
right!
So
again,
you
know
this
post
is
on
the
list.
If
you
want
to
go
back
and
respond
to
it
directly,
the
authors
would
definitely
appreciate
more
feedback.
J
Oh
my
and
number
four
is
means
means
a
sub
registry
for
all
the
current
ones,
correct
yeah
it
would
be
a
lookup
table,
so
the
our
code
would
be
the
first
item
in
a
lookup
table
and
this
the
second
16
bits
would
be
the
second
item
in
our
code
table.
How
are
we
on
time?
Yep,
okay,
so
there's
basically
three
other
questions
that
we
had.
J
These
actually
haven't
gone
to
the
list,
because
we
were
waiting
for
responses
to
the
last
question
with
that
we
never
got,
but
basically
a
couple
of
things
one
can
we
include
more
than
one
error
code
or
information
code
as
we
might
want
to
call
it,
and
it
was
there
any
reason
to
prevent
this.
I
mean
the
you
know.
The
protocol
would
support
it
and
there
doesn't
seem
to
be
a
reason
that
we
have
in
our
mind,
as
you
know
why
this
would
be
necessarily
a
bad
thing
to
do.
J
But
if
you
have
a
bad
thing
to
do,
you
know
why
it
would
be
bad
to
include
more
than
one
informational
sub
packet
speak
up.
Please
and
the
other
question
is
what
should
a
forwarding
server
do,
and
this
is
a
little
more
tricky.
So
when
a
forwarding
service,
they
really,
you
know
if
they
go
off
and
do
this
request
for
you
and
they
get
back
an
ATS
0
extended
error
packet.
J
Should
they
always
send
it,
never
send
it
or
send
it
only
if
it
believes
the
client
can
handle
it
and
how
you
make
that
determination
would
be
up
to
code.
Of
course,
and
then
finally,
security
errors
are
unauthenticated,
there's
been
some
people
that
have
talked
about
well,
but
you're,
getting
back
a
section
of
a
packet
which
isn't
signed
by
anything.
So
it's
fudge
able
should
because
they're
unauthenticated
you
know,
should
they
even
should
this?
Should
this
document
even
exist,
because
we
have
no
way
to
secure
it?
J
Is
there
anything
we
can
do
and
then
there's
been
some
notion
of
well,
but
they're,
just
informational
in
the
first
place,
it's
more
likely
that
it
would
just
and
a
user-defined.
You
know
message
somewhere
or
something
like
that.
So
that's
there's.
We
don't
have
really
good
answers
for
any
three
of
these.
We
would
be
happy
to
make
stuff
up
because
we're
good
at
that,
but
we'd
prefer
to
have
your
opinion
so
that
we
could
make
stuff
up,
and
then
you
can
yell
at
us
later.
If
we
get
it
wrong.
F
Stephane
bought
my
optic
for
the
security
thing.
Yes,
that
is
an
obvious
thing
we
can
do
is
to
use
DNS
over
TLS,
because
typically
it
will
be
used
for
stub
to
resolve.
Oh,
we
have
a
standard
for
DNS
or
TLS
on
now
we
have
even
a
standard
to
authenticate
Zoey's,
although
it
has
been
approved
one
hour
ago.
So
it's
it
seems
to
me
the
obvious
solution
for
this
suite
a
problem.
That's.
J
True,
although
the
the
deep
ray
of
DT
DNS
over
TLS
solution
was
really
resolver
to
recursive
and
that
doesn't
deal
with
things
like
forwarders
and
things
like
that
so
well,
but
but
or
to
a
to
authoritative
z--
for
that
matters
all
right,
but
it
sort
of
nothing
yeah,
but
it's
coming,
I
think
you're
right,
so
Erik
I
think!
That's
you
all
the
way.
In
the
back.
There.
Q
J
Q
Sorry,
mr.
PICU,
this
Eric
person,
yes
I,
was
gonna,
say
something
similar
to
what
you
said
and
I
hate
to
disagree
with
Stefan,
but
I
think
the
security
concern
is
something
I
was
going
to
jump
up
and
say
something
about
and
in
general
I
think
it's
probably
ok.
As
long
as
you
define
these
codes,
you
think
about
what
sort
of
advisory
and
what
would
actually
prompt.
You
know
a
security
action.
In
other
words,
if
I
get
this
code
and
it's
gonna
cause
me
to
retransmitted
or
make
a
decision
or
whatever
then
yeah.
Q
The
lack
of
authentication
is
a
big
deal.
If
it's
something
that's
you
know
evidence
that
just
you
know
gives
me
an
indication.
Just
think
that
through
is
you
define
the
codes.
I
think
some
of
the
codes
might
be
more.
You
know
reasonable
than
others,
but
to
just
disagree
with
the
TLS
thing.
That's
transport
security,
and
this
is
about
like
a
sort
of
an
object,
so
they're,
they're,
probably
composable
but
I'd,
say
that
they're
they're
kind
of
different,
so
I
wouldn't
try
to
use
transport
security
to
secure
an
object
like
a
Datagram
that
comes
back.
S
J
Well,
so
the
reason
that
we
don't
have
flags
because-
and
we
thought
about
that
for
a
while,
but
the
reality
is
we
expected
to
find
more
than
16.
So
the
number
of
flags
gets
very
long
and
we
could
do
things
like
the
weird
insect
flagging.
You
know
where
you
skip
large
sections
of
zeros
and
stuff,
but
you
know
the
question
is
this:
which
is
better
more
flags
or
you
know
when
you
may
only
define
one
or
two
or
more
error,
edie
and
s0
blocks,
which
take
up
even
more
bits.
M
M
It
seems
to
me
that
what
we're
talking
about
is
exactly
transport
and
not
objects.
By
definition,
objects
are
things
in
the
data
model
which
assigned
at
the
place
that
they're
generated
before
they're
published
we're
talking
about
codes
that
correspond
to
the
movement
of
those
objects
between
servers,
which,
I
think
is
all
transporting
so
I.
Don't
understand,
Eric's
comment
that
this
is
about
object,
security
and
not
transport
security.
Well,.
J
So
that's
a
really
good
question,
but
the
question
my
return
question
is:
are
we
only
defining
stuff
that
our
air
that
our
transport
errors
specific
for
imagine
you
know,
imagine
an
authoritative
server
that
has
an
error
to
return.
I,
don't
know
what
it
might
be
so
well
whoa.
We
won't
name
it
that
has
to
return
it
to
the
resolver,
which
is
actually
supposed
to
go
back
to
the
client,
and
then
it
becomes
an
object
that
is
passed
from
top
to
bottom
I
guess
I
mean.
M
Yeah,
it's
just
one
really,
really
brief
sort
of
further
exploration,
the
one
that
seems
that
the
are
code
that
seems
like
it
corresponds
to
the
data
model
is
the
name
error,
because
an
object
either
contains
a
name
or
it
doesn't.
But
that's
why
we
have
an
N
SEC
record
which
is
signed,
so
you
don't
rely
on
the
Transport
Security
do
it.
You
do
have
object
security.
In
that
case,
all
the
rest
of
my
think,
our
exactly
transport
yeah.
J
Q
A
F
J
A
All
right
since
the
HTTP
people
bailed
out
on
us,
we
just
they
wanted
just
to
sort
of
talk
about
localhost
for
a
minute.
I.
Think
the
one
ounce
and
the
item
and
going
through
all
this
stuff
on
the
mailing
list
is
the
DNS
SEC
thing
so
and
unless,
if
someone
thinks
there's
other
stuff
out
there
and
please
correct
me
sort
of
thing,
so
we
just
wanted
to
know
if
people
had
any
opinions
on
how
they
want
to
dress
it
in
the
draft.
B
It's
worth
keeping
in
mind
that
if
people
feel
very
strongly
that
this
name
needs
to
be
signed,
that
means
going
back
into
the
swamp
of
whether
to
ask
for
a
delegation
in
the
route.
So
we
would
want
very,
very
clear
guidance
as
the
chairs
to
forward
a
document
that
suggested
that
should
be
done
and
I
see
our
ad
at
the
microphone
yeah.
T
Looking
further
at
what
I
think
the
correct
behavior
of
this
is,
and
I
did
summarize,
that
in
an
email,
I
think
that
the
current
response
from
the
route,
which
is
n
X
domain
correctly
reflects
what
the
semantics
of
this
should
be.
So,
basically,
the
whole
section
of
the
text
would
I
had
suggested
they
put
in
and
kind
of
wrote
in
as
I
cared
to
stick.
The
sudden
that
sounds
good
should
probably
all
just
be
scrubbed
out,
and
you
know
the
DMS
does
the
right
thing
anyway.
Okay,
thanks
bye,.
J
Okay,
Wes
hurt
occur,
agreeing
with
Warren
in
a
different
way
in
the
ITF.
We
we
keep
having
this
belief
that
the
DNS
is
the
only
naming
system
and
it's
like
you
know
if
it,
if
you
get
a
n
X
domain
or
you
get
us
a
serv
fail,
because
it's
do,
you
know
sec,
you
know,
failing
that,
it
doesn't
exist
and
the
reality
is.
We
know
that
that's
not
true,
there's
that
there's
a
huge
trend
of
enterprises
that
have
named
trees
that
don't
exist
outside
and
if
you
ask
the
externals,
you
know
DNS
service,
for
it.
J
They're
gonna
give
you
back
an
NX
domain
or
an
error
because
it
doesn't
exist.
The
reality
is
is
that
we
have
been
dealing
with
multiple
naming
systems
since
the
dawn
of
time
within
a
switch
and
a
whole
bunch
of
other.
You
know
things,
including
YP,
you
know,
or
whatever
the
name
of
that
service
was.
J
We
know
how
to
do
deal
with
that
on
the
end
host,
and
so
you
know,
maybe
local
host
should
always
be
one
27001,
and
if
so,
if
we
think
that
that's
true
and
callin
:
one,
then
we
can
publish
it
and
sign
it,
but
the
reality
is:
if
the
value
might
change
on
every
system,
then
you
can't
sign
it.
It
just
doesn't
make
sense,
and
even
you
you
know,
even
if
you
signed
a
delegation
to
nothing,
and
so
no,
this
is
outside
the
DNS.
In
my
mind,
that
doesn't
make
it
wrong.
T
V
A
V
V
We
had
a
lot
of
feedback
in
the
last
meeting
about
the
privacy
aspects,
we're
still
potentially
looking
for
some
text
on
that
from
the
people
are
really
strong
on
the
privacy,
but
we
have
having
the
new
version
of
the
draft
added
new
text
specifically
bans,
stub
resolvers,
recursive
resolvers
and
any
client-side
middleboxes
from
transmitting
on
xpf
are
are
inside
a
packet.
Obviously
we
can't
actually
stop
anybody,
but
at
least
the
draft
makes
it
clear
that
this
is
not
intended.
V
There's
now
a
presentation
format
defined
for
the
RR
initially
I
said
in
the
draft
that,
because
this
is
a
measure
RR,
but
there
was
actually
no
need
for
a
presentation
format,
though
it's
pointed
out
that
actually
field
debugging
packets,
it's
still
useful
to
be
able
to
display
one.
So
that's
not
going
to
find
in
the
draft
I've
updated
the
t6
text
so
that
you
can
clear
and
now,
whereas
the
XPS
record
is
supposed
to
be
added
to
the
packet
and
typically
I
should
be
after
any
TC
record.
V
That
appears
so
the
TC
is
not
actually
calculated
over
the
RR
cigarettes
or
over
the
tea
soup.
Seasick
record
is
calculated
over
the
xbf
record,
as
xpf
record
was
tagged
on.
The
end,
then,
is
stripped
off
by
the
server
before
handling
any
TC
calculations,
so
I
should
verify
the
packet
again.
We
feel
this
is
adequate,
because
the
record
is
only
supposed
to
be
communicated
between
two
trusted
systems
are
on
the
same
network,
so
we
thought
the
security
aspects,
laughter,
okay,
those
really
the
changes.
V
So
it's
a
very,
very
short
draft
and
like
getting
even
more
feedback
and
hopefully
get
where
I
should
call
for
adoption
and
get
this
progressed.
There
is
already
an
invitation
out
there
in
DNS
dist,
at
least
on
the
proxy
side
of
that
and
I'm,
not
sure
the
paradise
guys
aren't
here,
but
they've
also
been
from
that
infest
that
on
the
server
side
of
parody
NS.
But
we
want
to
get
spunky
on
a
code
point
and
get
the
draft
adopted.
B
So
how
many
people
have
read
the
draft?
That's
pretty
good
I
think
it
would
be
good
to
have
a
couple
of
one
or
two
people
to
review
and
make
sure
you
want
to
ask
the
working.
You
know
you
have
a
clear
path
forward
for
the
working
group
to
adopt
it.
So
do
we
have
one
or
two
volunteers
to
work
with
Rea
on
reviewing
those
and
making
sure
that
maybe.
V
V
V
A
Yeah
and
I'd
say
you
know,
barring
any
sort
of
large
negative
feedback
we
we
would
probably
kick
off
a
call
for
adoption
sometime
in
December
and
just
see
where
things
go
right.
You
know
and
and
we're
the
chairs
aren't
against
that
unless
there's
violent
outbursts
here
in
the
room
about
that.
So
as
I
watch
mr.
yeah.
V
V
A
W
W
W
N
W
Are
common
backgrounds,
Dean
standards
allow
for
supplemental
information
to
be
included
in
the
education
section
with
the
audience
response
existing
Houston
implementation
already
add
a
mixed
media
exchange
or
Marik's
exchange
or
a
salary
target,
and
developers
knows
we're
under
the
u.s.
state
guarantees
that
Jesus
records
will
be
accepted
or
cashed
by
RFC
2181
section
five
point
four
point:
one
ranking
data
and
the
politic
resolvers
account.
Since
aside
no
data
in
X
domain
response,
it's
using
cached
in
sec
or
nz3
records
by
RG
eighty
one,
ninety
eight.
W
W
This
is
my
proposal
assure
our
answers
answers
also.
It
is
evening
service
austerity,
results,
use,
query,
answer
and
I
shall
records
payers
instruct
proposed
Couto
payouts
and
to
increase
the
probability
that
these
external
recalls
extra
date
will
actually
be
useful
for
is
or
bots.
The
query
has
dinosaur
DNA
coach
a
bit
set
and
assured
records
are
signed
by
Dina
sake.
Our
records
may
contain
insects,
insects,
three
errors
for
the
query
and
other
related
names.
W
Responses
with
I
shall
recalls
fit
in
required
response
sites,
and
these
are
good.
I
shall
answer
periods
for
name
a
query.
Actual
answers
may
be
named
quad
day
or
name
in
sick
insects.
Three
for
name
cadre,
query
assurances,
maybe
a
or
name
in
sick
in
64,
Nahor,
name,
MX,
query.
Unshod
answers
may
be
exchanged
a
cot
day
under
insects,
insects,
3.
This
is
already
implemented
for
name
a
suruÃ
query
target.
Our
answers
may
be
matrix
a
target
host
a
cot
day
and
second
SEC
3
under
for
name
a
name
called
a
query.
W
W
Cadre
for
free
proposal,
cardio
free,
propose
I
shall
cut
the
in
as
a
sectional
II
to
change
it,
be
any
standards.
I
think
and
molecule
much
corresponds.
It's
proposed
a
proposed
pseudo
are
our
contours,
I
shall
are
ours
and
I
shall
unsub's
proposals
develop
path,
choose
action,
are
ours
and
adding
insects
in
sick
or
in
sexy
sauce
records
and
the
March
March
queue
type
struct
proposes
new
in
zero
new
new
himself
of
shown
doctor
it's
a
shark.
You
types
and
accompanying
questions
draft
proposals,
New
Eden
syrup
shown
not
to
carry
a
shark.
A
B
B
J
Line
at
the
microphone
life
is
good,
hard
of
course,
I'm.
One
of
the
authors
of
the
multiple
responses
draft
to
and
and
I
think
that
youth.
In
my
mind,
there
are
three
places
where,
where
multiple
answers
may
come
from
right,
one
is
the
client
asks
additional
questions,
so
there's
some
of
those
fit
that
the
multiple
responses
draft
has
been
talking
about.
Well,
what
if
the
server
has
data,
so
in
other
words
the
the
administrator
knows
that
has
stuff
or
there's
automatic
analysis
to
determine
I
can
be
smarter
than
the
client.
J
The
server
was
smart
and
thought
it
was
a
good
idea,
or
the
administrator
of
the
server
was
smart
and
created
config,
regardless,
whether
it's
another
magical,
art
type
or
not.
So
so,
I
guess
consider
that
and
we'd
be
happy
to
to
do
a
merge
on
our
end,
I
think,
or
at
least
a
couple
of
us
that
talked
would.
X
We
have
to
look
at
the
minimal
response,
size,
that's
kind
of
things,
but
we
are
happy
to
well
I'm
happy
to
help
you
and
to
work
out
on
this
work.
I.
Think
it's
a
very
good
proposal
and
well
liked
very
well.
We
would
like
to
work
with
you
on
that
or
not
to
make
it
to
implement
it
in
our
resolve
presenter
and
to
push
the
draft
forward.
Thanks
I.
Y
Was
smoking
from
IC
in
mind?
We
are
actually
moving
away
from
having
large
responses
and
going
towards
minimal
responses.
Where
we
only
answer
the
question
very
pertinent
ly,
we
don't
add
any
extra
luggage
to
the
to
the
answers,
pons
response
message
now
there
are
two
ways
of
sending
additional
responses.
One
is
for
the
server
to
think
what
is
right
for
the
client
to
have
and
for
the
server
to
hand
out
whatever
it
thinks
is
right
for
the
trying
to
have
the
other
way
to
do.
Y
Y
Multiple
multi,
cue
types
idea:
I,
don't
think
it's
a
good
idea
for
the
server
to
add
whatever
it
wants
to
the
response,
the
reasons
that
the
server
has
to
do
considerable
work,
internal
queries
into
its
own
database
to
add
additional
things
to
the
answer
response
that
takes
but
takes
time
basically,
and
if
it
adds
something
to
the
answer
and
the
client
eventually
ends
up,
throwing
it
away.
It's
wasted.
Work
so
I
think
it's
better.
The
client
requests
what
it
wants
and
the
silver
just
gives
it
what
it
wants.
That's
it.
Z
This
is
one
gray
from
I,
see
whatever
actually
I'm,
also
a
big
proponent
of
the
many
more
answers.
But
what
I'm
missing
from
all
those
proposals,
or
maybe
I
just
remember-
is
some
analyzes
what
we
are
actually
saving,
because
adding
additional
answers
is
increasing
complexity
and
it's
increasing
complexity
in
the
injury's
overcoat
and
in
in
a
stub
resolver,
possibly
as
well,
and
it
increases
the
packet
sizes
increasing
the
GTO
Specter.
So
basically,
what
I
would
like
to
see
its
analyzed?
It's
a
free
world
data
from
some
resolver,
for
example.
Z
If
if
this
like
safe
in
the
latency,
is
actually
outweigh
the
risks
of
larger
responses
and
an
additional
complexity
in
the
cold,
because
I
well
I
more
fear
the
additional
complexity
in
the
code,
because
that's
it's
always
easier
to
throw
away
like
everything
in
the
additional.
If
you
not
have
asked
for
it,
just
because
of
the
security
reasons,
because
you
might
miss
a
corner
case
and
and
your
cache
get
gets
poisoned
and.
Z
And
the
other
thing
is
that
in
your
draft,
this
is
for
resolver.
Well,
if
you,
if
you're
talking
about
alterative,
sending
multiple
responses
to
resolver
again,
is
this:
is
this
really
helpful
because
this
only
helps
with
bootstrapping
or
domains
that
have
really
really
low
TTL?
Because
after
that,
it's
already
in
the
cache
and
for
stop
to
stop
tour
is
over
I'm
hoping
that
the
war
will
be
moved
to
DNS
over
TLS
everywhere.
Z
R
Favor,
knowing
them
so
I
think
all
of
this
is
solving
a
zero
dot,
zero
dot,
something
person
problem
because
most
of
the
stuff
in
resolvers
and
DNS
is
cached
and
I
gave
a
talk
about
how
effective
it
is.
If
you
look
for
the
top
100
domains,
you
have
cache
hit
rates
above,
say,
99%
and
DNS
set
in
this
is
simply
not
existent
I
mean
so
for
the
vast
majority.
This
doesn't
give
you
anything
and
I
said
it's
complexity.
In
the
code,
so
I
mean
there
are
I,
think
other
things
we
should
work
on
in
this.
L
Dave
Lawrence
Akamai
I
want
to
acknowledge
a
Ralph's
point
that,
yes,
cache
does
have
a
tremendously
large
effect
here,
but
as
for
example,
the
happy
eyeballs
project
by
Apple
is
shown.
Is
it's
really
not
a
sufficient
answer
to
wanting
to
know
multiple
types
at
one
time
and
as
Wes
and
I
have
discussed
in
the
past
the
multi
cue
types
and
multi
responses,
slash
additional
answers
and
slightly
different
problem
spaces.
L
L
A
client
can
ask-
and
you
know
positively,
whether
the
server
that
you're
asking
supports
the
option
or
not
and
then
can
move
forward
based
on
that
information,
whereas
additional
answers
not
only
demands
DNS
SEC
in
order
to
function
effectively,
but
also
really
it
for
a
client
to
understand
whether
the
server
did
it
is
a
kind
of
you.
Don't
have
a
good
signal
there.
If
the
server
doesn't
actually
support
it.
W
AA
First
slide:
yes,
so
for
this
issue
there
are
now
have
a
fire,
a
final
drought,
so
the
they
it
improves
their
this
working
group
is
very
interesting,
is
how
pika
so
may.
In
future,
we
use
some
energy
to
Southeast
Asia,
so
we
can
choose
to
choose
well
proposal
or
solution
or
combines
is
different,
a
solution
together
to
make
her
a
new
solution,
so
so
Fujiwara
already
so
every
night
nights
right.
AA
Yes,
so
already
have
a
good,
her
childhood,
the
demonstrator,
the
Kemper,
a
shovel
proposals
in
nice
table.
We
may
analyze
them
in
depth,
so
choose
choose
one
solution
or
compare
different
solution,
so
I
my
comments,
so
it
hit
improves.
This
working
group
is
very
interested
in
this
topic.
Oh
thank
you.
AB
B
AB
N
There
was
something
sir,
not
discussed
in
Berlin
I
think
it
was
also
a
comparable
portal
from
from
Warren
about
this
kind
of
thing,
and
there
was
a
promise
made
then
that
more
data
would
be
gathered
and
presented
to
the
working
group.
So
we
could
make
some
objective
decisions
about
that.
As
far
as
I
know,
that
data
has
never
been
presented.
So
maybe
we
need
to
try
to
go
back
to
those
first
principles
and
do
some
analysis.
N
Just
one
has
been
suggested
because,
although
I
think
that's
a
good
idea,
I
think
we
still
need
to
figure
out
the
cost-benefit
analysis
here
in
terms
of
both
the
quick
complexity
and
expose
you
to
things
like
amplification
attacks,
I'm
very,
very
concerned
about
the
prospect
of
adding
more
needless
data
into
response
and
then
amplifying
them
a
deep
data
coming
back
and
then
using
that
for
all
sorts
of
nasty
DDoS
attacks.
If
we
don't
have
to
say
next,
data
back
are
still
not
going
to
give
us
a
clear
beat
through
optimization.
Why
do
it
I
I.
A
Went
back
and
read
the
Berlin
minutes
the
other
day
and
basically
the
consensus
that
came
out
of
that
room
was
people
like
the
clients
asking
rather
than
servers
telling
right.
But
but
there
are
in
some
cases
like
with
the
MX
and
the
SRB,
where
you
know
do
it,
they
just
send
all
of
it
because
they
know
it's
gonna
be
used
kind
of
thing
so
and
I
can
dig
up
the
Berlin
minutes
again,
but
yeah
you're
you're
correct.
We
that
seem
to
be
the
consensus
coming
out
of
the
room.
Basically,
at
that
time,
okay,.
N
G
Bill
Manning
I,
look
at
this
and
I
think
this
is
the
lovely
menu
for
an
attack
profile.
We
have
increasingly
complex
code
in
both
server
and
client.
We
have
extra
bandwidth
utilization.
We
have
much
more
data
being
pushed
around
that
may
or
may
not
be
used
based
on
the
assumptions
of
one
side
or
the
other.
The.
M
Joe
amply
I
think
it
is
actually
worth
including
the
additional
column,
which
is
what
we
do,
so
they
send
parallel
queries
and
if
the
only
concern
with
that
is
that
it
takes
more
bandwidth,
then
really
we
have
to
remember
that
the
amount
of
bandwidth
is
actually
used
by
queries
is
already
almost
zero.
Compared
to
the
amount
of
bandwidth.
We
had
a
provision
for
all
the
rest
of
the
chef
that
arrives
to
the
servers,
so
it's
free
and
it
requires
no
code
changes
and
no
changes
in
any
expectations
and
no
drafts.
AC
AC
So
if
we
are
proceed
decide
to
proceed
on
the
multiple
response
we
we
need
to
consider
about
the
transport
issues,
especially
in
ninety
six
environment,
because
there
I
think
they're
wide
discussions
on
these
issues
and
many
people
view
of
every
six
is
not
very
workable
for
the
large
DNS
response.
So,
if
ya,
in
the
context
of
this
draft,
and
that
the
multiple
multiple
response
so
is
it
possible,
it
was
of
considering
to
think
about
the
transport
issues
yeah.
Thank
you.
AD
B
C
D
C
B
What
we're
hearing
is
a
lot
of
interest.
You
know,
as
a
couple
of
folks
mentioned,
we're
hearing
a
lot
of
interest
in
this
general
problem
space.
We
do
have
a
couple.
We
do
have
several
drafts
that
are
either
competing
proposals
or
complimentary
proposals,
and
it's
a
little
bit
hard
to
tell
which
I
mean
this
this
chart
is
is
very
good
to
that
point,
and
thank
you
for
doing
this,
but
I
think
the
comments
we
heard
that
there
is
there's
still
some
more
discussion.
B
We
need
I
think
that's
absolutely
true,
and
what
I
it's
it's
a
it's
kind
of
a
moving
target,
but
what
I'd
like
to
start
with
is
use
cases.
What
problems
do
any
of
these
proposals
solve
that
people
actually
have
and
that's
when
we
can
start
to
sort
out,
are
these
things
worth
doing?
Are
they
worth
additional
complexity?
Are
there
security
considerations
that
will
need
to
be
mitigated
or
managed,
but
first
we
have
to
what
I
heard
at
least
and
Tim
can
twist
my
arm
if
I'm
confused
here.
A
B
Because
it
because
this
sounds
like
what
we
need
to
do
is
have
people
be
able
to
say
which
of
these
proposals
they
like
or
don't
like
and
and
and
why
and
I
heard
Wes
offering.
Perhaps
a
combined
draft
I
think
it's
a
little
bit
too
soon
to
say
that
that's
necessarily
where
we
want
to
go.
But
please
keep
that
in
mind,
because
if
it
turns
out
that
these
drafts
are
complimentary
as
far
as
solving
related
problems,
that
might
very
well
be
a
direction
we
want
to
go.
A
And
we'll
probably
start
will
do
a
lot
of
that
based
on
this
table,
and
so,
if
people
think
like,
oh,
there
needs
to
be
another
line
in
the
table.
That
says
that
finds
X,
Y
or
Z
sort
of
thing
right
or
we
think
this
is
wrong,
or
we
think
this
is
great.
I
think
this
is
fairly
accurate.
I
think
you
know,
you've
marked
some
stuff
in
red
that
you're
not
sure
about
and
I
think
you
know,
but
if
people
think
oh,
this
is
incorrect.
A
You
know
please,
let's
you
know,
because
this
is
a
very
good
way
for
people
to
actually
quickly
see
where
all
the
places
sort
of
get
tweaked,
tweak'd
sort
of
thing
so
and
I
just
remember,
going
back
and
reading
all
the
Berlin
minutes
and
all
the
various
comments
about
stuff.
That
was
the
thing
it
took
me
a
little
bit
to
sort
of
wind
through
so.
V
Yeah
rave,
Alice,
I,
see,
and
certainly
the
table
does
need
some
work,
for
example,
the
result
of
modification
table.
Currently
this
a
nice
big
Green's
on
the
first
two
there
shouldn't
be
no,
there
should
be
not
applicable
because
those
two
proposals
don't
actually
give
recursive
resolve
the
support,
thanks
for
starting
up
to
help
fix
that.
Okay.
V
L
Dave
Lawrence
Akamai
I'm
recommending
that
Ray
work
on
it
anyway.
I.
Don't
see
that,
though,
that
subjectivity
is
a
real
problem
here,
I
mean
we
all
have
our
vices.
We
all
it's!
It's
not
like
we're
involved
in
some
kind
of
fiscal.
You
know
fiduciary
responsibility
thing
here:
we're
trying
to
come
up
with
the
best
proposal
and
so
advocating
for
your
proposal.
I
think
is
a
perfectly
valid
part
of
the
process
pointing
out
why
yours
is
good
and
you
know
how
that
fits
into
thing.
L
E
It
looks
me
over
a
quick
point.
I
would
like
to
come
back
to
the
to
the
point
of
cost-benefit
analysis.
I
think
it
would
be
really
really
useful
if
an
operator
of
being
a
recursive
DNS
has
a
couple
of
PhD
students,
maybe
something
like
that
and
that's
actually
a
cost
emulation,
yeah
and
a
benefit
simulation.
E
So
if
you
find
out
that
a
proposal,
one
of
those
proposals
like
saves
us
0.02
percent
of
the
DNS
queries,
it's
obviously
not
a
big
benefit,
but
I
think
we
need
to
understand,
together
with
the
use
cases
that
we
hopefully
gonna,
see
on
the
mailing
list.
How
much
of
whatever
traffic
bandwidth
round-trip
times
does
each
of
those
proposals
actually
save
in
practice
on
the
network,
because
it's
DNS,
oh.
AE
AE
AE
The
micro,
oh
there
we
go
so
this
draft
is
about
describing
what
are
the
necessary
mechanisms.
A
DNS
SEC
validator
should
have
so
that
DNS
tech
validators
can
be
performed
appropriately.
So
what
we're
talking
about
is
provisioning
mechanisms,
monitoring
mechanisms
and
management
mechanisms,
but
the
idea
is
that
DNS
SEC
validators
could
really
enable
DNS
SEC
after
all
so
well.
The
draft
is
in
the
version
six
now
it
has
been
progressing
through
two
different
versions
and
where
we
think
the
draft
is
in
pretty
good
shape.
AE
AE
AE
AE
So
the
question
we
have
is
probably,
among
others,
but
that's
the
current
questions
we're
facing
is
that
we
have
some
some
status
for
the
key
s.
Key
+
Z
s
key.
However,
this
status
does
not
provide
any
well
does
not
are
not
clearly
stating
whether
the
KSK
and
although
the
SK
can
be
trusted
and
used
for
the
validations.
So
what
we
would
like
to
know
if
there
is
a
consensus
on
what
isn't
none
trusted
key
so
from
the
status
as
well
as
from.
Let's
say,
the
time
status
has
been
changed
or
this
kind
of
things.
AE
AE
AE
R
Not
for
long
I
think
in
general,
this
is
good
work
and
I
really
liked
it
up
to
think
requirement.
Eight
and
then
the
KSK
status
case
have
lost
me
because
we
have
in
the
DNS
I
mean
the
notion
of
the
TTL
and
how
we
put
stuff
in
cache.
Now
that's
kind
of
set
in
stone.
Why
should
a
validator
be
different?
There.
AE
N
Generate
Scotland's
I
can't
disagree
with
what
ralph
said
there
I
think
some
diverse
market
is
a
bad
idea
and
the
idea
of
revoking
data.
That's
in
the
cash
because
I
Keys
going
bad
all
of
a
sudden
doesn't
seem
quite
right
to
me
and
I
think
it's
could
be
an
interesting
vector
all
sorts
of
denial
of
service,
its
accident
compromises
on
resolving
service,
so
I'm
not
convinced.
This
is
necessarily
a
good
idea.
N
M
Joe,
a
please
I
agree
with
Jim
I
think
the
word
suddenly
shouldn't
feature
here,
because
I
think
the
stuff.
The
timing
should
be
controlled
by
the
people
who
published
the
data
in
the
DNS
and
not
by
people.
Ideally
who
have
to
make
guesses
about
the
intentions
of
the
people
published
it
so
I
think
it's
a
bad
idea,
I
think
are
baying.
Ttl
makes
more
sense.
I
had
one
other
comment,
which
is
not
one
of
your
questions,
which
is.
M
You
also
include
a
section
as
a
number
of
sections
that
relate
to
bootstrapping
and
retrieving
trust
anchors,
and
you
used
the
unbound
anchor
approach
as
an
example
that
was
written
in
response
to
it
now
long
expired
document
that
specifically
addressed
validator
bootstrap,
but
I
would
still
really
like
the
working
group
to
pick
up
and
I
think
that
is
especially
given
our
current
experience.
I
think
that
would
be
a
great
thing
to
pick
back
up
and
actually
publish
in
its
own
right
separately.
I.
M
AE
AE
M
My
other
point
there
is
that
we
may
see
the
mechanisms
for
by
which
we
recommend
a
validator
picks
up
a
trust.
I
could
change
over
time,
because
we
may
learn
things
about
from
k-rod
KSK
rolls
it
would
be
ashamed
to
have
to
rev
an
entire
document
like
this,
just
because
that
particular
mechanism
has
changed
so
I'm.
Just
really
just
reaffirming
my
opinion
that
everybody
already
knows
that
the
other
document
is
good.
Q
Eric
Australian,
so
I
want
to
agree
with
Jim
and
Joe
on
the
first
point,
I
think,
but
sort
of
just
to
sort
of
clarify
my
perspective.
I,
don't
think
the
TTL
is
necessarily
part
of
the
validating
process,
so
I
mean
like
the
caching
aspect
of
it.
You
might
just
say
that's
a
separate
issue
because
I
think
it
kinda
is
so
I
agree
with
them.
I
think
trying
to
put
that
into
the
validation
discussions,
making
more
complicated
than
it
needs
to.
Caching
is
separate
and
there's
a
whole
bunch
of
thinking
around
that.
Q
So
I
would
separate
that
out
and
the
only
thing
I'd
say
is
I
think
it's
worth
spending
some
time.
I
haven't
read
the
draft,
so
if
this
is
in
there
I
apologize
for
being
redundant,
but
what
to
do
with
revoked
keys
after
keys
been
revoked,
that's
kind
of
like
a
permanent
statement,
but
if
it
gets
flushed
out
of
cache
or
forgotten
and
the
revoked
key
can
be
reused
again.
That
could
potentially
be
a
problem.
Q
AF
Russ
Mundy
I
won't
speak
to
your
first
question
Daniel,
but
the
second
one
I
think
that
if
there
is
a
sudden
relocation,
then
everything
associated
with
that
key
in
the
cache
should
be
flush,
because
if
it's
in
there
is
either
negative
or
positive
validation,
the
validation,
if
the
key
is
in
fact
revoked
should
be
terminated.
The
other
question
that
I
have,
though
I,
am
having
a
hard
time,
envisioning
the
sudden
relocation
or
on
trust
the
condition.
I,
don't
know
that
there's
been
a
accurate
or
a
valid
scenario
written
up
for
that
is.
AF
AE
AF
J
You
oh
well
third
occur
is
I.
Speaking
is
with
my
hat
of
not
writing.
You
know
resolver
code,
because
I
don't
but
I
can't
imagine
any
cash
author
wanting
to
keep
a
chain
of
keys
and
then
have
to
go
search
through
it.
So
to
me
you
know:
that's
like
a
non-implementation,
starter,
that's
that's
a
huge
memory
and
footprint
and
everything.
So
then
the
question
becomes
alright.
Assuming
that
that's
not
valid
to
do
what
are
our
choices
and
I
think
people
have
already
outlined.
J
The
two
choices
is
one:
you
don't
care
and
you
keep
you
know
the
TTL
and
and
related
data
in
the
cache
or
two.
You
could
just
wipe
the
whole
cache
right,
but
then
you
end
up
with
a
different
attack
where
you
know,
if
I
could
get
you
to
come
to
some
little
zone
and
I
keep
revoking
the
key,
then
you're
gonna
always
be
wiping
your
cache
in
the
cache.
That
comes
you
know.
J
So
the
reality
is
data
producers
today
already
have
the
mechanisms
for
deciding
how
long
information
that
is
put
in
a
cache,
because
it
has
been
proven
valid,
can
stay
there
and
their
TTL
fields
and
signature,
expiration
fields
and
and
I'm
a
security
geek
right
I'd
want
to
be
able
to
go
back
and
revoke
everything,
but
I
don't
see
a
viable
mechanism
for
doing
that
easily.
So
I
think
that
the
TTL
and
the
sig
expiration
fields
are
the
only
thing
you
have
to
go
on
and
I.
J
AG
Whistles
from
Verisign
I
see
the
document
uses
zsk
and
KSK
KSK
quite
a
bit
and
I
would
just
encourage
you
to
be
very
careful
with
that
and
make
sure
that
all
this
works
with.
You
know,
folks
that
choose
to
use
just
one
key
for
signing
their
zones.
Maybe
talk
about
SCP
bit
rather
than
k,
sk
n
z,
sk
cuz.
These
are
really
just
hints
and
for
our
convenience
right,
I.
N
B
Alright,
so
we've
discussed
this
now
in
a
couple
of
meetings
and
what
what
Tim
and
I
are
sitting
here
trying
to
figure
out
is:
do
we
think
it's
ready
to
consider
adoption
or
do
we
think
it
needs
more
work
before
we're
ready
to
consider
adopting
it?
So
can
I
hear
a
hum
people
who
think
this
document
is
interesting,
useful
ready
for
adoption.
Please
hum
now.
B
B
AH
B
B
AI
AI
The
reason
for
that
and
again
I'm
sure
you're
aware,
is
that
the
signal
that
came
back
from
the
early
adoption
of
the
mechanism
in
RFC
81452
jested
that
the
take-up
of
the
new
key,
the
new
KSK,
was
not
universal
and
that
the
pool
of
resolvers
that
was
signalling
that
they
had
not
let
akin
up
this
new
key
was
significant
enough
for
the
ICANN
folk
to
feel
it
was
time
to
pause
and
reflect,
which
is
fair
enough.
It
was
a
good
call,
but
there's
a
lot
of
trouble
with
interpreting
that
signal.
AI
It's
a
signal
that
moves
inward
with
the
query.
It
doesn't
go
backwards
to
the
query,
er
and
so
the
aggregate
signal,
the
composite
of
all
of
these
signals,
is
actually
only
visible
to
the
route
service,
dns
forwarders
and
local
caching
suppress
the
query
moving
inward.
So
at
some
point
you
get
a
real
issue
that
the
signal
you've
got
is
not
easy
to
do.
Attribution.
AI
The
real
question
that
they're
wanting
to
ask
is
not
answered
by
this.
In
any
case,
how
many
users
might
be
affected
and
go
dark
when
the
key
roles
is
not
the
same
as
looking
at
supposed
resolvers,
because
you
can't
tell
attribution-
and
you
don't
even
know
if
the
user
has
alternate
resolvers-
that
they
could
have
used
if
the
one
that
they
were.
You
know
using
this
point,
went
dark
because
etc,
resolved
dot.
Kampf
normally
has
a
few
things
in
it.
AI
And
you
know
I
worry
that
the
answer
is
no
there's
always
so
much
ambiguity
when
you're
trying
to
ask
a
question
about
users
when
the
mechanism
of
answering
it
is
resolved
eccentric,
so
maybe
there's
a
different
way
of
doing
it.
And
maybe,
if
you're
asking
a
question
about
users,
we
should
look
at
users
and
look
at
it
from
a
user
centric
viewpoint.
So
the
question
is:
can
you
can
you
devise
a
query
that
could
reveal
the
state
of
those
trusted
keys
in
not
just
a
resolver
but
the
resolver
system
that
the
user
actually
uses?
AI
AI
What
if
we
proposed
a
mechanism
that
altered
the
DNS,
SEC
validation
outcome
based
on
the
presence
of
a
label
in
the
query
name
and
the
proposal
is
relatively
simple:
it's
a
proposal
to
add
a
resolver
mechanism
that,
if
a
query
contains
a
generic
label
of
the
form
underscore
is
ta
and
an
encoded
key
tag.
Then
a
validating
resolver
will
report,
validation,
failure,
our
code
or
whatever.
AI
If
the
key
is
not
in
the
trusted
key
store,
simple,
as
that,
and
because
of
the
way
the
logic
works,
there's
a
negative
as
well,
which
is
a
negative
question,
underscore
not
ta
a
key
tag
and
that
will
report
validation
failure
if
the
key
is
in
the
trusted
key
store.
Why
do
you
do
that?
Because
you
actually
need
to
give
a
relatively
complete
table
of
analysis?
AI
Now,
if
you
actually
phrase
three
queries
using
the
positive
label,
the
negative
label
and
a
generically
badly
signed
domain
name,
just
any
old
name
that
doesn't
validate
the
table
at
the
base
of
that
page,
will
actually
tell
you
which
kind
of
resolve
you're
looking
at.
If
it
was
a
single
resolver.
Okay,
you
can
sort
that
out.
AI
AI
The
query
doesn't
identify
the
user,
nor
does
the
answer
it
doesn't
really
reveal
which
resolves
are
being
used,
doesn't
mean
it's
not
meant
to
it.
Never
changes
in
secure
to
secure
or
authenticated
it
only
downgrades.
It
never
upgrades,
because
it's
just
a
label,
not
a
golden
name.
Anyone
can
set
it
up.
Anyone
it's
not
exclusive
to
you
me
or
anyone
else,
with
access
to
a
particular
label
and
in
fact
the
way
it
works
is
only
the
user
gets
to
see
the
answer.
AI
Okay,
so
that's
what
I'm
proposing
here,
it's
certainly
susceptible
to
mass
measuring
techniques
and
the
technique
that
we
use
to
measure
DNS,
SEC
validation
and
ap
neck,
which
uses
an
ad
to
perform,
gets
gets
perform.
Dns.
You
can
use
this.
This
process
of
the
process
here
certainly
is
susceptible
to
this
kind
of
measurement.
Users
can
measure
their
own
DNS.
The
same
way
ISPs
can
measure
their
own
resolver
systems
the
same
mechanism.
It's
not
exclusive
for
anyone
to
do
this.
AI
So
in
talking
about
this,
and
talking
to
the
folk
at
I
can't
go
and
what's
going
to
help
you.
It
certainly
seems
that
this
could
be
of
use,
and
it
would
certainly
be
useful
for
DNS
resolver
manufacturers
to
have
this
available
and
to
actually
implement
this
mechanism.
One
conversation
I
had
is,
if
I'm
a
validating
resolver
do
I
have
to
look
for
this
label
on
every
single
response
is
that
a
lot
of
work
could
be
that's
why
we
have
computers,
but
one
of
the
ways
to
alleviate
that
is
to
specify.
AI
AI
B
X
Around
and
all
that
laughs,
we
think
I
think
it's
a
good
jobs.
One
remark
you
well,
it's
you
reserved
a
label
in
every
job,
but
if
people
of,
if
we
can
get
some
consensus
on
the
name
of
the
label,
we
had
already
some
discussions
about
it
in
score,
is
ta
or
not,
etc.
But
if
there's
consensus
on
the
naming,
etc
and
there's
some
convergence
here,
we
will
implement
it
in
advance.
Thanks
the.
AI
Name
was
deliberately
chosen
to
start
with
an
underscore.
So
in
theory
it's
not
a
hostname
which
doesn't
have
underscores
and
it
was
sort
of
the
leading
underscore
was
meant
to
look
like
a
lot
of
the
other
things
that
are
special
used
because
of
leading
underscore
the
is
ta
was
almost
borrowed
from
80
145.
In
some
ways
it
was
meant
to
be
just
a
descriptive
piece
of
text
with
a
key
tag.
Quite
frankly,
if
someone
inadvertently
creates
this
kind
of
label
yeah,
don't
do
that!
That's
a
bad
thing!
If
you
expect
answers
that
work
use
it.
V
So
brave
Alice
I
see
so
Jeff
as
I
understand
it
you're
proposing
to
use
this
in
systems
similar
to
your
current
advertising.
Based
framework
me:
yes,
you
drug
go
nuts.
Whichever
way
you
want
in
those
frameworks,
can
you
actually
tell
the
difference
in,
for
example,
client-side
browser
code
between
a
DNS
lookup
failure
and
a
failure
to
reach
retrieve
what
if
a
resource
is
pointed
to
at
the
a
record
that
that
results?
V
V
AI
D
AJ
Z
AI
AI
AI
AI
If
you
know
that
key
and
it's
not
in
your
trusted
key
store,
if
you
know
that
key
change
good
to
bad.
So
if
I,
if
I
ask
for
sta
nonsense,
didn't
each
address
or
cell
fail,
it'll
send
back
whatever
it
was
going
to
send
back
from
DNS
SEC
validation.
It's
never
going
to
change
good
to
know
so
bad
good.
So
if
it
validated
otherwise,
it
will
say
that's
ok.
This
sounds
like
a
beer
in
a
napkin
right.
AI
AI
B
T
O
B
AK
D
AK
Problem
is
the
source
of
the
problem.
It
was
in
specifications
themselves,
so
we
we
form
a
group
at
the
last
IDF
to
see
what
to
do
on.
We
decided
to
manage
on
update
the
TC
I've
see
on
each
moksha,
I've
see
which
are
certain
concern,
and
so,
to
mention
of
that
said,
not
to
rewrite
who
TC
do
a
new
patrol
car,
etc.
Even
each
each
time
you
read
that
you
see
you
find
things
which
should
be
done.
AK
AK
AK
AK
A
Show
of
hands
who
has
read
this
okay,
so
we
need
some
more
people
to
read
it.
Yeah
I
speaking
as
this
chair
I
do
believe.
It's
probably
a
working
group
item,
because
this
does
actually
address
an
interesting
flaw
in
the
t-statistic
thing
so,
but
the
group
may
have
their
opinions
about
them
that
oh,
but
we
definitely
need
more
people
to
read
it
and
we
get
feedback.
Y
Y
As
long
as
we
don't
modify
the
protocol,
I
think
that
we
should
address
these
deficiencies
from
2845
and
this
draft
not
just
have
that
text
copied
over
the
bottom
without
fixing
these
issues
now,
I
did
send
comments
about
this
to
the
mailing
list
and
we
should
not
just
say
that
this
28
for,
if
has
already
been
shipped
at
17
years
old.
So
we
cannot
do
anything
about
the
text
we
should
address.
We
should
clarify
the
text
and
basically
remove
the
efficiencies
from
the
text.
I.
Y
Y
A
Think
yeah
I
think
hopefully
some
more
review
and
this
week
we
can
give
you
some
feedback
as
well,
because
but
I
do
I
I
guess
this
is
just
my
opinion
and
the
working
group
can
you
know,
and
my
co-chair
can
beat
me
on
it,
but
once
we
crack
that
document
open,
we
we
probably
should
sort
of
address.
Any
sort
of
you
know
questionable
language
or
sort
of
things
that
need
to
be
more
clarified.
Most.
Y
A
A
D
AK
T
T
Originally
is
calling
it
RFC
1918
for
names,
but
that's
kind
of
a
bad
name,
I,
think
it's
more
a
condom
for
the
namespace,
so
users
wanna
pony.
Basically
they
want
some
sort
of
name
for
internal
or
disconnected
namespaces.
You
know
they
keep
doing
stuff
like
this.
We
see
a
bunch
of
people
using
these
sorts
of
names.
T
Localhost
is
in
you
an
interesting
one.
Local
domain
has
actually
suddenly
shown
up
and
I
was
looking
to
see
why-
or
at
least
it's
increased
in
prevalence
turns
out.
If
you
install
Ubuntu
and
it's
not
connected
to
anything,
it
decides
to
name
itself
local
host,
not
local
domain,
and
this
is
a
fairly
new
sort
of
thing.
You
know
it's
becoming
much
more
prevalent,
so
people
want
to
use
this.
T
You
know
we
keep
telling
them.
No
users
want
a
pony,
but
you
know
we
say
this
causes
issues
you
squat
on
random
names,
there's
some
additional
root:
lookups
potentiate
leaks,
some
of
your
internal
namespace
but
I.
Think
sort
of
the
pollution
is
the
annoying
one.
Eventually
they'll
cause
collisions,
but
you
know
users
still
wanna
pony
we
say
no,
you
can't
have
a
pony.
T
Actually
what
we
say
is
slightly
more
subtle.
What
we
say
is
you
should
go
off
and
register
a
name.
You
should
go
from
really
example.com
and
then
put
your
random
stuff
under
that
you
should
be.
You
know,
foo.example.com.
We
are
the
adults
in
the
room.
We
know
that.
That's
that
this
is
what
you
should
do.
It's
the
right
thing
to
do
seriously.
You
should
go.
Do
this
and
that's
true.
That
is
the
right
thing
to
do.
Of
course
we
also
preach
abstinence.
You
know
we
tell
teens.
T
This
is
risky,
behavior
don't
go
off
and
do
it.
These
seem
to
be
about
equally
useful
right.
We
can't
stop
users
from
doing
this.
We
can't
stop
teens
from
having
sex.
We
should
probably
just
acknowledge
the
fact
that
we
can't
stop
this
and
try
and
deal
with
it
in
a
way.
That's
not
going
to
hurt
so
potentially
a
way.
That's
not
going
to
hurt.
T
Is
we
take
a
name
and
we
set
it
aside,
and
we
say
this
is
where
you
can
do
stupid
crazy
stuff
I've
been
using
that
internal,
because
it
looks
like
it's
already
been
squatted
on
it
kind
of
describes
things,
and
it's
purely
for
non-technical
reasons
that
it's
a
Tod
that
internal
DARPA
would
obviously
work
and
would
be
you
know
within
our
bailiwick.
However,
users
aren't
gonna.
Do
you
know
my
intranet
internal
DARPA
instead
they'll
just
squad
on
a
name,
so
you
know
that's
why
potentially
a
TLD.
Obviously
we
can't
force
people
to
use
this
either.
T
We
can't
tell
them,
you
know,
go
use
something
that
you
registered.
We
can't
force
them
to
use
this,
but
at
least
some
said
of
them,
we'll
a
number
of
people
who
don't
really
participate
in
the
IETF
eff
said.
Yes,
I
really
really
want.
This
I
really
really
wanted
this
for
a
long
time.
If
it
existed,
I
would
use
it.
T
They
might
be
lying,
who
knows,
but
you
know
there,
what
did
I
figure
out
9
times
10
to
the
68
possible
TL
DS
I
think
we
should
just
set
one
aside
squad
on
it
and
say
you
know
we're
not
squad
on
it.
Officially
get
it
and
say
this
is
where
you
can
do
your
crazy
stuff?
Oh
well,
obviously,
just
like
1918.
T
If
two
companies
are
using
that
internal
and
merge
they're
gonna
have
a
sad
time,
I
think
that's
just
something
that
we
know
in
the
document
and
say
this:
is
your
space
go
off
into
whatever
you
will?
If
you're
gonna
merge
these
things,
you're
gonna
have
a
bad
day?
Oh
well,
yes,
this
is
all
kind
of
icky
and
I've
acknowledged
that
multiple
times.
However,
I
think
that
if
we
don't
give
users
this
they're
just
going
to
continue
to
squat
on
stuff.
So
you
know,
let's
just
give
them
their
pony
that
way.
T
AF
N
N
I
think
that
would
clear
all
sorts
of
problems
among
go
back
and
revisit
over
hassles,
but
we've
just
essentially
closed
off
with
dotnet
I
think
the
problem
we're
going
to
get
there
is
pure
primarily
what
issues
around
I
can
policy
about
applying
for
a
Tod
in
getting
an
insecure
delegation.
I
do
think,
there's
a
mechanism
for
that
in
place
that
I
can
already
and
I
think
you've
been
a
wonderful
hot
if
you're
doing
that
particular
path.
N
T
So
yeah
I
mean
the
reason
that
with
Alysha
T's
had
and
we
needed
e
in
a
sec
and
secure
delegation
was
cause
otherwise
DNS
SEC
breaks
and
you
know
we
could
always
do
the
we
will
put
it
under
normal
reserve
list.
We
could
ask
for
a
delegation
in
parallel.
If
it
happens,
yeah,
if
it
doesn't
matter,
don't
really
care,
but
there's
a
I
can't
person
well.
AL
I
learned
I'm,
not
speaking
on
behalf
of
I,
can
and
I'm
not
going
to
make
a
comment
about.
Should
it
be
a
TLD
or
not?
That's
not
why
I
came
to
the
microphone
for
you're
talking
about
mergers.
Yeah
I
just
wanted
to
point
out
that
that's
not
the
only
problem.
The
problem
is
when
you
make
referrals
and
you
pass
referrals
to
other
parties
in
your
application
and
then,
if
you
make
a
referral
with
my
machine
name,
dot
internal
to
somebody
that
is
not
in
the
same
internal
network.
AL
T
M
How
Aaron
its
Joey
Emily
here
so
on
the
delegation,
question
I
sense,
a
melt
or
last
about
this,
so
I
need
to
repeat
that
I!
Don't
think
there
needs
to
be
a
D
name
or
a
delegation
for
this
I.
Don't
think,
there's
any
actual
technical
policy
issues
here
for
the
IETF
I,
don't
think,
there's
any
implementation
issues
that
the
IETF
needs
to
ask
that
Ayane
or
anybody
else
to
do
I,
don't
think
there's
any
work
here
for
the
IETF
and
I
think
we
actively
don't
want
work
anywhere
close
to
this.
M
H
My
name
is
Andrew
Sullivan,
I,
completely
agree
with
Joe
and,
moreover,
on
the
previous
slide,
I
think
you
say
that
there's
no
process
for
this
and
it
requires
creating
one,
but
it
doesn't
require
creating
one
here.
It
requires
creating
one
in
another
place
that
is,
you've
got
to
go,
create
that
and
I
can
and
so
for
the
same
reason
that
you
have
to
go
and
create
that
and
I
can
you
have
to
create
a
new
rule
for
delegating
something
that
would
not
be
an
operational
TLD
not
allowed
to
delegate
things
under
official
things,
etc,
etc.
AM
O
David
Conrad
I
can,
but
not
speaking
on
behalf
of
I,
can
even
if
I
knew
what
I
was
gonna,
be
saying,
I'm
a
little
confused
as
to
why
there's
a
feeling
that
this
should
be
thrown
over
to
I
can
since
I
account
deals
with
the
enough
stuff
and
I
would
have
thought
that
this
would
be
a
nominee
for
the
specialist
names
are
se.
So
me
too,
I
just
really
confused.
I
Bernie
volts
I
just
want
to
suggest
one
other
thing.
If
you
do
proceed
with
this,
as
you
might
suggest
that
somebody,
you
know,
senator
just
using
host
name,
dot,
internal
use,
host,
name
dot,
you
know
your
company's
domain,
name,
dot,
internal
or
something,
because
that
then
would
solve
at
least
some
of
the
issues
with
two
companies
merging
or
you
going
into
coffee
shop
right.
It
would
reduce
the
chance
of
collisions.
H
This
is
interesting
again
just
to
respond
to
what
David
asked.
This
is
not
a
special
use.
Domain
name,
there's
nothing
special
about
it.
This
is
a
name
in
the
DNS,
it's
just
a
name
in
the
DNS.
That
happens
to
be
a
split
horizon.
If
we
think
that
split
horizon
is
a
good
idea,
and
this
working
group
wants
to
embrace
new
ways
to
make
split
horizons
work
even
worse
than
they
already
do,
then
that's
fine,
but
but
the
name
in
question
is
none
of
our
business
because
it's
just
a
standard
delegation.
H
T
A
AN
No,
no,
you
go
yep
Edna
jr.,
so
in
terms
of
I
can
hearing
so
much
about
I
can
I
think
this
work
should
be,
and
I
can
and
actually
I
can
board
just
commissioned
in
the
in
the
meeting
in
Abu
Dhabi
just
commissioned
and
they
a
full-scale
study
on
names
collision
through
the
S
AK.
These
security
instability,
Advisory
Committee,
so
I
encourage
you
to
go
there
and
and
I
think
that
process
is
supposed
to
be
open.
AO
Stuart
Cheshire
from
Apple
I
have
a
quick
comment,
not
so
much
directed
at
you
warned,
but
towards
several
of
the
comments
that
were
made
in
your
presentation.
You,
you
made
this
joking
reference.
I
want
a
pony
repeatedly
and-
and
you
pointed
out
that
end
users
and
organizations
are
doing
this
already,
and
we
sit
here
at
the
ATF
bearing
a
heads
in
the
sand.
Pretending
it's
not
happening
and
pretending
we
can
stop
them.
I
can
only
assure
ports,
show
widespread
use
of
dot
home
and
dot.
Arpa.
AO
We've
already
had
this
little
dance
at
the
ITF,
where
we
pretend
dot
home
doesn't
exist
and
we
call
it
home
got
Harper.
Instead,
it's
not
too
whether
anybody
outside
the
ITF
will
care
about
that.
They'll,
probably
carry
on
using
dot
home.
So
people
talk
about
problems
with
referrals
and
mergers.
One
use
case
I
view
for
this
is
bootstrapping.
You.
D
AO
A
new
piece
of
hardware
out
of
the
box-
and
this
is
the
default
configuration
if
you
have
a
domain
name
for
your
company
that
is
registered
and
paid
for
every
year.
You
don't
need
to
use
my
company
name
com,
DARPA
at
dot
internal,
as
somebody
else
suggested,
because
you
already
have
a
global,
unique,
fully
qualified
domain
name
that
you
can
use
for
all
your
names.
AO
This
is
for
the
product
you
buy
on
the
Shelf
in
Best
Buy,
and
it
doesn't
know
what
your
domain
name
is,
and
maybe
the
first
thing
you
do
is
configure
it,
but
to
configure
it,
you
have
to
talk
to
it
and
talk
to
it
has
to
get
on
the
network.
So
there's
this
bootstrap
process,
so
I
think
there
are
use
cases
like
that.
O
That's
what
a
wonderful
use
case
makes
perfect
sense.
I
guess
what
I'm
still
struggling
a
bit
with
is
how
you
know
it's
something
like
that
internal
would
be
different
than
dot
local
or
anything
else.
That's
been
put
into
the
the
specialties
names
registry.
You
know
there
is
an
effort
underway.
That's
as
Edmund
mentioned
looking
at
name
collisions,
but
that
seems
to
be
somewhat
orthogonal
to
this.
So
you
know
I,
don't
I,
don't
actually
think
it
matters
so
much
where
the
work
is
done.
O
You
know
if
it's
done
at
I
cam,
that
sort
of
suggests
it's
only
sort
of
DNS
related
and
it'll
take
a
lot
longer
than
probably
people
would
like.
If
it's
you
know,
thrown
into
the
special
use
names
registry
with
you
know,
an
RFC
that
says
this
is,
for
you
know
the
kind
of
Z's
case
that
that
Stuart
was
describing.
You
know,
I
think
it
would
be
done
and
we
wouldn't
have
well.
We
would
have
these
conversations
again,
but
you
know
what
at
least
we
could
point
them
at
an
RFC.
So.
AP
A
Thanks,
so
thank
you
that
that's
yeah,
that
seems
to
be
the
end
of
the
most
of
scheduled
portion.
I,
wanted
to
just
run
down
a
couple
of
things
cuz.
We
do
actually
have
some
spare
time
for
ones
on
the
highlights
on
the
terminology.
Biz
document
shoot
for
1:15
on
a
working
group
last
call
and
have
some
folks
start
reviewing
some
of
the
concepts
I've
seen
some
good
starting
to
see.
Discussions
with
Natalie,
listen
I
like
that.
A
So
that's
good
on
the
50:11
Wes
has
a
new
version
coming
out,
or
he
has
one,
and
once
we
see
that
and
if
Mike
and
Ed
or
mollified
you
know,
we'll
probably
kick
off
with
like
a
working
group.
Last
call
for
one
week
do
a
short
one
just
to
make
sure
we've
covered
all
the
pieces
on
the
xpf
document.
Joe
and
Sarah
need
to
give
give
us
some
review,
and
then
we
can
probably
push
forward
on
some
sort
of
call
for
adoption
and
see
what
people
think
the
additional
answers.
A
If
we
can
get
some
reviews
this
week
and
we
can
see
some
good
reviews
on
the
list
or
if
we
see
why
you
see
the
authors
put
out
a
new
version,
I'd
like
to
do
call
for
adoptions
and
basically
in
the
next
couple
weeks.
So
let's
let's
try
to
see
if
we
can
sort
of
get
some
feedback.
I
think
both
those
are
pretty
relevant,
as,
as
folks
said,
even
the
KSK
sent
no
one.
So,
let's
see
if
we
can
go
with
that.
B
Wes
Hart
occur
had
a
demo
of
a
new
service,
he's
prototyping
for
our
FC
7706,
which
is
local
caching
of
the
root
zone.
For
those
who
believe
the
things
like
the
root
name
servers
and
things
like
that
are
too
political,
and
the
answer
is
to
move
them
out
of
their
current
critical
role.
This
is
the
sort
of
thing
they
should
be
looking
at
Wes.
Please
raise
your
hand
so
that
people
know
to
find
you
and
buy
you
a
beer
and
look
at
the
demo
and.
B
We
had
some
late-breaking
requests
regarding
agendas
which
it
turned
out
and
also
Tariq's
RF.
If
you
would
wait
raise
your
hand,
a
draft
that
didn't
we
didn't
get
to,
but
he's
asking
for
a
review
for
a
new
our
our
type,
the
I
VI
PTR
type,
raise
your
hand
and
take
a
few
minutes
and
review
the
draft
because
he's
looking
for
feedback
on
that
anything
else.
As.
A
A
I
mentioned
that
in
the
chair,
slides
I
and
that's
true-
we
definitely
want
some
folks
to
look
at
that,
because
there
is
a
lot
of
text
change,
I,
don't
think
it's
a
lot
of
technical
change,
but
I
think
there's
enough
text
change
that
folks
need
to
just
make
sure
that
things
aren't
falling.
But,
yes,
we
want
to
kick
off
a
working
group
last
call
in
December
for
that
too.
So
that's.