►
From YouTube: IETF99-DNSOP-20170718-1550
Description
DNSOP meeting session at IETF99
2017/07/18 1550
https://datatracker.ietf.org/meeting/99/proceedings/
B
D
E
E
A
G
H
A
G
G
All
right,
everybody
good
afternoon
for
the
last
session,
welcome
to
Danis
op
I'm
Tim,
that's
Suzanne,
and
it
is
I.
Atf
90
you
just
you
just
don't
realize
it.
So
you
know
who
we
are
Joel's
offered
to
stand
up,
engage
a
prescriber
or
we
force
the
former
18
to
basically
do
our
bidding
so
and
Paul
says
is
going
to
be
minute.
So
I
appreciate
that.
G
So
please
make
your
name
at
the
mic.
So
while
we
probably
know
people
we
may
not
know
everybody
I'm,
always
bad
about
that
I.
Well,
I
didn't
get
the
the
ietf
right.
I
did
update
the
new
well
document.
So
this
is
the
new
text,
so
hopefully
everybody's
taking
a
little
look
at.
It
doesn't
seem
to
be
a
lot
different
than
the
old
text.
G
Yes,
I'm.
Sorry,
sir
we're
gonna
ask
you
the
service
I
I've,
since
we've
got
some
blue
sheets
going
around.
Please
fill
those
in.
So
everybody
knows.
What's
going
on
how
many
people
we
have
here,
how
many
so
we
can
get
a
big
room
like
this,
so
the
agenda
this
time
we
got
a
three-hour
cruise.
The
first
two
hours
is
sort
of
previous
work
that
we've
been
doing.
G
So
but
mostly
it's
updates
on
current
stuff,
going
on
quick
thing
on
document
updates.
Since
the
last
meeting,
it's
I
feel
I
feel
this
is
very
sad.
We've
only
got
one
thing
sort
of
published
and
we've
been
on
a
cadence
of
getting
three
drafts,
published,
I,
know
I
know,
and
this
is
kind
of
my
fault,
I
sort
of
got
busy
with
work
and
I
get
sidetracked
and
stuff.
So,
but
we
got
key
tag
pushed
out.
G
G
It
went
through
a
second
working
group
last
call
and
I.
Basically
had
kraut
Joel,
who
I
go
to
Joey
Lynn,
who
I
saw
at
lunch
that
he
is
responsible
sort
of
fixing
some
of
the
outstanding
items,
so
Oliver
you're
off
the
hook
on
that
so
they're
pretty
minor.
No,
so
that
was
his
free
lunch.
So
Joe
raise
your
hand.
Yep
yep,
we'll
sit
down
later
this
week
and
we'll
get
this
sort
of
hashed
out.
So
we
can
move
this
forward.
Ok,.
G
G
Then,
of
course,
the
RPG
that
wonderful
RPG
document
that
sort
of
caused
a
lot
of
you
know
hullabaloo.
We've
worked
out
all
the
boilerplate
problems
and
suzanne
sent
out
an
email
earlier
today,
basically
sort
of
describing
that
think
of
it
as
replace
RPG
with
client
subnet.
In
your
mind
and
the
work
we
did
with
client
subnet
to
you
know
document.
What
was
there
make
it
informational?
You
know
yeah,
we
can
write
about
the
security
things
and
all
the
things
that
we
think
are
bad,
but
we
don't
actually
change
the
protocol.
G
I
Oh
so
I
know
it's
a
very
new
topic,
but
that's
not
what
I
read
from
Suzanne's
no
two
hours
ago,
what
I
sorry
Paul
Hoffman.
So
what
I
read
from
Suzanne's
note
is
that
the
introduction
that
says
we
are
not
talking
about
whether
this
is
a
good
idea
or
a
bad
idea,
or
whatever
is
more
the
case
that
so
even
once
it
comes
into
working
group,
we
don't
get
through
then
start
talking
about
whether
we
think
it's
a
good
idea
or
not.
I
C
You're
both
right,
because
you
know
not
that
we
want
to
spend
a
lot
of
a
lot
of
time
on
it,
which
is
why
I
said
ok,
but
the
point
there
was
that
we
resolved
the
point
that
was
controversial
by
saying
or
acknowledging.
There's
a
challenge
there.
That's
not
what
the
document
is
about.
The
scope
of
the
document
in
both
cases
was
to
say
we're
describing
the
technology
as
currently
built
and
deployed
not
going
into
the
surrounding
issues.
This
is
informational
for
the
purpose
of
documenting
what
people
are
doing.
Yeah
and.
G
That,
after
that
gets
published,
we're
welcome
to
put
out
a
standards
track
that
you
know
we
go
to
our
hearts
content
on,
basically,
which
was
the
you
know,
so
I
believe
you
know
that's
currently
where,
where
things
are
going
on
that,
ok
and
yes,
it
does
seem,
it
always
does
seem,
we've
sort
of
gone
over
it
a
couple
times
a
few
of
the
things
that
we
have
adopted,
the
outer
leaf
document
David
he's
made
some
updates
to
it.
I
think
we're
getting
close
enough.
If
we
have
a
few
more
reviews
for
a
working
group.
G
Last
call
on
that.
It's
actually,
you
know
sorting
the
shape
up.
We
need
to
get
back
with
John
about
the
TCP
requirements.
I
know
he's
adding
some
feedback
since
Chicago
and
we
want
to
see
what
that's
going
so
the
and
the
wire
format
draft
that's
a
interesting
one,
because
there's
a
lot
of
DNS
over
transport
stuff
going
on
right,
so
we're
actually
sitting
down
with
some
80s
later
in
the
week
to
sort
of
discuss
all
the
you
know
or
as
I
call
them
DNS
/
Hoffman.
You
know
protocol
drafts
that
are
out
there.
G
You
know
no
offense
Paul,
but
just
to
sort
of
figure
out
how
we're
sort
of
you
know
sort
of
you
know.
Where
are
we
juggling
all
that
sort
of
stuff
right,
mostly
because
it's
been
adopted,
and
so,
if
we
don't
do
something
with
it,
because
it
does
seem
to
freak
out
there,
we
have
to
have
a
sort
of
a
good
story
as
to
why
so
and
and
no
response
it
I
think
we
just
you
know:
we've
had
some
editorial
stuff
on
that
I
think
we're
technically
it's
there.
G
It's
just
there's
some
editorial
stuff
I
think
we
need
to
sort
of
pull
together
and
that's
my
bad.
So
one
thing
we're
thinking
about
is
because
things
like
DNS
terminology.
This
is
when
they're
making
changes
and
they
seem
small
but
they're.
Actually
because
it's
becoming
standards
tracked
we're
concerned
that
people
aren't
really
sort
of
maybe
looking
at
all
the
bigger
picture
sort
of
thing,
so
we
are
sort
of
considering
some
smaller
in
terms
just
for
specific
topics
or
graphs.
You
know
something
like
an
hour
in
length.
G
We
bang
on
something
that
people
sort
of
you
know
bent
to
their
heart's
content
and,
and
just
basically
sort
of
you
know,
work
through
some
stuff.
You
know
interested
in
some
feedback
on
that.
If
people
think
that's
crazy
or
not,
we
just
don't
you
know
we
don't
want
really
long
sort
of
out-of-control
ones.
I
think
we
figure.
If
we
can
keep
them.
You
know
sort
to
the
point.
We
can
sort
of
focus
on
specific
things,
maybe
just
sort
of
help
us
move
some
stuff
forward,
though
the
document
list.
G
G
Basically
the
action
item
we
have
is
we
want
to
make
sure
that
Wes
and
Mike
hug
it
out
today
and
we
get
to
the
bottom
of
the
baking
tension
and
then
I
think
we're
ready
to
sort
of
move
forward.
An
update
on
the
a
tame
draft
which
people
seem
very
interested
in
and
some
people
seem
very
sort
of
frightened
about
session
signaling,
which
I
originally
thought
we
were
getting
close
to
working
for
glass
fall,
I
think
as
the
author's
start
to
dig
into
it
more.
G
We
realize
we're
not
there
and
there's
gonna
be
some
style
on
us.
I
actually
haven't
had
a
chain.
I
saw
the
slides
at
the
very
last
minute.
Having
that
transfer.
Look
at
him
so
well,
we'll
give
details
in
that
and
David's
done
a
bunch
of
work
on
the
bulk,
our
draft,
which
really
freaked
a
lot
of
people
out
the
first
time
it
sort
of
was
presented.
G
But
there
is
some
interesting
stuff
in
there,
so
I
think
they've
actually
come
up
with
a
sort
of
a
very
good,
simplified
approach
to
the
problem
that
looks
like
we
feel
is
it
you
know
if
the
group
looks
for
it
probably
ready
for
adoption,
and
then
we
may
touch
on
some
sort
of
the
new
work
with
their
business
two
sides
of
a
multi-sided
coin
as
I
call
it
the
server
stale
draft.
You
know
this
is
about
you
know,
do
you
fetch
things
quickly
or
do
you
basically
serve
stuff
out
of
cash?
It's
the
whole.
G
G
We
just
want
to
see
you
know
which
way
it
kind
of
goes
this
way
or
that
way
sort
of
thing.
So
that's
really
you
know
what
we've
done
on
the
agenda
for
this
week,
mostly
today.
So
you
know
so
so
yeah.
So
that
should
keep
us
busy
for
PR
reasons
like
I
said:
Thursday
we'll
do
a
lot
of
a
lot
of
the
new
stuff.
So
you
know,
if
you're
looking
for
sort
of
the
crazy
ideas
that
I
always
and
welcome
to
sort
of,
what's
listened
to
so
and
they're,
not
even
that
crazy.
G
J
I'd
like
to
'participate
one
of
them,
I
have
some
material
I've
contributed
to,
but
I
also
have
the
UTA
session,
where
I'm
deeply
involved
in
the
STS.
You
know,
email
security
thing
I'm
wondering
whether
it's
possible
to
shift
the
algo
negotiation
if
the
author's
are
present
and
ready
to
the
last
thing
today.
Maybe
if
that's
a
possibility,
I
hope.
G
Good
to
know
that
so-
and
there
was
one
other
topic-
I
think
you
all
probably
saw
it-
there
was
a
advisory
about.
It
was
on
behind
dry
soils
were
about
I'm,
the
teasing
on
durability,
and
so
that
had
come
up,
and
there
was
a
discussion
a
meeting
this
week
with
a
lot
of
event
with
all
the
vendors.
So
all
the
major
players
there,
for
instance,
is
put
together.
One
slide
I
was
going
to
bring
that
up
and
we
can
talk
about
that.
G
C
G
Yeah
your
spy
Creek,
but
this
is
just
the
teasing
Oh
yep.
A
G
M
As
you
know,
both
Moss
and
bind
issued
patches
to
address
a
teasing
vulnerability
recently
when
we
got
together,
we
found
that
the
vulnerability
had
the
same
underlying
calls
in
in
both
products
and
we
Furr,
so
the
dns
vendors
got
together
on
Sunday.
We
found
that
a
correction
is
needed
to
RSC
two
eight
four,
five
versed
in
the
slide.
M
There
is
a
the
there's,
a
section
in
285
that
defines
the
orders
that
certain
checks
should
be
done
to
get
over
this
problem.
We
had
to
change
the
order,
so
we
fill
the
correction
isn't
needed,
but
in
addition
it
became
it
became
clear
that
284
5
doesn't
cover
all
the
cases
that
some
clarifications
are
needed
and
we're
concerned
that
if,
if
two
experienced
vendors
make
the
same
mistake,
then
new
players
may
well
make
that
mistake
as
well.
B
I
I,
don't
interoperate
on
that.
So
on
the
terminology
document
as
you've
seen,
there's
been
some
traffic
on
the
list.
I
What
it
seems
to
be
since
the
last
meeting
is
we
have
occasional
bursts
of
here
are
20
Corrections
or
thoughts
and
such
like
that
and
then
silence
for
a
month
and
such
like
that
I,
don't
know
if
that
means
we're
getting
done
or
if
it
means
that
without
authors
pushing
that
it's
not
interesting
enough
and
so
I'm
gonna
defer
to
the
chairs
on
figuring
out
when
we're
done,
we
still
have
we
have
by
the
way
for
those
of
you
who
want
to
know
what
happens
we
done.
I
We
are
keeping
in
the
issues
list
on
github,
and
so
even
if
you
bring
up
an
issue
on
the
mailing
list,
I
will
move
that
over
to
the
to
the
github
issues
list.
If
you
have
a
github
account,
it's
better.
If
you
do
that,
so
that
the
issue
doesn't
look
like
it
came
from
me,
but
we-
and
so
we
have
a
couple
of
open
issues
left
on
that.
But
we
have
one
big
open
issue
and
that
is
waiting
on
me
and
sort
of
like
the
standard.
You
know.
I
Dollar
sign
excuse
my
day
job,
but
one
thing
that
we
promise
to
do
when
we
started
the
best
document
is
to
actually
go
through
the
mailing
list
from
original
77,
19
and
fine.
You
know
in
during
that
time
we
said:
oh
we'll
do
that
in
the
best
document
and
there's
a
bunch
of
things
that
we
punch
it
and
have
forgotten
about
and
yeah
it.
N
G
I
Not
going
to
go
through
the
mailing
list,
and
so
that
will
probably
take
me
another
month
or
so
to
start
this,
but
the
result
of
that
will
be
some
open
issues
that
will
be
long
and
hard.
One
of
them
is
like.
Do
we
talk
about
resolution
versus
resolvers
and
do
we
fix
some
of
the
terminology
in
in
77
19?
We
picked
some
terminology
because
it
had
been
written
up
in
earlier
RFC's,
and
so
we
would
take
the
noun
instead
of
the
verb
and
things
like
that.
I
So
that
will
open
up
a
bunch
of
issues
and
I
hope
that
this
group
doesn't
think.
Oh,
that's
not
important,
because
it
was
important
enough,
the
last
time
where
it
looked
like
we
were
going
to
thrash
and
we
punch
it.
Instead,
it's
probably
still
just
as
important
as
as
two
years
later.
So
that
might
happen
over
the
next
couple
months
and
yeah
hi
George
from
my
clinic.
M
M
I
And
roll
abyss
space
because
it's
never
going
to
finish
right
so
I'm,
not
in
favor
of
keeping
it
open
as
a
draft,
then
the
reason
is
this:
we've
been
getting
a
surprising
number
of
documents
that
have
nothing
to
do
with
this
group,
referring
to
RFC
77
19.
So
so
the
number
of
surprising
references
outside
has
made
me
realize
people
really
want
an
RFC,
so
we
should
get
another
one
done,
even
if
we
have
to
do
a
third
one
but
yeah
and
by
the
way
on
the
on
the
encyclopedia
thing.
I
Encyclopedias
from
1900
to
about
1915
are
absolutely
great.
If
you
get
a
chance
to
go
through
them.
Look
at
articles
on
things
you
think
you
know
about
what
they
thought
chemistry
did
was
just
like
really
really
fun.
So
you
know
go
for
that
and
who
knows?
Maybe
77
19
people
in
50
years,
we'll
look
back
and
go.
That's
not
the
way
the
DNS
worked,
but
so
I
do
hope
that
people
are
still
interested
enough
as
we
bring
up
issues,
especially
the
ones
that
we
punted
on
again.
C
I
think
that's,
it
might
be
that
it's
been
a
little
bit
difficult
to
get
sustained
reviewer
attention,
because
this
is
a
long
and
complex
document.
It's
a
little
bit
intimidating
people
should
go
ahead.
I
guess
you
know
not
to
speak
for
the
authors,
but
it
does
seem
that
it
would
also
it
would
be
valuable,
even
if
someone
doesn't
feel
able
to
take
on
the
entire
document
to
have
reviews
of
particular.
G
I
Sort
of
the
other
dollar
sign
argument
that
people
often
give
is.
Oh,
if
you
had
a
PhD
student,
you
know
have
them
do
this
research.
If
anyone
here
has
PhD
students
who
are
doing
anything
on
the
DNS,
especially
if
they're
one
step
away
and
they're
supposed
to
really
understand
the
DNS,
even
though
they're
not
working
on
it
by
all
means
have
that
person
do
a
thorough
review
of
this
and
open
issues.
Those
are
great
people
for
discovering
what
we
all
thought
was
obvious
is
not
okay
and
by
the
way,
I
liked.
A
M
The
way,
basically,
the
way
it
works
is
we
combine
query
and
responses
to
into
query
response
pairs,
collect
those
into
blocks
of
a
few
thousand
at
a
time
and
then
abstract
the
common
data
from
those
blocks,
and
we
also
have
optional
recording
of
sections
are
ours
and
so
forth,
and
it's
not
the
simplest
file
format
in
the
world,
I'll
liebelei
I'll.
Just
let
that
sphere
itself
on
to
your
eyeballs
and
move
on,
and
now
we
we
presented
this
status
of
draft
zero
one
in
Chicago.
Since
then,
there's
been
a
couple
of
new
things
happening.
M
We
issued
a
draft
zero
two
which
was
just
a
minor
editorial
improvements
and
correcting
an
image,
and
then
in
July
we
issued
the
latest
version
zero:
three,
where
we've
added
an
implementation
status
into
the
draft.
But
the
big
news
is
that
we
now
have
a
open
source
implementation
of
this
available
on
github.
It's
C++
and
you're.
Very
welcome
go
and
have
a
look
at
it.
M
Right
Karen
open
questions
we
have
now
in
Chicago,
we
had
an
open
question
of
what
to
do
about
malformed
packet,
recording,
malformed,
packets
and
I'm
afraid
that
question
is
still
open.
We
haven't
really
thought
too
much
about
it,
and
this
includes
considering
what
exactly
we
mean
by
a
malformed
packet.
It's
the
question
of
packets
that
are
nearly
correct
where,
for
example,
you
can
extract
the
question
from
the
pack
from
the
query,
but
where
there's
something
then
goes
wrong
in
the
rest
of
the
packet.
What
do
we
do
about
handling
those?
M
M
M
However,
we've
also
recently
received
comments
on
0-3,
which
have
raised
some
interesting
questions.
The
first
one
is:
we
have
a
reference
in
the
draft
at
the
moment,
two
extensions
for
implementation,
dependent
fields
in
the
data,
but
have
no
we're
actually
described
exactly
how
those
extensions
are
going
to
work.
So
we
need
to
know
around
something
there,
and
we've
also
had
comments
about
potential
use
in
a
scenario
where
traffic
reconstruction
is
absolutely
not
required.
M
Now,
we've
been
very
much
developing
this
from
the
point
of
point
of
view
of
recording,
pretty
much
everything
and
using
it
to
reconstruct
traffic
so
being
confronted
with
people
saying
yeah
we'd
like
to
use
this,
but
actually
we
don't
really
want
to
bother
about
recording
addresses
and
so-called
subnets
would
be
fine.
We
need
to
think
about
this.
M
Currently
we
have.
Although
we
have
a
lot
of
optional
fields
in
the
in
the
format,
we
have
enough
fields
than
noted
as
compulsory
so
that
we
can
do
very
basic
traffic
reconstruction.
So
we
need
to
think
about
this
and
also
the
question
of
what
should
be
the
minimal
time
stamp
resolution,
because
again
the
people
who
are
interested
in
storage,
but
not
necessarily
reconstruction,
and
have
also
raised
the
possibility
of
well.
We
don't
really
care
about
time
resolution
to
greater
than
a
second.
M
P
M
M
Though,
if
we
loosen
reconstruction
that
raises,
if
we
loosen
reconstruction,
there's
a
question
of,
do
we
put
a
marker
in
the
data
saying:
hey
you
actually
haven't,
got
enough
data
to
reconstruct
and
prevent
it.
Do
we
just
recommend
that
implementers
introduce
dummy
data
of
their
own
when,
if
asked
to
reconstruct
that
reconstruct
including
data
that
isn't
there?
But
tonight
that's
an
open
question.
Q
M
What
I
can
I'd
be
anything
I
can
tell
you
about
the
IPR.
Is
that
we're
proceeding
with
the
draft?
Because
the
working
group
wants
us
to
proceed
with
the
draft?
As
I
mentioned,
we
have
open
sourced
the
software.
Now
that
software
is
it's
an
Mozilla
Public
License,
but
it's
copyright,
I
can
and
I
referral.
I
refer
you
to
the
Honorable
mr.
Mandelson.
M
S
That's
me
here:
one
thing
that
was
mentioned
for
the
problem
of
mandatory
versus
optimal
data
would
be
to
have
two
profiles
of
CDNs
one
where
everything
was
mandatory
on
one
with
a
lot
of
things
were
optional,
it
would
complicate
a
bit
iguana
all
the
semantic
description,
but
it
would
help
with
all
the
public.
It's
not
only
a
dynastic
problem
in
there
are
many
cases
where
you
have
only
a
part
of
the
data
you
still
want
to
stow
it.
So
I
tend
to
think
that
this
idea
of
two
profiles
is
a
white
one.
S
M
My
honestly
I
only
worry
about
profiles
is
whether
two
would
end
up
being
enough.
You
know,
okay,
we
could
draw
a
line
between
reconstruction
and
non
reconstruction,
but
are
there
going
to
be
other
potential
applications
where
a
similar
line
might
exist?
I
I,
don't
know
that's.
Why
I'd
like
a
bit
more
discussion
about
potential
users
first,
if
that
makes
sense,
yeah.
M
S
E
K
Adams
I
can
and
I'm
a
very
heavy
user
of
the
Sydney
Nash
format
and
the
tools
that
soon
as
net
provider
and
I've
got
many
feature,
requests
on
the
tools
and
then
maybe
a
few
things
on
the
the
capture
format
itself
and
with
regards
to
the
tool.
Is
there
a
specific
mailing
list
that
and
I
know?
This
is
not
about
developing
the
standards.
I'm.
Sorry
to
ask
you
this,
but
if
there
is
there
a
mailing
list
that
that
people
can
go
to
and
discuss
these
features
etc
like
the
proper
development,
yes,.
M
T
The
comment
that
was
going
to
make
was
simply
a
request
for
if
people
genuinely
are
interested
in
this
dinner
stat
news
case,
could
we
just
have
a
little
bit
of
traffic
on
the
list,
because
there's
been
nothing
there,
everything's
been
off
the
record
so
far.
So
if,
if
we
can
here
on
the
list
specific
requirements
about
the
additional
data
that
people
would
like
to
see
captured,
that
would
really
help
us
in
moving
forward
to
meet
that
use
case.
V
All
right,
I
am
where
Tucker
learns
over
there
ignoring
me,
and
we
can
go
on
ignore
the
outline.
So
just
as
a
quick
reminder
in
5011,
the
math
is
sort
of
complex
about
how
you
generate
a
query
interview
integral
for
good
reasons.
It's
not
that
it's
bad,
it's
just
complex,
so
it
involves
both
a
minimum
and
a
maximum
there's
that
you
take
the
minimum
of
half
the
signature,
validity
and
half
of
the
tto
of
the
old
dns
key
and
15
days.
V
So
in
50:11
security
considerations,
we're
sort
of
changing
sort
of
the
maximum
amount
of
the
minimum
amount
of
time
that
you
must
wait,
while
you're
publishing
a
new
key
before
you
can
start
using
exclusively
it
or
it
and
newer
keys.
And
so
we
called
that
in
an
update
to
the
document.
We
call
that
an
add
wait
time
and
so
the
add
wait
time
is
now.
V
The
difference
is
now
the
add
hold
down
time,
which
was
the
original
30-day
window
that
everybody's
more
familiar
with
in
50:11,
along
with
the
signature
validity
period,
which
is
the
signature
expiration.
The
signature
inception,
plus
the
query
interval
that
we
talked
about
last
time,
plus
the
slop.
So
the
slop
is,
you
know,
typically
what
we
do
in
DNS
here,
which
is
2
times
max
TTL.
V
V
Recently
and
I
I
tried
to
get
a
new
document
out
bytes
they
failed
because
he
gave
so
many
good
suggestions
that
it
took
me
a
while
to
implement
them
I'm
down
to
like
the
last
one
and
then
there's
one
issue
as
well:
they're,
actually,
two
so
first
off
issue
number
one
in
relocation
in
fifty
eleven
in
the
document
that
is
actually
in
the
draft
repository
now
is
wrong.
Thanks
Mike
for
pointing
are
you
here
somewhere,
okay,
good,
because
we're
supposed
to
hug
it
out
later,
apparently
so
pictures
or
it
didn't
happen.
V
You
know
Mike
reminded
me
that
the
hold-down
time
in
fifty
eleven
is
thirty
days,
but
the
removal
downtime
is
just
really
sort
of
a
suggestion
for
how
long
you're
supposed
to
publish
it
and
how
long
the
validator
is
supposed
to
remember
that.
It's
that
there
was
a
removal
so
how
long
it
should
actually
keep
it
around
and
think
about
it
and
yeah
go
ahead.
Mike,
you're,
gonna.
V
N
V
So
the
change
I'm
making
is
what
I
think
you'll
be
happy
with,
so
that,
rather
than
having
one
wait
time,
which
the
last
version
the
document
had
now
there's
two
so
there's
an
add,
wait
time
and
a
remove
wait
time
and
really
the
only
differences
is
for
the
remove
wait
time.
We
knock
out
the
add,
hold
down
time,
which
was
thirty
days
before,
because
because
relocation
does
happen,
the
first
time
you
see
it,
there's
still
a
wait
time
you
still
have
to
you
can
get
replay
attacks
against
you.
V
If
you
don't
wait
the
signature
validity
plus
these
other
chumps,
so
it
becomes
that
that's
issue
number
one
that's
functionally
resolved
unless
Mike,
you
know,
finds
a
problem
with
it
and
I
will
try
and
get
that
out
this
week,
sometime
issue
number
two
is
unresolved,
but
so
here's,
our
here's,
just
a
quick
example
running
through
it.
So
from
the
current
KSK
and
again
the
timing
that
I
can
has
put
forward.
There
is
no
reason
to
panic
for
I
cans.
5011,
you
know
supported
role
of
the
current
KSK,
which
is
like
underway
now.
V
V
So
when
we
plug
in
all
the
math-
and
we
do
all
those
same
min/max
and
all
that
other
kind
of
stuff
we
end
up
with
and
we
keep
boiling
down
the
math
and
doing
all
the
division
we
end
up
with
56
days
that
is
much
shorter
than
they
are
planning
on
waiting
for
that
key
to
be
in
place.
So
none
of
the
security
considerations
we
are
considering
in
this
draft
has
any
concern
over
the
current
key
world
rolling
process
and
Mike
you.
You
were
right.
V
The
math
in
the
appendix
that
was
the
exhibit
that
was
in
the
example
had
62.5
days.
You
were
right.
I
was
wrong,
thank
you
and
for
relocation
we
delete
the
30
days
and
we
leave
it
at
26
days.
So
the
when
the
KSK
is
revoked
sometime
next
year,
it
will
stay
in
the
zone
for
a
think
7b
days,
roughly
so
much
longer
than
26.
V
V
So
an
add,
wait
time
versus
a
wall
clock
time,
and
so
you
know,
should
you
specify
it
as
a
wall
clock
according
to
the
signature
expiration
and
to
me
this
is
a
matter
of
taste,
because
the
reality
is
that
the
math
has
terms
in
it,
some
of
which
are
wall,
clock
terms
and
some
of
which
are
length
terms,
and
so
the
end
result
is,
you
know
either
way
you
end
up
having
to
fuzz
one
set
of
numbers
or
the
other
so,
like
the
add,
hold
down.
Time
is
30
days
from
publication.
V
The
signature
expiration
is
a
wall
clock
time
and
the
equations
could
really
be
structured
as
either
I
found
more
wait
terms
than
I
did
wall
clock
terms,
plus
I.
Don't
want
to
change
the
document,
I'll
be
honest
because
I
prefer
it
the
other
way,
but
because
it's
you
know
like
one
to
one
right
now.
If
anybody
else
has
an
opinion
on
his
site,
especially
now's
the
time
to
stand
up
and
say,
I'd
prefer
a
wall
clock
equation,
let.
V
V
In
this
equation,
one
of
those
signature
validities
is
the
real
signature
of
validity
in
especially
in
the
the
query
integral
one
of
this.
One
of
the
intervals
is
based
on
sig
expiration,
sig
interval
and
it's
fixed
right.
So,
no
matter
when
you
publish
it
the
other
one,
the
first
signature
bility,
the
bigger
one.
This
is
actually
dependent
on
when
you
actually
publish
so
they're,
actually
quite
different
orin
orin
Kumari.
W
Just
a
minor
clarification,
you
said
things
like
that:
we're
adding
and
Ed
wait
time
and
things
like
that
for
people
who
haven't
been
following
along,
they
might
get
the
impression
that
we're
changing
50
11.
This
is
just
clarifications
on
how
to
use
it
or
yes,
just
for
those
who
weren't,
you
know
paying
attention
as
it
went
by
no.
W
V
There
you
can
have
a
query
interval.
That's
faster
than
one
day
so
unknown
may
have
an
upper
interval
of
one
day
sure
said
so.
This
is
entirely
based
on
the
math
and
50:11
alone.
If
implementations
of
course
do
their
own
thing,
they
shouldn't
be
slower
than
the
query
interval
if
they
did
that
they
wouldn't
be
following
50:11,
so
if
they
do
stuff
faster
by
only-
and
so
this
is
worse
this,
so
my
implementation
does
one
day
or
yes,
oh
and.
G
G
V
C
V
So
the
next
slide
is
exactly
that:
I
should
have
an
update
out.
I
was
hoping
by
Monday,
but
I
failed
that
so
it'll
be
out
this
week.
Sometime
I
will
also
release
all
the
comments
in
response
to
Mike's
very
good
set
of
comments
and
in
on
my
opinion
and
I.
Think
in
Warren's
opinion
it's
ready
for
last
call
and
that
towers
in
Chicago.
A
R
R
So
why
we've
all
seen
scenes
own
files
like
this?
You
host
your
website
somewhere.
Ever
you
don't
host
your
DNS,
please
cname!
Your
website
out,
you
cannot
see
in
your
apex,
actually
put
an
IP
in
there
and
the
whole
year
from
how
this
IP
won't
work.
You
know
this
is
not
the
only
reason
to
have
a
name
other
than
the
most
most
obvious
popular
reason.
To
do
this
solutions.
You
see
right
now,
you
put
the
see
them
at
the
apex,
this
kind
of
works.
R
R
Okay,
so
this
is
an
example
zone
file
using
a
name,
the
websites
still
see
names
to
the
CDN
and
the
apex
is
a
named
to
the
CDN.
You
could,
of
course,
use
a
name
for
both
butts
and
trying
to
show
the
difference
here.
If
you
don't
do
a
query
for
the
the
website,
doc
need
a
BW,
you
get
a
cname
and
look
closely.
The
website
is
a
cname
to
the
host
at
the
CDN,
and
then
you
get
the
a
record
for
the
host
at
the
CDN.
In
a
name.
This
works
differently.
R
R
There.
Various
concerns
have
been
voiced
on
the
nizam.
The
in
a
sec
is
an
issue
depending
on
how
you
set
this
up.
You
may
need
online
signing.
There
are
many
ways
to
do
it
without,
but
people
are
concerned
about
this
loops
are
an
issue
for
a
cname.
You
know
what's
happening,
but
an
a
name
will
be
flattened
by
the
resolver
in
a
name
point
to
another,
a
name
we
imagine
there
could
be
undetectable
loops
there
and
solar
needs
to
be
done.
R
Another
issue,
his
team
shall
be
do
IP,
based
or
other
methods
for
picking
the
right
data
center
to
point
somebody
to
if
the
authoritative
does
the
a
name
resolution
for
you,
it
will
either
have
to
pass
on
a
DNS,
client,
subnet,
etc,
or
you
will
get
bad
results.
The
draft
proposes,
for
this
reason
that
resolvers
do
a
real
lookup
of
the
a
name,
but
we'll
have
to
see
if
people
actually
roll
it
out
and
final
concern
on
this
slide.
R
R
The
next
far
as
I'm
concerned,
now
that
we
are
adopted,
we
need
some
running
coat.
Many
people
have
running
alienum
coat,
but
not
exactly.
According
to
draft
the
drafts
need
some
restructuring.
We
have
separate
sections
on
authoritative,
regional
/
behavior
right
now,
but
the
primary
and
secondary,
authoritative
behavior
is
all
mixed
up
in
that
section
and
it's
confusing
people.
The
draft
needs
more
examples.
Even
this
presentation
has
more
examples
than
the
drafts
and
one
final
thing
right
now.
R
This
draft
mentions
v4
and
v6
the
EDS
client
subnet
drafts
or
RC
no
mention
fee
for
a
v6.
The
xpf
draft
mentions
both
I.
Imagine
that
it
might
make
sense
to
do
something
about
that.
Make
it
simpler
for
if
this
is
ever
necessary
to
create
a
new
address
type
in
DNS
without
having
two
updates.
Eight
other
RFC's
there
was
it.
Y
Hi
this
is
Andre
Caesars
Nick
hi
personally
I
find
the
draft
very
confusing
at
the
moment,
because
there's
in
the
alternative
name
server
section,
you
say
that
the
name
server
should
resolve
the
a
name
to
a
and
quote
a
and
then
there
might
be
might
be
records
that
coexist
in
the
zone
for
a
or
called
a,
and
how
do
this
play
together
and
there's
a
lot
of
other
stuff
like
this,
for
example,
in
the
DNS
exciting
section,
if
you
have
a
key
do
something,
if
you
don't
have
a
key,
do
something
else,
I
think
this
needs
to
be
simplified.
Y
S
A
S
Yeah
Stefan
Bosnia
I'm,
going
to
Paris
a
grumpy
guy,
because
the
goal
is
to
I
know
the
user
to
use
the
app
X
in
usually
visible.
You
don't
if
I
like
the
URL,
but
it's
it
should
be
noticed
that
it's
a
qtp,
specific
problem
because
all
the
other
protocols
other
way
to
do
it,
who
are
DNS,
indirection
and
mix
SLV,
it's
Tara,
so
it's
only
to
fix
a
weakness,
a
big
weakness
of
a
HTTP.
S
R
Z
Z
A
Z
R
Z
I
also
might
be
the
owner
of
zone
and
sign
it,
but
I
don't
run
any
Dennis,
Dennis
well,
I
had
and
in
the
scenario
that
there's
now
on
lines
signing
you
say
well
after
the
TTL,
the
the
authorative
name,
server
has
to
resolve
the
a
name,
sign
it
and
do
an
extr
to
the
secondary
etcetera,
but
still
then
the
I
know
in
many
practical
situations.
This
is
the
case,
but
yeah
it's
a
principal
cases.
Its
howdy,
miss
AK
was
once
designed
and
how
it's
now
being
used
and
I
think
that's
an
important
observation.
R
AA
Yeah
I'm,
John,
Levine,
I,
guess
about
us
I
have
kind
of
the
same
concerns
as
everybody
else.
On
the
one
hand,
this
is
a
problem
that
needs
to
be
solved,
but
I
have
a
hack
in
my
DNS
provisioning,
so
I
just
try
to
kind
of
do
it.
On
the
other
hand,
I
am
concerned
that
that
I
mean
I.
Do
offline.
Signing
I
have
no
intention
of
doing
online
signing
ever
so.
It
needs
to
work
with
that
and
I'm
wondering
you
know.
Maybe
we
could
see
if
we
could
do.
AA
It
is
something
that
smells
more
like
cname
is
like
the
a
and
and
quad-a
records,
or
they
just
return.
The
original
ones
from
the
up
from
the
source
like
cname,
does,
rather
than
renaming
them
into
your
own
zone,
and
the
other
question
is
I.
Have
this
vision
that
we
go
through
this
entire
process
and
we
finally
get
it
out?
You
know,
and
the
day
after
we
publish
that
somebody
says
I
do
boy
I
do
voice
over
IP.
Why
does
it
do,
sir?
Why
doesn't
it
do
some
records?
AA
I
mean
I,
don't
think
I,
don't
necessarily
think
we
need
a
huge
bitmap
of
every
possible
record
type.
But
I
would
you
know,
but
I
do
wonder.
I
mean
I
understand
the
main
use
case.
The
plenty
of
web
servers
for
you
need
a
part,
a
but
I'm,
just
wondering
if
we've
looked
hard
enough
to
see
if
there
are
people
doing
other
services
that
use
other,
it's
particularly
serve
an
MX
that
that
it's
worth
figuring
it
worth
seeing
whether
we
need
to
sweep
them
in
yeah.
R
F
AB
Countryside
I
like
this
drop
but
I,
don't
like
the
idea
of
authoritative
server,
resolving
and
online
signing
everything
else.
I
think
it's
too
complicated
to
implement
this
in
many
many
scenarios
and
I
think
it
would
be
nice
if,
because
I
think
there
it
is
there,
but
only
implicitly
that
an
option
that
the
a
name
record
would
be
combined
with
a
and
quad
a
record
of
so-called
last
resort.
So.
AB
Server
would
do
no
processing
at
all.
It
would
just
add
a
name
record
to
regular
quote
al-ansar,
and
in
this
case
the
recursive
resolver
that
is
capable
of
a
name
processing
would
get
some
better
IP
address
according
to
in
direction
of
a
name
record,
but
normal
resolver
would
get
the
a
records
of
last
resort,
so
we
could
somehow
gradually
go
towards
the
is
a
name
solution
without
the
complexity
of
server-side,
resolving
and
signing,
and
so
on.
The.
AB
AC
Now
I've
heard
several
people
say
things
like:
oh
it
should
just-
or
this
doesn't
cover
my
case
or
it's
too
complex
and,
and
maybe
part
of
the
problem
is
that
the
document
is
insufficiently
clear
about
why
this
is
hard,
because
what
we're
trying
to
do
right
is
is
fake,
a
whole
bunch
of
stuff
and
we're
trying
to
do
it
without
changing
all
of
the
installed
base
of
all
of
the
garbage
that
has
ever
been
shipped
on
the
internet
ever
at
least
another
day
and
and
so
on,
and
so
there's
a
whole
bunch
of
of
dependencies
that
you
know
and
and
decisions
that
we've
made
over
time
that
that
maybe
maybe
some
introductory
text
that
I
I
guess
I
kind
of
volunteered
to
do
now
that
I
hear
all
these
people
are
concerned
about
it.
AC
That
would
would
say,
look
here's
the
here's.
The
reason
why
this
is
as
hard
as
it
is
would
help
motivate
some
of
the
trade-offs
and
and
then
we
could
stop
having
a
discussion
about
well.
Why
don't
you
just
do
this
because,
for
instance,
on
Jon's
point
that
you
just
made
about
the
MX
thing?
Well,
I
I
know
of
at
least
one
implementation
or
a
whole
bunch
of
people
would
like
MX
to
work.
Fine,
and
the
answer
is
well,
you
can't
because
it
doesn't,
and
so
they
come
up
with
another
ant.
AC
You
know
they
come
up
with
a
different
hack
and
that's
the
way
that
it's
been
done,
but
there's
a
whole
bunch
of
stuff
that's
deployed
already
and
the
reason
it's
deployed.
That
way
is
because
everybody
is
cheating
in
using
the
eventual
consistency
of
the
DNS
to
convince
people
that
it
works.
So
I
I
think.
Maybe
if
we,
if
we
write
some
checks,
that
sort
of
explains,
that's
where
the
difficulty
is
we
might,
we
might
get
a
little
bit
quicker
convergence,
yeah.
P
G
T
Currently,
this
draft
is
at
the
O
3
version
that
came
out
in
July.
The
idea
behind
the
draft
and
the
phrase
it's
used
currently
in
the
abstract
introduction
is
that
this
is
for
managing
the
properties
of
long
lift
sessions,
for
example,
TCP
or
TLS.
In
this
specific
draft,
we
deal
with
two
properties
in
terms
of
being
able
to
set
session
timers
and
servers
being
able
to
indicate
to
a
client
retry
times
for
certain
operations.
T
T
This
draft
uses
a
new
format.
It
proposes
using
a
new
opcode
6is
tend
to
be
assigned
in
the
count
sections.
The
draft
says
that
the
counts
must
be
0.
Therefore,
there
can
be
no
ours
within
this
kind
of
message
and
what's
proposed.
Instead
is
a
new
theory
format
which
follows
directly
after
the
count
sections
in
the
payload.
T
What
I've
tried
to
do
on
this
slide
is
I,
walk
back
through
the
email
archive
and
I
just
try
to
gather
the
arguments
that
have
been
made
for
and
against
using
that
new
format.
The
proposal
to
use
the
TLV
one
of
the
ideas
behind
it
is,
if
we're
going
to
use
in
your
code.
This
is
an
opportunity
to
have
a
clean
break
from
using
ours.
T
Ours
have
fields
in
them
which,
for
example,
when
they
used
in
opt,
are
once
the
fields
are
overloaded.
You
could
also
argue
that
they're
redundant,
so
there's
a
feeling
that
the
RR
format
isn't
necessarily
the
right
one
to
use,
despite
defining
a
new
format
here.
What
it
also
does
is
because
we
have
an
opcode,
then
the
set
of
TVs.
You
have
effectively
form
a
new
opcode
space
underneath
the
new
opcode,
because
each
of
those
TVs
is
completely
flexible
in
how
you
define
the
data
in
it.
T
One
of
the
arguments
for
not
using
our
ours
was
that
there
are
error
cases,
so
you
would
have
to
worry
about
sessions.
Signaling
are
ours
any
having
normal
DNS
messages
and
vice-versa,
you
have
to
deal
with
the
case
where
these
shouldn't
ever
reach
a
cache,
because
they
shouldn't
get
there
and
a
range
of
error
scenarios.
T
The
counter
arguments
that
have
been
made
to
say:
no,
we
should
stick
with
an
RR,
even
though
we
have
a
new
opcode
r
that
passing
this
within
the
name
service.
Isn't
that's
difficult.
The
issue
is
the
knock-on
effect
to
every
element
of
the
DNS
ecosystem.
So
once
you
have
a
new
format
like
this,
all
the
string
of
tools
involved
need
to
be
updated.
So
if
you
have
write
a
string
or
string
to
our
conversion
formats,
we've
got
to
update
them.
T
You've
got
to
update
all
your
logging,
any
capture
tools
that
you
have
storage
formats,
so
this
has
implications
for
CDNs
for
doing
this
tap,
etc
and
any
tool
that
wants
to
pass
a
dns
message
will
have
to
cater
for
this,
because
at
the
moment,
by
using
our
R's
it
unknown,
our
arse
can
still
be
managed
within
that
framework,
or
you
can
just
extend
it
by
adding
a
new
RR,
but
because
this
is
an
entirely
new
format.
Those
tools
are
going
to
get
tripped
up.
T
The
other
argument
is
around
all
this
error
handling
and
it's
well.
We've
already
come
across
that
problem
with
opt
our
arse,
so
we
kind
of
know
how
to
solve
it
with
this
and
one
I
didn't
put
on
the
slide
is
of
course,
if
we're
using
this
new
format,
we
probably
need
to
think
about
deployment
issues
because
think
about
issues
we
ran
into
just
by
trying
to
use
a
DNS
0.
T
To
back
that
up.
We
did
just
a
little
bit
of
limited
memory
testing,
so
tom
has
a
test
tool
which
will
send
a
session
sickening
message
using
opcode
6
and
the
new
to
avi
format,
and
we
fired
that
offer
a
few
recursive
x'.
We
found
that
find
an
unbound
appeared
to
do
the
right
thing.
They
returned
not
implemented
with
an
opcode
of
6
Open
DNS
return
implemented,
but
the
opcode
was
0
in
the
response.
T
Sorry,
this
was
all
done
over
TCP
I
should
say
Google
when
it
got
this
message,
it
waited
a
second.
Then
it
shut
the
TCP
connection.
We
fired
it
at
DK,
geez
not
was
over
over
TLS
and
that
immediately
shut
the
connection.
So
this
these
obviously
aren't
blockers,
but
we're
making
a
list
of
yeah.
If
we
do
this
with
that,
there
are
some
things
that
might
need
to
be
fixed.
T
T
T
We
started
thinking
about
actually
using
a
new
format
and
we
took
a
look
at
the
text
in
1035
and
the
way
that
that's
written
is
very
much
here's,
the
DNS
message
or
Mac.
You
have
counts
and
have
are
ours
and
you
can
have
op
codes.
The
text
it
uses
to
describe
an
opcode
is:
it
is
a
4-bit
field
that
specifies
the
kind
of
query
in
this
message.
It
doesn't
say
anything
more.
T
So
none
of
this
indicates
any
expectation
choose
anything
other
than
the
standard
message
format,
so
it
doesn't
explicitly
prohibit
it,
but
it
doesn't
cater
for
it.
So
one
question
we
have:
is
there
any
other
document
that
clarifies
that
great?
If
there
is
to
have
that
reference,
I
leave,
mark
Andrews
is
participating
remotely
I
understand
he
has
a
strong
feeling
that
there
is
nothing
to
prohibit
doing
this
with
NOC
code.
T
The
other
question
is,
we
started
thinking
about
the
name
and
what
facilities
this
new
york
code
actually
provides.
So
at
the
moment
it's
called
session
signaling,
but
when
we
actually
looked
at
how
it's
being
used
in
service
discovery
documents,
that
name
is
actually
a
bit
misleading.
So
if
all
you
read
is
this
draft
in
this
context,
the
current
framing
in
the
current
language
could
easily
lead
you
to
believe
that
this
is
just
specifying
a
control
channel
or
a
channel
under
which
you
create
a
context
for
regular
deines
messaging
to
happen.
T
The
way
it
has
been
used
in
some
of
the
other
drafts
is
that
it
is
also
transporting
data
inside
these
TVs,
for
example,
in
the
post
draft.
The
server
actually
sends
the
new,
updated
data
back
to
the
client
in
a
server
initiated
session,
signaling
message
in
a
recent
more
recent
draft,
which
is
the
relay
draft
that
has
this
in
the
latest
version.
It
actually
has
the
case
where
a
mdns
wire
format
message
is
encapsulated
inside
the
data
of
a
TLV
that
goes
as
a
session
signaling
message.
T
So
what
what
struck
is?
Is
that
the
way
we're
doing
the
spec
is
there
is
nothing
that
limits
what
can
go
in
these
TVs,
and
so
we
just
need
to
be
clear
about
what
you're
getting
by
using
this
new
opcode,
and
so
we
think
we
should
rename
it
some
to
something
like
just
doing
a
session.
In
other
words,
this
is
a
different
way
to
do
dns
within
the
context
of
a
session
that
you
set
up
with
mechanism.
T
Assuming
me
detangle.
All
of
that
there
are
a
handful
of
issues
start
standing
on
the
o3,
and
these
are
ones
that
are
noted
in
the
document.
Looking
at
the
language
they're,
the
term,
that
session
is
used
very
liberally
and
in
the
most
recent
update,
we've
realized.
We
are
updating,
77
66
in
this,
so
we
need
to
be
clear.
It
in
the
language
I
think
about
what
a
session
is.
Is
it
a
SEM
766
session,
or
is
it
a
session
signaling
session,
so
that
needs
some
work?
T
This
version
of
the
draft
introduces
two
timers
one,
which
is
in
an
inactivity,
timer
the
inactive
timer.
No,
there
is
a
keepalive,
timer
and
I
think
we
need
a
bit
more
work
to
describe
the
fact
that
we're
introducing
a
kind
of
traffic
which
is
the
keepalive
message,
which
is
special
in
the
sense
that
it
doesn't
reset
the
inactive
timer,
whereas
every
other
kind
of
message
that
sent
on
this
session
will
do.
T
T
There's
a
subtle
question
is
that
the
order
they
received
or
the
order
they
are
transmitted
and
one
of
the
errors
this
came
up
in
is
when
we
talked
about
the
applicability,
if
this
too
quick
and
it's
still
not
unclear
whether
it
is
applicable
too
quick
or
not,
I
think
it
is
given
some
discussions
that
we
had
Christine.
You
want
to
talk
on
that
now.
Yeah.
F
The
problem
is
that
when
we
do
things
that
quick,
we
want
to
basically
process
the
server
to
process
the
message
as
they
are
not
received,
and
the
quick
transmission
itself
doesn't
guarantee
that
the
order
in
which
they'll
receive
is
the
same
as
the
order
in
which
they
are
transmitted.
Now
UDP
doesn't
guarantee
that
either
and
the
the
sentence
that
you
have
there
is
kind
of
weak
because
most
act.
What
does
that
mean?
I
mean
he
is
putting
the
message
on
a
queue
acting.
T
F
T
F
F
T
O
Your
Cheshire
from
Apple
I
believe
I.
Remember
the
reason
for
that
which
we
can
debate
and
may
disagree
with,
but
the
reason
was
there
may
be
operations
that
create
state.
The
future
operations
depend
on,
and
so
the
intention
of
this
was
if
we
wanted
to
support
that,
then
the
ordering
had
to
be
respected
or
got
two
ways.
F
F
Because
if
they
are
transactions
that
change
the
state
of
the
server,
you
have
to
wonder
whether
you
should
have
several
such
transaction
in
the
pipeline
or
whether,
on
the
contrary,
users,
just
one
or
maybe
in
each
transaction.
You
have
a
point
of
the
views.
One
minute,
there's
a
classic
sit
solutions.
O
To
sort
of
use
the
example
that's
are
I
was
using
how
one
of
the
first
clients
of
this
is
the
DNS
push
where
you
can
subscribe
to
be
told
about
change
to
record,
or
you
can
unsubscribe
if
the
transport
gets
those
messages
out
of
order
and
the
server
receives
an
unsubscribe
for
something
is
never
heard
about.
Is
that
an
error?
Should
it
return
an
error
code,
or
should
it
sit
on
that
and
wait
for
the
subscribe
to
come
in
that
it
was
canceling?
F
From
I
know
of
it,
what
you
would
do
there
is
that
I
mean
suppose
that
you
want
to
request
at
the
client,
doesn't
better
serve
all
in
a
bind
you
you
would
say
that
the
the
server
would
actually
reject
and
unsubscribe
if
he
does
not
seem
to
subscribe,
because
I
know
or
might
even
do
something
nasty.
But
the
client
should
wait
until
the
Sequoias
in
confirmed
to
set
an
unsubscribe.
So.
O
That
would
be
another
way
of
solving
the
problem
and
I
don't
feel
strongly.
So
if
the
working
group
can
decide
which
one
we're
going
to
pick
that's
fine,
if
we
can
rely
on
a
transport
like
TCP
to
deliver
things
in
order,
then
the
client
doesn't
have
to
wait
a
whole
round
trip
for
the
confirmation
before
it
can
proceed
to
the
next
step.
Right.
It's
not
limiting.
F
F
Is
an
optimization
that
says
that
if
the
Henderson
way
it
seems
are
flowing
3d,
the
cost
of
that
optimization
is
that
you're
mandating
a
sequencing
transport.
Yes,
which
has
its
own
cost
means
it's
also,
and
so
so,
basically,
you
have
one
design
that
attempts
to
gain
performance,
one
wave,
it
loses
performance,
the
other
way
it
says,
I.
O
Don't
think
I
want
to
spend
a
lot
of
time.
I
mean
I.
It
sounds
like
you
prefer
something
that
doesn't
require
the
transport
to
deliver
things
in
order
like
TCP.
Is
that,
like
a
quick
summary
of
where
you
stand?
Okay,
so
I'd
be
interested
in
hearing
other
people's
opinion,
because
I
really
don't
mind
it's
one
of
these.
It's
tricky
decisions
where
either
solution
would
work
perfectly
fine
and
those
are
the
hardest
to
agree
because
it
goes
5050
yeah.
AD
So
Ted
lemon,
just
an
additional
sort
of
complexity
to
that
is
that
so
session
signaling
generally
carries
state.
So
you
definitely
want
anything.
That's
sent
after
a
signaling
session,
signaling
message
to
be
processed
after
the
session
signaling
message.
If
you
don't
do
that,
the
state
will
not
apply
to
it
and
that's
bad
and
then
there's
the
other
case,
which
is
where
you
just
happen
to
have
two
DNS
messages
in
a
TCP
connection
or
a
quick
connection
that
are
not
socially
in
session
signaling
mechanism
messages
and
they
are
sent
in
a
particular
order.
AE
T
A
AC
AC
Some
of
these
things
could
be
processed
at
order
that
that'd
be
significantly
advantage
advantageous
in
other
cases,
so
I
think
I'm
increasingly
persuaded
by
Christians
argument,
but
it
occurred
to
me
and
I
said
this
in
the
jacquard
channel
that
that
we
might
take
a
page
out
of
dns
updates
a
book
here,
because
it
has
prerequisites.
Okay,.
AF
A
AG
Was
screaming
loudly
about
the
vibe
formatting
delays?
So
let
me
scream
here.
Basically
the
proposal,
if
I
understood
you
correctly
is
using
new
opcode
and
new
format
idea
and
right.
So
from
my
perspective,
it
seems
like
specification,
which
is
creating
DNS
version
two
over
the
version,
one
right,
because
the
unit
version
one
is
just
the
header
which
is
like
without
any
value
no
data
at
all.
At
the
end,
there
is
something
completely
unrelated
to
the
previous
DNS,
so
maybe
it's
time
for
the
clean
cut,
I
I'm,
you
know
I'm
not
insisting
on
the
old
DMS.
T
T
A
T
Very
quickly
on,
through
these
say,
just
minor
things
that
we
need
to
also
take
into
account.
We
stays
in
the
draft
that
an
impasse
proxy
should
not
blindly
forward
this.
We
don't
actually
say
what
empath
proxies
should
do
with
it,
and
also
in
the
O
3
version
of
the
draft.
We
explicitly
state
that
name
compression
is
forbidden
and
it
dawned
on
us
that
having
DNS
warm
up
messages
encapsulated
inside
TVs
is
in
conflict
with
that,
so
we
probably
need
to
revisit
it.
T
There
were
a
couple
of
other
issues
which
are
noted
in
the
draft,
but
we
haven't
come
up
with
a
solution,
for
one
is
the
fact
that
if
you
don't
have
an
additional
section,
you
can't
do
T
cig,
and
then
you
can't
do
any
easiness
zero
and
the
main
use
case
we
could
see
for
that.
We
lost
with
that
was
being
able
to
pad
these
messages.
So
a
solution
was
proposed
at
a
padding
TLB,
but
it's
not
in
the
o3,
so
that
does
need
catching
up
with,
and
there
was
previously
a
more
fundamental
question
about.
T
Does
actually
every
message
require
a
response,
because
it's
which
DNS
that
feels
natural,
but
in
some
of
the
service
discovery
cases
it
feels
really
redundant
and
I
think
the
relay
draft
actually
does
away
with
responses
in
some
cases,
because
that's
natural
to
the
message
by
the
last
thing
to
say
before
we
move
into
discussion
is
that,
as
I
said,
there
are
several
drafts
in
service
discovery,
in
particular,
push
that
depend
on
its
normatively.
So
this
is
whole
up
at
work.
T
So
this
is
something
that
we,
it
would
be
really
good
to
get
to
a
resolution
quickly
on
and
I'm
all
open
on
ideas
of
how
we
resolve
the
tale
V
versus
RR
debate
that
don't
involve
rock-paper-scissors
all
armwrestling
or
ever.
But
this
is
one
of
those
cases
where
I
think
we
have
two
camps
and
I'm
not
sure
how
we
move
forward.
On
that
say,
that's
for
the
working
group
for
yeah.
C
We
have
a
couple
minutes
yeah.
We
have
a
couple
more
minutes
because
actually
we
were
a
little
bit
ahead
of
time
with
that
discussion
which
felt
very
productive,
so
he
didn't
stop
but
kind
of
put
us
back
on
schedule.
So
we
have
a
couple
minutes
now
and
definitely
we
do
need
to
continue
the
discussion.
You
know
on
the
list
and
in
the
halls,
because
if
there's
a
relatively
quick
resolution
in
these
things
possible,
we
should
do
that.
This.
Y
But
you
might
be
aware
of
my
new
crusade,
the
DNS
bear
violations
and
I've
seen
a
lot
of
new
implementations
coming
up
and
people
implementing
DNS
protocol
in
various
languages
and
stuff,
like
that,
and
those
are
the
people
who
are
generally
not
here
and
and
those
are
who,
when
I'm
concerned
about
introducing
and
you
complete
a
new
format,
because
from
dos
implementation
I've
seen,
they
generally
tend
to
ignore
the
things
that
are
stable.
So
they
might
not
parse
the
OP
code
and
stuff
like
that.
Just
ignore
it
and
try
too
hard
this
here.
Y
He
is
it
as
a
DNS
format
and
in
break
horribly,
so
that
so
on
one
side
better
on
this.
But
on
the
other
hand,
if
we
break
this
earlier,
it's
might
lead
to
a
new
development
in
the
DNS
protocol.
Like
like
reinventing
some
things,
we
did
wrong
in
the
past,
but
it
leads
me
to
other
concerns.
I
have
with
this
sexually
the
depending
stuff
and
other
things
like
this.
Y
AD
Q
AD
AD
And
honestly
I
mean
that's,
that's
what's
good
about
it,
and
you
know,
as
far
as
as
far
as
like
you
know,
some
random
device
out
on
the
internet
crashing
or
returning
a
bad
result
because
it
gets
it
first
of
all
is
something
if
something
doesn't
look
at
the
opcode
and
tries
to
parse
that
the
the
payload
as
right.
What?
AD
AD
AC
AD
AC
AD
T
T
AH
And
and
I
like
that,
it
it
enables
all
sorts
of
things,
solves
problems,
potentially
solves
problems
we
currently
have
using
Eden
s0
enables
all
sorts
of
things
that
we
can't
do
currently
as
a
as
somebody
who
implements
monitoring-
and
you
know,
log
processing
and
all
those
things
I'm
not
particularly
concerned
about
the
extra
work.
If
I'm
conceal
the
messages
I
will
ignore
that
opcode.
If
I
am
concerned
about
them,
then
it
doesn't
matter
to
me
whether
it's
in
our
TLB
I
have
to
write
code
to
process
it
anyway.
AH
So
so,
there's
that
I'm
a
little
concerned
about
the
issue
of
embedding
DNS
messages
in
tlvs.
That
seems
a
little
bit
odd
to
me.
I
I,
remember
having
a
conversation
with
somebody.
I
think
he
was
in
brilliant
about
about
push
notifications
and
how
that
might
work
and
things
and
what
I
said
the
picture
I
had
in
my
head
and
we
were
having
that
conversation
was
a
TLB
would
set
up
the
session
set
up
a
lien
and
and
the
client
could
send
a
DNS
query
with
sunscreen.
O
AD
AD
O
AH
AH
The
the
I
guess
yeah,
it
feels
to
me
like
sort
of
a
layer,
violation
and
and
and
it
and
I'm
and
then
I'm
concerned
about
the
possibility
of
things
like
DNS
over
HTTP
over
TLB
over
DNS
like
we
can
up.
It
enables
some
really
weird
things
that
I
don't
think
we
need
to
embed
DNS
messages
in
the
TLB
itself,
so.
O
O
All
I
wanted
to
say
was
that
the
spirit
we
approached
it
was
you
created
this
document
that
define
this
new
container
format
and
we
thought
we
were
embracing
that
in
the
spirit
that
you
and
Ray
intended,
and
it's
only
recently
that
we
found
that
you
know
that
we
read
more
into
the
document
that
then
you
intended,
but
it's
what
we
were
actually
not
trying
to
we're,
not
trying
to
change
the
document.
We
actually
thought
we
were
embracing
the
spirit
of
it.
Yeah.
T
O
O
T
AF
C
AI
Tom
cruson,
Terry
I'm,
just
gonna,
say
I
like
the
TLB
format,
because
this
stuff
is
session
related
and
it
makes
you
think
about
it
differently
and
treat
it
differently,
and
this
separation
is
I.
Think
a
good
thing.
AI
C
C
Yeah
and
if
there
are
additional
issues
where
you
need,
we
need
more
feedback
to
get
done.
Ish
yeah.
This
is
actually
a
good
candidate
for
another.
For
an
interim
yes
and
get
everybody
that's
interested
in
maybe
some
of
the
folks
in
the
SSD
or
other
groups
with
they're
watching
this
work
also
yeah.
We
can
do
an
interim.
G
If
anybody
was
in
d-pryde
this
morning,
I
had
Daniel
Gilmore
presenter
draft
about
muxing,
DNS
and
HTP
over
the
same
port,
which
people
were
horrified
for,
though
many
people
actually
were
trying
to
solve
the
problem,
which
is
not
what
we
were
trying
to
do.
We
were
trying
to
warn
people
that
there
are
these
bad
architectural
things
you
can
do
if
you're
not
paying
attention
to
stuff
right
and
I.
G
That's
gonna
fund
'mentally
cause
some
breakage
right
or
cause
something
bad
to
happen
as
we
go
down
the
road
and
I
I'm
just
you
know,
we
should
sort
of
consider
that
as
we're
sort
of
reading
this
draft
and
I
think
a
few
people
have
sort
of
said
that
so
that
was
the
only
thing
I
wanted
to
sort
of
say
about
that.
So
thanks,
sir.
E
E
Essentially,
it's
a
way
of
putting
vines
dollar
generate
feature
into
an
RR
record
that
could
then
be
shared
in
zone
transfers
in
order
to
dynamically
generate
records.
It's
really
based
a
lot
of
people
were
under
the
impression
was
built
around
regular
expressions,
but
really
it's
only
based
on
matching
numbers
and
a
quick
example
here
shows
you
how
one
record
could
then
generate,
for
example,
whole
bunch
of
address
records
or
PTR
records
or
what-have-you
for
this
draft.
E
The
Birgeneau
six
draft
was
just
published
on
the
3rd
of
this
month
right
at
the
deadline
cutoff,
but
because
that's
the
way
we
all
do
things.
The
main
goal
here
was
to
simplify
the
draft,
so
a
lot
of
it
was
changing
around
to
make
the
language
a
lot
more
straightforward.
This
actually
had
a
significant
effect
on
the
total
page
count
dropped
it
by
50%.
E
Some
of
that
was
not
just,
of
course,
from
the
language
clarification,
but
things
like
taking
out
a
couple
features
like
there
was
this
feature
where
it
tried
to
modify
wildcard
semantics,
essentially
to
hide
the
effect
that
you
know
to
hide
the
overt
evidence
that
pattern
generation,
wild
carding
was
in
effect
here.
This
is
driven
by
some
operational
issues
that
the
folks
at
centurylink
it
had
where
they
see.
E
We
also
remove
some
of
the
octet
value
restrictions
to
make
it
a
lot
more.
Dns
e,
that
is
originally
they
define
patterns,
is
only
being
in
terms
and
the
substitution
data
that
you
could
use
only
in
terms
of
the
u.s.
ASCII
character
set
in
particular
printable
characters,
and
the
DNS,
as
we
know,
does
not
have
this
particular
restriction,
and
so
even
though
it's
unlikely
you're
going
to
want
anything
other
than
ussd.
E
Nonetheless
to
make
it
more
consistent
with
the
rest
of
the
protocol.
In
now,
it
essentially
allows
any
octet.
We
also
there.
Some
things
were
kind
of
wide
open.
The
way
it
was
originally
defined.
You
could
have
any
number
of
references
being
used
for
substitution,
limited
to
only
I
suppose
by
the
size
of
the
unsigned
short
for
your
entire
message
length,
but
in
practicality,
you're
going
one
far
fewer
than
that,
and
so
we
tried
to
limit
it.
E
I
think
the
current
number
is
32,
which
would
give
you
every
nibble
of
a
ipv6
address
so
tried
to
make
that
a
lot
more
constrained
as
far
as
simplifying
your
implementation
might
go,
and
then
there
are
a
whole
bunch
of
other
clarifications
that
exist
in
the
draft.
There's
still
other
ideas
that
want
to
be
pursued,
in
particular,
as
I
mentioned,
the
original
design
goal
included
really
modeling
a
lot
of
dog
that
dollar
generate
behavior.
E
As
far
as
being
able
to
format
the
way
records
looked
and
the
thought
there
again
was
that
having
familiarity,
you
know
that
people
would
see
that
hello.
This
is
just
like
always
generate
inside
a
record,
might
help
move
things
along
faster,
but
it
might
be
possible
to
doesn't
dollar
generate
itself
was
just
a
little
bit
too
flexible
in
what
would
should
be
expected
out
of
its
format.
Generation.
There's
also
another
record
in
this
draft:
the
NPN
record,
which
was
supposed
to
help
with
DNS
SEC.
E
Essentially,
it
gave
a
DNS
SEC,
like
version
for
these
generated
pattern
names
it
wouldn't
allow
you,
the
full
expressiveness
of
being
able
to
say
that
this
particular
pattern
would
always
generate
this
record,
especially
in
the
context
of
trying
to
hide
the
bulk
record
that
actually
generated
it.
But
it
turns
out
that
you
know,
as
I
was
trying
to
write
it
up
and
clarify
it.
I
was
there
significant
DNS
at
roll
out
issues
here?
E
E
All
of
those
have
big
enough
hurdles
that
it
doesn't
seem
wise
to
address
it
for
the
basic
use
case,
that's
desired
here
and
then
last
but
not
least,
another
thing
that
I
want
to
end
up
talking
about
and
I'm
surprised
that
John
Levine
I
don't
think
he
mentioned
it
when
he
was
up
the
mic
a
moment
ago.
Talking
about
a
name
but
there's
an
issue.
Did
you
mention
it
and
I
just
tuned
out
for
a
second
okay?
E
So
the
issue
is
essentially
that,
while,
while
some
people,
some
famous
DNS
cognizant
I,
have
declared
on
mailing
lists
that
it
is
a
myth
that
rolling
out
in
URR
is
hard.
That
is
relatively
true
when
you're
adding
an
RR.
That's
just
shipping
around
data
that
nobody
is
supposed
to
look
at.
What
the
our
data
is
when
you're,
adding
something
that
actually
has
semantics
on
the
server.
You
can
easily
get
in
the
situation
where
your
master
is
your
primary
server.
Has
this
record
and
then
is
being
transferred
to
servers?
E
E
Some
text
has
to
be
added,
I,
don't
think
the
bulbar
itself
is
going
to
solve
the
problem,
but
it's
a
wider
issue
that
the
working
professor
consider-
and
that
was-
and
we
would
like
to
adopt
it
as
a
working
group
document
to
move
forward.
These
others
what's
mentioned
here,
I
think
can
easily
be
done
under
the
auspices
of
finally
being
and
being
this
up
document.
C
G
E
AA
Okay,
I'll
sit
down,
yeah
yeah,
hi,
I'm,
still
John
Levine.
Yes,
I
have
to
say
that
this
latest
version
is
much
less
horrible
than
the
previous
version.
But
if
that
sounds
like
faint
praise,
it
is
and
I
mean
I,
don't
have
a
book.
I
stole
a
bunch
of
issues
with
it.
I
mean
I,
think
there's
a
certain
mean
I
think
the
least
bit
these
records
with
semantics.
That
secondaries
don't
know
about
problem.
You
know
it's
one,
that
I
guess
when
we
invented
DNS
SEC.
We
hoped
it
would
never
happen
again
and
and
there's.
AA
Know
we
already
a
bit
in
the
DNS
blacklist
world.
We
have.
We
have
a
stunt
server
called
rbl,
DNS
D
that
does
kind
of
this
stuff.
Okay,
and
nobody
has
ever
asked
to
have
rbl
DNS
these
junk
put
into
the
standard
DNS
spec
it
to
stun
server.
It
does
one
rather
peculiar
thing,
and
it
does
it
pretty.
Well,
you
know
enemy.
What
you
have
here
is
now
that
you
sort
of
do
per
generalized
it.
You
know,
as
far
as
I
can
tell.
AA
Don't
see
that
as
a
big
enough
issue
to
be
worth
all
of
the
damage
to
the
DNS
or
a
little
bit
create
Vienna's
cruft
that
this
requires
I
said
like.
Why?
Don't
you
guys
just
bytes
not
servers,
and
you
can
use
that?
You
know
it's
not
as
nice.
You
know
I
realize
I,
understand
it
as
operational
issues,
because
you,
like
you,
have
multiple
secretary.
AA
You
have
multiple
secondaries
with
multiple
with
multiple
other
providers,
but
I
don't
see,
I,
don't
see
the
issue
of
getting
them
to
to
support
your
stun
server
as
being
meaningfully
different
from
getting
them
to
do
to
put
in
all
this
stuff.
Okay-
and
my
final
thing
is
for
DNS,
SEC
I,
think
youth
bite
the
bullet
and
say:
if
you
do
this,
you
have
to
do
online
signing
you,
you
should
do
something
like
CloudFlare
is
malicious.
AA
Y
Three
I'm
John
most
of
my
comment:
I
had
just
drop
the
NPN
and
require
online
signing,
but
on
top
of
that,
the
DNS
a
keys,
have
two
bytes
specification
of
the
usage.
So
why
we?
Why
not?
We
think
about
adding
a
special
type
of
DNS
key
just
for
silent
about
records?
Yes,
okay,.
E
I've
had
a
similar
thought
that
you
could
had
a
couple
of
keys
in
its
own,
one
of
which
is
for
static.
Signing
of
you
know
for
a
a
zone
that
actually
mixed
this
in
two
types
of
data
that
your
static
key
offline
to
you
could
sign
everything
and
then
you'd
have
your
one
online
view.
That
would
be
the
rest.
Yes,.
Y
AC
I'm
Andrew
Sullivan.
The
reason
I
got
up
here
is
because
of
John's
remark.
Well,
why?
Don't
you
just
got
these
stunt
servers?
Why
don't
you
just
go
off
and
do
that
with
your
friends?
The
reason
that
people
don't
want
to
do.
That
is
because
it's
the
same
reason
that
we're
all
here
in
this
room.
This
is
this
is
the
reason
for
standardization
that
we
want
to
be
able
to
work
interoperable
with
various
other
people
on
the
Internet.
AC
So,
despite
the
fact
that
you
know
somebody,
who's
probably
paid
for
my
presence
here
would
would
dearly
love
to
close
this
all
up,
and
you
know
sew
it
up
nicely
so
that
nobody
else
can
play
in
this
space
on
the
purpose
of
getting
together
and
standardized
standardized
things.
This
way
is
precisely
so
that
we
can
create
more
competition,
have
a
better
ecosystem.
I
think
that's
important.
Yeah.
E
An
awful
lot
to
say
that
I
also
think
it's
important
I
mean
my
own
employer,
who
also
I
did
not
speak
for,
does
have
an
among
the
many
modes
of
its
authoritative
nameserver,
one
that
does
work
on
regular
expression
patterns,
and
so
we
could
perfectly
well
set
this
up
for
a
customer
who
says
I
want
to
do
this
really
large
zone.
Can
you
just
automatically
generate
it
and
step
time
to
transfer?
P
Demetri,
a
speaking
for
myself,
I
just
think
that
making
DNS
turing-complete
is
generally
around
GUI
to
go,
but
I
just
say
that
putting
computational
resources
to
another
party
is
again
conceptually
wrong,
so
not
because
I,
don't
like
mine
or
I,
don't
like
generate
I,
see
why
people
need
this,
but
I.
Just
think.
If
you
take
this
one
step
further,
it
would
go
in
the
wrong
direction.
So,
as.
E
E
Do
you
want
to
just
to
get
a
sense
before
bringing
into
the
lister
okay.
C
C
E
G
C
E
And
so
and
I
will
leave
it
to
my
think.
Mccune
this
press
presenting
his
I
will
be
stealing,
was
okay
to
describe
what
the
salient
differences
are,
but
in
the
case
of
surveil,
the
proposal
here
is
essentially
really
only
meant
to
cover
cases
where
things
are
humming
along
just
fine,
and
then
the
authorities
go
out
to
lunch
when
you're
trying
to
resolve
a
name.
We
still
we
don't
change
the
semantics
of
the
PTL
at
all.
E
They
would
still
be
essentially
so
we
don't
change
the
immediate
semantics
of
the
PTL
and
that
the
TTL
still
defines
the
maximum
time
before
which
you
should
attempt
to
refresh.
However,
traditionally
resolvers
have
been
expunge
the
record
from
the
cache
when
they
encounter
an
expired
TTL.
What
this
says
is
you
know,
keep
it
around
for
a
bit
longer
and
the
bit
longer
is
defined
a
little
bit
later,
but
essentially,
when
you
come
across
authorities,
so
you
can't
get
an
answer
from
any
authority.
E
Then,
within
a
short
period
of
time
you
should
send
a
response
back
to
the
client
before
the
client
finds
out.
There's
current
recommendation
that
this
should
be
around
1.8
seconds.
Then
your
resolver,
though,
keeps
trying
to
get
it
up
to
whatever
it's
normal
fetch
timeout
is
in
bind
used
to
be
30
seconds.
I,
think
they've
cut
it
down
to
ten
seconds
now.
Dippers
all
reduce
different
values.
E
It's
not
really
that
relevant
to
the
doc
other
than
don't
wait
just
1.8
seconds
you
should
keep
trying
along
and
in
this
particular
case
also
negative
responses
are
considered
to
be
a
successful
refresh.
If
you
had
your
in
dub
dub,
dub
example.com,
with
an
a
record
and
now
it's
an
X
domain,
the
NX
domain
is
a
successful
refresh.
E
That
is
what
you
should
be
serving,
even
if
you
have
to
rely
on
a
sir
stale
answer
in
the
future
and
then
after
a
number
of
another
period
of
time,
which
is
currently
recommended
to
be
days
to
allow
for
manual
intervention
at
the
authorities
for
fixing
whatever
problem
is
going
on
with
then
even
over
a
long
holiday
weekend.
Eventually,
then
you
expunge
the
data,
so
you're
tapping
your
cache,
sizin
and
everything
you
know
at
this
point.
E
You
have
a
real
problem
back
the
way
you
would
have
had
in
that
very
first
period,
and
the
goal
here
is
to
balance
data
integrity
with
resiliency,
because,
most
of
the
time
in
our
operational
experience,
the
answer
that
you
had
before
the
detail
expired
is
still
the
answer.
That's
going
to
work
even
after
the
detail
has
expired,
most
detail
refreshes
for
us
come
back
with
the
same
answer,
and
so
the
key
here
is
at
least
try
to
get
a
fresh
answer
before
you
decide.
You're
gonna
use
the
stale
answer
and
then
move
on
it
works.
E
I
wrote
a
PAC
4x9
back
in
2011.
It
has
smooth
over
a
lot
of
temporary
and
stability
and
even
prevented
several
major
incidents
for
us
things
where
you
know
our
web
servers
would
have
tried
to
connect
the
origin
and
failed
because
their
provider
had
come
under
das
attack.
For
example,
it's
been
contributed
to
ISE
now
for
inclusion
in
vine
9.12.
I
don't
know
what
the
current
implementation
status
is,
but
that
was
my
understanding.
Getting
a
thumbs-up
from
Vicky
and
wild
bull,
Bachman
Google
do
have
patents
that
cover
this
area.
E
Wow
akhom
eyes
in
particular
that
was
a
sign
from
Zira
Cole,
really
spells
it
out.
That
clearly
covers
it.
We
have
both
had
our
official
IPR
statements
with
using
the
license
declaration
to
be
provided
later,
but
the
code
was
contributed
to
is
see
under
the
Mozilla
public
license,
and
so
you
know,
even
though
it's
still
technically
the
will
be
provided
later.
We
expect
it
just
to
be
freely
available
and
the
big
questions
we
have
are
Warren
and
I
are
even
not
completely
in
agreement.
E
These
timers
that
exist
existed
because
this
was
what
worked
in
our
environment
when
I
originally
implemented
it,
but
it
is
worth
discussing
to
see.
Are
these
the
rightness
recommendations
to
make,
and
we
would
think
otherwise,
it's
pretty
straightforward
and
could
move
along
pretty
well
and
so
we'd
like
to
see
working
group
adoption
and
just
push
it
on
through.
E
T
P
AJ
Phenomenal,
so
this
is
a
huge
deviation
from
what
actually
the
DNS
sort
of
protocol
was
supposed
or
doing.
But
my
main
concern
is
this
is
supposedly
be
standards
track
and
it
describes
one
implementation
pretty
precisely
and
the
draft
notes
that
are
other
implementations
like
unbound
and
we
have
one
and
I
think
Cisco
also
has
one
which
might
also
have
IPR
on
that
I
think
it
might
be
worth
actually
writing
up
something
more
on
the
requirements.
AJ
E
So
again,
with
it
changing
the
idea
of
what
the
TTL
means
and
what
the
expected
standard
behavior
would
be
on
the
internet,
I
think
it
is
absolutely
relevant
to
being
standards
track,
and
you
know,
like
you
say
yes,
this
is
one
particular
implementation,
but
I'd
also
very
much
welcome
feedback
on
what's
a
better
way
of
doing
it
like
how
could
that
change?
You
know
what
aspect
of
the
requirements
would
changed
under
a
different
implementation.
Well,.
E
AK
W
I
guess
Warren
kumari
yeah
I
mean
I,
don't
think
that
we're
in
any
way
wedded
to
this.
So
if
other
implementations
want
to
describe
their
implementation,
you
know
we
can
include
those
as
well
or
something
similar.
You
know
this
is
not
the
best
way
if
you
all
works
better
or
if
you're
willing
to
describe
it
and
similar.
AJ
W
Z
E
A
E
W
Is
the
same
so
to
be
honest,
I
didn't
know
about
the
IPR
until
David
found
it,
and
then
one
of
our
lawyers,
sometimes
like
I,
can't
really
tell
if
this
applies
and
I
don't
really
know.
So
you
know
they
filed
as
much
as
seems
like.
It
could
possibly
be
something
that
rifice
this,
but
it's
sort
of
off
on
the
sides.
So
obviously
I'm,
not
a
lawyer
I've,
been
poking
our
lawyer
to
see
you
know
to
try
and
provide
more
info.
Okay,
but
they're,
not
hugely
interested
in
actually
thank.
E
Happened:
I'm
happy
to
discuss
that
on
lists,
but
I
think
that's
actually
the
exact
reverse
situation.
What
you
want.
Somebody
has
a
long
to
be
TTL
they're
unlikely
to
be
under
attack
for
that
long.
That's
going
to
impact
that
many
people
have
their
record
cache.
Where
is
somebody
like
a
CDN
not
just
to
CBN,
but
that
has
you
know
very
short
details.
It's
easy
to
make
a
fun
attack
that
would
cover.
You
know,
lasts
long
enough
to
cover
even
several
tto
extra
periods.
U
And
giovani
aside
en
it's
great
to
work,
I
think
it's
very
interesting
also
because
there's
a
current
trend,
a
lot
of
people
move
in
their
services
to
cloud
providers
and
there's
a
risk
of
collateral
damage
in
shared
infrastructure.
So
if
you
have
something
in
place
like
that,
we
kind
of
remove
all
but
the
long-term.
Let's
say
this:
incentives
for
attacks
the
DNS
infrastructure
so
I
think
it's
good
work.
Thank
you.
M
Thanks
this
is
this
is
a
draft
written
in
conjunction
with
including
sivaraman
than
Shanker
right.
Consider
considered
normal
case
of
events.
We
query
for
the
Horde,
a
wrecker
all
ww2,
calm,
it
stays
in
our
cache
TTL
the
record.
The
record
then
expires
a
little
bit
later.
We
clear
we
query
thrice
again,
it's
not
in
the
cache.
We
have
to
do
an
upstream
fetch.
M
Now,
let's,
let's
suppose
that
before
we
do
these
before
we
do.
The
second
query:
we
query
for
another
record
from
the
same
zone.
Food
comm
MX
will
also
make
a
couple
of
assumptions
here.
We
will
assume
that
with
every
response
we
retrieve
the
serial
number
of
the
zone
and
we
will
also
assume,
but
the
serial
number
of
the
zone
uniquely
reflects
the
contents
of
the
zone.
In
other
words,
if
there's
only
changes
the
serial
number
changes.
M
X
M
M
Now
going
back
if
the
serial
numbers
were
the
same
and
then
with
our
assumptions,
we
can
assume
that
the
zone
constants
hadn't
haven't
changed.
Had
we
queried
for
the
same
record
at
the
time
we
query
for
the
MX
record,
we
would
go,
we
would
have
got
the
same
data.
Therefore
we
we
are
entitled
just
simply
to
extend
the
TTL,
the
record
we
have.
M
So
the
zone,
the
zone,
serial
information,
how
do
we
get
the
zone
serie
of
information
we
could?
We
could
send
it
along
in
in
needy
NS
record,
but
the
zone
already
has
that
information
in
the
form
of
an
SOA
results
record.
So
the
simplest
solution
seems
to
be
to
just
add
the
SOA
results
record
to
the
to
the
response.
M
M
It
said
that
of
a
fundamental
theorem.
It's
fundamental
theorem
of
software
engineering
is
that
every
problem
in
computer
science
can
be
solved
by
adding
another
level
of
indirection
and
one
of
the
ways
British.
When
I
was
preparing
this
presentation
and
looking
back
over
some
previous
previous
RFC's,
it
occurred
to
me
that
a
similar
thing
applies
in
our
in
our
field
of
work.
M
Every
DNS
protocol
problem
can
be
sold
by
adding
another
a
DNS
option
and
that's
and
that's
notwithstanding
Ted
lemons,
somewhat
negative
opinion
of
them,
so
we
have
so
we
have
to.
We
have
the
client
had
in
any
DNS
option
to
the
query
and
it's
asking
the
server
to
return
that
SOA
resource
record
if
they
find
that
if
the
point
doesn't
need
it,
that
was,
if
there's
no
option
the
server,
that
server
doesn't
doesn't
add
it.
So
we
say
we're
saving
recycling
bandwidth.
M
The
server
adds
the
e
DNS
option
to
the
response
as
a
guarantee
that
the
zone
change
is
accompanied
by
a
version
number
change.
So
this
is
this
is
an
operator.
This
is
an
operational
thing
by
enabling,
by
enabling
this
up
this
option,
the
zone
manager
is
saying
that
every
time
my
zone
changes
I
will
update
the
serial
number.
M
M
Is
that
serve
as
easy,
anis
response
option
really
needed
because
it
could
be,
it
could
be
argued.
That's
simply,
adding
an
SOA
resource
record
to
the
additional
section
can
be
interpreted
that
the
server
supports
that
that
the
survey
is
saying
that
the
version
number
changes.
The
serial
number
changes
when
the
zone
changes
I
did
we
did,
we
did
have
a
bit.
We
did
have
a
discussion
of
this
I
mean.
M
Might
my
feeling
is
that
that
the
the
response
is
needed,
because
otherwise
we're
assigning
a
semantic
meaning
to
the
position
of
an
SOA
results
record
in
the
response
which
I
don't
know
I'm
just
unhappy
with
a
real
can
of
worms
is
how
should
we
cope
with
ECS,
where
the
respondent,
where
the
response
coming
back
depends
on
subnet,
so
you
get
it
so
you
get
an
SOA.
Is
it
covering
everything?
Is
it
covering
the
subnet
there
has
been?
M
So
that's
that's.
Basically
it
questions.
A
C
Think
the
next
day,
the
primary
next
step
here
is:
we
didn't
need
people,
since
it
is
a
new
draft,
and
since
these
questions
are
relevant
and
irrelevant,
we
will
be
looking
for
reviewers
for
the
for
the
graph
to
decide
whether
it's
it's
useful
uninteresting
and
should
whether
it
should
be
it
should
have
further
work
from
the
working
group.
Thanks
Lena.
AL
C
AL
A
Y
Answer
a
question:
if
it's
really
useful
I
think
the
effect
will
be
really
marginal,
because
you
need
a
support
for
the
EDS
response
option
laughing.
You
do
this
to
your
first
question
also
because
we
try
to
minimize
the
answers
and
now
you
are
blowing
in
up
again
so
I
think
you
need
a
DNS
response
option
and
in
this
case
the
effect
will
be
only
marginal
because.
K
K
AH
AH
That
requires
a
lot
more
thought
agreed.
I
I
have
previously
got
questions
from
ICANN.
Doing
TLD
operator
moves
that.
Well.
How
do
you
plan
to
deal
with
in
your
timing
with
you
know
if
somebody
extends
a
an
honor
sig
to
its
its
validity
period,
rather
than
the
TTL.
A
AH
W
So
I
thought
that
it
was
only
me
that
the
bad
idea
fairy
visits,
but
this
is
really
cool.
Are
you
so
one
of
the
things
I'm
not
sure
if
it's
gonna
be
all
that
useful,
because
you
need
to
do
another
look
up
into
the
zone
and
I'm
not
sure
if
the
way
that
lookups
happen,
that
happens,
that
often
right
I
don't
look
up
for
dub,
dub,
dub
and
maybe
two
other
things
and
then
possibly
not
for
a
long
time.
If
it
turns
out
that
I'm
incorrect-
and
that
does
happen
often
you
know.
AF
AK
A
AK
M
A
Q
AE
AE
All
the
work
so
I'm
happy
to
be
on
the
list.
So
in
terms
of
whether
it's
useful
one
idea
that
we
have
is
that
you
can
actually
look
at
a
thaw
retain
of
server
logs
and
you
can
look
it.
There's
a
I've
identified
this
a
pattern
of
queries
where
you
can
actually
look
at
the
queries
that
you've
gotten
and
estimate
what
benefit
you
would
have
gotten.
AE
So
if
you
have
access
so
I'm
gonna
go
through
the
doodle
data,
which
is
a
bit
tricky
because
it's
mostly
a
delegation
only
domain,
but
we
can
look
at
D
s,
records
and
things
like
that.
But
if
you
have
access
to
big
authoritative
zones,
then
then
talk
to
me
and
we
can
figure
out
a
way
to
actually
use
some
measurements
and
estimations
it
may
be
possible.