►
From YouTube: IETF-DNSOP-20211215-1700
Description
DNSOP meeting session at IETF
2021/12/15 1700
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
C
B
G
F
B
F
C
F
F
F
F
We
also
well.
We
already
announced
our
meetings
on
the
on
the
twitter
and
we
already
have
a
number
of
followers.
So
please
spread
the
word.
The
jabber
room
is
open.
I
think
there's
people
already
in
well.
The
minutes
are
taken
using
the
the
notes
tool
see
here
below
the
the
link
and
the
volunteer
ordeal
help
chairs
will
work
on
the
notes
on
the
minutes
here,
of
course,
with
all
mitigs.
F
F
Sorry
for
my
this
evening
for
today.
So
the
dns
terminology-
we
we
discussed
that
already
earlier
and
also
on
the
mailing
list.
I
think
we
think
it's
a
good
shape.
We
have
to
discuss
a
number
of
open
issues,
so
we
reserve
their
30
minutes
with
paul,
and
the
second
draft
on
on
the
agenda
is
the
delegation.
Revalidation,
schumann,
paul,
viksey
and
punit
is
added
as
an
editor
to
the
document.
So
thank
you
punit.
F
C
E
F
F
E
E
I
have
opinions,
I'm
sure
some
of
you
have
noticed
that,
but
in
fact
what
we
really
want
is
consensus
on
where
to
go
so,
like
I
say,
I
have
a
couple
of
slides
on
these
two
topics
and
then
I'll
hand
it
over
to
the
chairs,
who
you
know,
have
a
better
ability
than
I
do
on
calling
consensus
in
a
fair
fashion.
So
let's
do
invalid
work
wic
first,
so
the
definitions
that
are
in
the
current
draft
were
added
in
rsc.
8499
that
is
remember,
84.99
was
was,
is
the
v2
of
our
terminology
document?
E
E
E
So
the
basic
problem
we
have
for
in
bailiwick
is
that
there
are
no
definitions
in
the
source.
Rfcs
we
can't
say
here
is
how
in
baileywick
was
defined
before
so.
What
we've
done
in
rfc
8499
is.
We
came
up
with
some
definitions
and
then
we
added
sibling
glue
and
we
added
a
few
things,
but
there
is
now
a
large
disagreement
about
whether
what
we
got,
whether
it's
better
to
say
what
we
got
or
to
leave
it
undefined.
E
There
is,
in
my
mind
and
again
just
my
mind,
a
weak
consensus,
not
a
strong
consensus
to
abandon
any
discussion,
because
any
discussion
that
gives
definitions
will
be
confusing
and
not
necessarily
match
what
people
are
saying.
I
have
a
preference
to
try
to
define
things.
That's
why
you
know
I
started
the
original
document
and
I
believe
that
kazunori
also,
since
he
has
done
a
lot
of
refinement
on
some
of
my
blathering,
would
also
like
things
defined.
E
E
Even
if
it
is
something
saying
gosh,
we
can't
define
it
or
the
working
group
might
come
to
consensus
on
a
definition.
So
do
look
at
that
archive.
Although
tim,
you
said
that
you
were
going
to
be
summarizing
there,
but
it
would
be
good
for
us
to
deal
with
this
because
it
is
a
term.
It
is
a
term
that
people
hear
and
we
should
at
least
acknowledge
that
it's
a
term
that
people
hear
so
going
on
a
bit
let's
deal
with
glue.
E
So
here
is
the
first
part
of
the
current
text,
which
quotes
a
little
bit
out
of
rfc
1034,
which
talks
about
what
happens.
If
you
don't
have
glue-
basically
it's
it
sort
of
says
what
glue
is,
but
it
doesn't
actually
say
this
is
glue
and
then
here's
more
of
the
text,
that's
in
the
current
document
in
84.99
and
in
in
the
draft
which
says
okay.
E
So
I
looked
around
at
generally
at
how
people
talk
about
glue
and
we've
actually
in
the
itf
had
a
couple
of
discussions
specifically
related
to
glue
in
the
last
couple
of
years
for
things
in
the
deprive
working
group.
That
is,
if
you
want
to
have
things
attested
to
by
a
parent
in
a
signed
way
and
such
that
is
not
what
they're
normally
attesting
to.
What
are
they
attesting
to?
Are
they
signing
the
glue,
and
so
people
use
the
word
glue
a
lot
and
that's
been
coming
up
in
other
places.
E
So
I
have
proposed
this
definition,
whereas,
where
I'm
ripping
out
some
of
this
stuff
and
trying
to
give
a
succinct
definition,
I
think
we
can
agree
that
not
everyone
will
agree
with
this
definition
of
glue,
because
some
people
think
glue
is
what
they
think
glue
is
at
the
moment,
and
we've
certainly
seen
that
in
the
discussions
around
deprived,
where
some
people
will
say
glue
is
only
addresses.
It's
how
you
find
the
server
and
other
people
say
no
glue
is
about
what
we
know
about
the
server
that
is
not
signed
by
the
authoritative.
E
Sometimes
it's
called
whatever
paul
maca
petrus
felt
in
30
years
ago,
but
sometimes
it's
called
glue
data,
so
but
1034
also
then
says
to
fix
this
problem.
A
zone
contains
glue
rrs,
which
are
not
part
of
the
authoritative
data,
and
our
address
are
ours.
For
the
server,
so
that
part,
I
think
everyone
agrees
that
glue
contains
addresses.
E
These
rr's
are
only
necessary
if
the
name
server's
name,
is
below
the
cut
and
are
only
used
as
part
of
the
referral
response.
We
might
even
cut
out
those
last
two
sentences
from
this
definition
of
glue,
but
it
gives
a
little
bit
of
context,
but
I
also
think
it's
important
to
then
quote.
The
second
part
which
says
glue
above
includes
any
records
in
a
zone
file
that
is
not
properly
part
of
that
zone,
including
name
server
records
of
delegated
sub
zones.
Ns
records
address
records
that
accompany
those
ns
records.
E
B
So
we
had
it
best
in
our
head
right
as
well,
and
paul
waters
did
a
good
job
sort
of
writing
a
bunch
of
this
up,
and
then
he
had
a
comment
about
sibling
zones
and
sibling
glue,
which
seemed
to
get
some
like
agreement
like
this
seem
to
make
sense,
sibling
zones
being
two
zones
whose
delegations
are
in
the
same
parent
zone
and
then
sibling
glue
the
addresses
of
name
servers
that
are
in
a
sibling
zone.
Those
seem
to
get
some.
You
know,
like.
B
Oh
people
seem
to
be
okay
with
that
on
the
mailing
list.
A
side
note
I
was
looking
at
the
glue
is
on
optional
draft
and
they
use
instead
of
baileywick,
they
use
in-domain
glue,
which
I
I
think
you
know
is
a
reasonable.
You
know
it's
like.
Okay,
that
sort
of
you
know
is
a
useful
sort
of
data
point.
I
know
tony
was
saying
that
in
baileywick
he
feels
is
sort
of
overused.
B
One
thing
that
we
thought
is
is
keeping
separate.
The
glue
definitions
for
the
dns
protocol,
like
what
does
dns
need
for
glue
versus
what
like
a
registry
requirement,
would
need,
and
I
do
think
we
should
they.
We
should
definitely
keep
those
separate
and
define
those
and
maybe
they're,
not
both
called
glue.
Maybe
they're
called
something
different.
I
don't
you
know,
I
don't
know,
but
I
don't
like
to
get
them.
B
I
think
when
we
mix
them
up,
it
gets
things
all
sideways
and
then
on
the
next
page,
with
something
from
tony's
one
of
tony's
emails
he's.
I
know
I
asked
him
about
coming,
but
he's
switching
jobs
and
he's
sort
of
tied
up,
so
he
apologized
and
ben.
I
think,
on
the
next
page
tony
had
made
a
comment
in
bellywick
he
called
the
property
of
a
name
server
which
did
not
seem
completely
accurate
and
and
or
is
it
the
property
of
the
nsa
records
of
the
q
name
right.
B
So
that
was
a
something
that
sort
of
popped
up
in
that
you
know,
and
then
he
said
well,
we
can't
use
in
belly
work
anymore,
so
we've
got
to
just
sort
of
you
know,
move
on
to
something
else,
so
that
was
where
I
sort
of
saw
that
sort
of
that
mail
thread.
So
I'd
love
to
hear
some
comments
on
folks.
Let's
go
back
and
talk
about
this.
B
B
E
E
E
Registries
have
different
requirements
for
the
definition
of
bailiwick.
I
would
absolutely
not
want
to
have
any
anything
about
registries
there.
That
is,
a
registry
is
a
zone
holder
and
they
should
do
exactly
everything
that
is
needed
to
hold
his
own.
I
also
don't
think
we
should
be
talking
about
that.
I'm
skipping
ahead
now,
but
I
also
don't
think
we
should
be
talking
about
registry
requirements
for
glue.
That
is
even
if
registries
have
contracts
with,
say
a
certain
organization
about
how
they
handle
glue.
E
If
we
haven't
defined
glue.
Well,
that's
our
fault.
We
should
not
be
taking
somebody
else's
interpretation
of
how
we
defined
it
badly
or
didn't,
define
it
and
then
say:
oh
well,
since
they
think
we
defined
it.
This
way
we
should
follow
along.
I
think
that
that's
actually
really
a
bad
idea,
given
that
we,
you
know
both
1034
and
2181,
had
a
picture
of
what
they
meant
with
glue.
E
But
let's
note
that
they
didn't
talk
about
bailiwick,
and
so
I
think
it's
okay
to
say,
people
started
using
this
term.
You
know
what
we
probably
shouldn't
have
to
me.
That's
an
okay
outcome.
I
think
we
should
acknowledge
that
the
term
was
being
used
and
I'm
not
in
favor
of
saying
some
people
think
x
and
some
people
think
y,
because
there's
absolutely
going
to
be
people
who
think
z
and
a
fair
number
of
people
who
will
think
x.
You
know
today
and
why
tomorrow,
but
I
think
it
would
be
good
for
us
to
acknowledge
it.
B
B
E
G
H
F
F
And
there's
also
a
remark
by
fujiwara-san
and
schumann
about
the
other
draft.
The
new
glue
is
not
optional.
That
should,
the
definition
should
be
in
sync
should
be
consistent,
so
waiting
for,
or
indeed
we
don't
necessarily
have
to
wait
for
the
draft
to
be
finished.
The
glue
is
not
is
not
optional
but
work
towards
an.
C
Point
out
is
that
previously
there
have
been
multiple
cases
in
the
terminology
documents
where
what
we
ended
up
documenting
was
that
a
particular
term
was
ambiguous
and
we
can
even
we
could
either
discuss.
You
know
how
different
different
operators
different
participants
in
the
system
are
using
the
same
term
and
document
that
it
is
ambiguous
and
it
is
context
dependent
or
even
say.
F
E
E
That
says,
basically
what
a
few
people
on
the
list
have
said,
which
is
this
is
not
a
useful
term
like,
like
you
know
it.
The
the
differences
and
definitions
are
are
fairly
huge
and
therefore
it's
not
a
useful
term
glue.
I
think
that
everyone
agrees
is
a
useful
term
and
we
might
have
to
and-
and
I
sort
of
tried
to
in
the
in
in
my
proposal
show
the
two
different
ways
that
it's
used.
E
I
don't
think
that
there
are
more
than
those
two
different
ways
and
I'm
sensitive
to
what
mattias
suggested
about
maybe
having
a
different
term
for
the
2181
definition,
which
is
addresses
plus
croft,
but
I
would
certainly
want
to
see
a
discussion
on
the
mailing
list
about
that,
but
I,
I
think
you're
right
suzanne
that
we
can
say
this
term
is
not
a
useful
term
because
it
it
has.
You
know
so
many
definitions
and
I
would
I
would
lay
that
for
baileywick.
D
D
The
re,
the
reason
it's
not
a
useful
term
is
some
people
use
it
to
mean
sort
of
this,
and
some
people
use
it
to
mean
sort
of
that
and
some
people
use
it
to
mean
something
completely
different,
and
my
thought
for
that
is,
I
think,
a
lot
of
non-dns
people
are
also
going
to
look
at
this
document
and
when
their
random
dns
expert
tells
them
the
reason
your
domain
doesn't.
Work
is
because
the
non-bailiwick
in
dns,
sorry
and
glue
is
not
actually
working.
D
D
B
Yep,
no
absolutely
worn
and-
and
I
think
we
do
need
to
define
it
because
I
I
know
I
point
people
non-dinas
people
to
this
document
to
read
about
stuff
like
glue
and
things
of
that
nature,
right
and
and
as
paul
mentioned
there
is
this
issue
coming
up
in
deprived
about
what
people
think
about
is
glue
non-dna
as
people
trying
to
do
stuff-
and
I
don't
fault
them-
it's
just
that
we're
not
defining
it
in
in
a
clearer
way,
is
okay,
paul!
Does
that
give
you
directions.
C
C
It
does
feel
like
we've
made
some
progress
here,
if
only
by
saying
what
we're
not
trying
to
do
but
yeah.
Let's.
Let's
certainly
folks,
are
welcome
to
have
additional
commentary
on
the
mailing
list
about
how
these
terms
should
be
defined,
and
we
will
attempt
to
get
some
new
text
yeah
after
some
further
discussion
with
paul
just
about
what
that
that
should
look
like.
G
F
F
I
I
Of
the
draft
is
largely
done.
We
just
have
a
few
remaining
issues
and
a
bunch
of
us
finally
found
the
time
to
get
together
to
identify
those
issues,
as
you
might
have
heard.
Paul
suddenly
has
a
lot
of
free
time
on
his
hands
now.
So
that's
very
good
and
we
also
recruited
punit
to
help
us
out
who
was
already
involved
in
early
discussions
of
the
draft
anyway.
I
So
next
slide,
please
all
right.
So
I'd
like
to
reorder
the
discussion
a
bit
and
move
this
item
to
the
end
so
that
we
can
get
through
some
of
the
quicker
items
first,
but
essentially
we
described
in
the
draft
a
simple
and
a
more
detailed
revalidation
algorithm,
and
there
was
a
bit
of
put
push
back
against
the
complex
one.
I
So
this
simple
approach
came
from
a
suggestion
from
ralph
delmons
and
ml
labs
and
the
more
complex
one
is
the
original
one
from
paul's
resin
proof
wrap,
but
so
the
three
of
us
talking
paul
now
has
some
new
clarifying
and
motivating
text
for
the
latter
and
we'd
like
him
to
discuss
and
walk
through
that
in
some
detail.
So
we'll
leave
that
to
the
end
and
let's
move
on
to
the
next
slide.
I
Okay,
so
the
next
issue
is
the
dsttl
and
how,
if
any
in
any
way,
it
should
be
used
as
part
of
revalidation.
So,
interestingly,
the
dns
protocol
specs
today
say
that
the
ds
and
the
delegating
nsttl
should
match,
but
in
practice
that's
not
really
true
for
a
variety
of
reasons.
So
the
latest
text
says
that
resolvers
may
use
the
dsttl
in
preference
to
the
delegating
ns
to
compute
the
revalidation
interval,
and
we
didn't
really
have
a
good
sense
for
whether
there
was
consensus
for
that
text.
I
I
I
I
I
There
was
a
suggestion
made
to
include
a
treatment
in
the
draft
of
what
resolvers
should
do
if
the
entire
ns
set
is
assessed
to
be
lame.
That
is
if
we
can't
reach
any
of
the
name
service
for
the
child
zone,
and
the
proposal
was
to
say
that
resolvers
should
go
back
and
try
to
continue
to
perform
revalidation,
but
with
some
sort
of
hold
down
timer
so
that
they
aren't
constantly
spinning
in
a
loop
trying
to
do
this
and
effectively
causing
a
denial
of
service
attack.
I
So
our
current
thinking
is
that
we
don't
really
need
to
discuss
this
resolvers
already
have
to
deal
with
this
situation,
whether
they
implement
this
draft
or
not,
and
presumably
they
already
have
a
sensible
way
to
deal
this.
So
in
the
interests
of
keeping
the
draft
simple
and
focus
on
its
main
goal.
Our
suggestion
is
that
we
don't
say
anything
about
this,
but
you
know
we're
open
to
alternative
thoughts
on
on
that
topic.
Let's
move
on
to
the
next
slide.
I
There
were
a
couple
of
optimization
suggestions
that
have
been
made.
These
ones,
I
think,
mainly
came
from
olafur
and
friends
at
cloudflare,
so
the
first
one
is
that
resolvers
could
cache
whether
or
not
an
authority
server
is
doing
minimal
responses
or
full
responses
with
the
nsa
populated
in
the
authority
section
of
the
responses,
and
if
they
were
doing
the
latter,
then
we
could
forego
explicit
child
ns
said
fetches
for
subsequent
interactions
with
those
authority
servers.
So
on
the
face
of
it,
this
sounds.
You
know
reasonable.
I
It
might
save
the
resolver
some
work,
but
we
have
a
few
concerns.
It
does
involve
additional
complexity,
storing
additional
state
on
the
resolver
for
a
currently
unknown
gain
right.
I
think
you'd
have
to
do
a
kind
of
a
measurement
study
to
figure
out
whether
or
not
it's
worth
doing
or
not,
and
also
the
other
issue
is
how
to
quickly
and
correctly
detect
estate
changes
on
the
authoritative
server
if
they
change
from
you
know,
minimal
to
non-minimal,
etc,
etc.
G
I
So
the
idea
is
this:
could
obviate
the
need
for
resolvers
doing
explicit
child
and
a
set
fetches
for
sign
zones.
However,
again
the
question
here
is:
this
is
additional
complexity
for
unknown
gain,
or
at
least
as
of
yet
unquantified
gain,
and
also
this
kind
of
moves.
The
draft
into
discussion
of
authoritative
server
behavior,
which
it
wasn't
doing
before
it
was
focused
only
on
resolver
behavior.
So
this
kind
of
expands
the
scope
of
the
document
beyond
its
original
intentions-
and
you
know,
maybe
we
should
have
some
concerns
about
doing
that.
I
So
again,
our
suggestion
is
a
reasonable
idea
to
consider
and
think
through,
but
let's,
let's
not
discuss
this
in
the
draft
for
now
and
let's
move
on
to
the
next
slide,
which
is
abuse
prevention.
So
I
I
have
brought
up
this
issue
in
the
past
of
how
resolvers
can
protect
themselves
against
abusive
configurations
deployed
by
others
that
may
make
them.
You
know
do
too
much
work,
but
we
haven't
said
anything
about
this
in
the
draft
yet,
but
once
we
recruited
putin
into
this
effort,
he
raised
it
again.
I
The
way
that
thing
could
surface
in
this
draft
is
if
authoritative
servers
are
deploying
extremely
low,
ttls
and
causing
resolvers
to
perform
very,
very
frequent
revalidations,
and
the
obvious
suggestion
here
to
mitigate
that
is
that
resolvers
should
place
some
kind
of
lower
bound
on
how
frequently
they
are
willing
to
revalidate,
and
so
you
know,
we
should
state
something
about
that
in
the
draft,
along
with
possibly
recommending
a
default
value
for
that
lower
bound,
but
we're
open
to
suggestions
and
discussions
on
that
point
and
next
slide.
Please.
I
A
A
A
Okay
windows
rides
again
by
the
way
I
was
not
the
first
person
in
this
meeting
to
use
powerpoint.
So
this
is
about
the
complicated
part
which
was
section
four
of
that
draft
and
to
remind
everyone.
This
came
from
an
expired
draft
from
2010,
and
so
the
text
that
was
in
there
was
a
little
bit
naive,
as
such
things
turned
out
to
be
in
hindsight.
A
Now,
a
simpler
approach
was
proposed
for
this
draft
and
that
won't
work
and
I'll
explain
why
and
then
I'll
tell
you
the
clearer
approach
which
has
not
been
seen
by
the
mailing
list,
partly
because
it
was
done
at
about
midnight
and
partly
because
it
it
uses
the
term
in
bailiwick,
which
I
now
understand.
We
can't
use.
So
I've
got
some
some
rework
to
do
and
I'm
hoping
to
get
some
input
from
this
interim
meeting
on
on
those
topics
so
that
I
can
then
post
this
text
to
the
mailing
list.
A
This
text,
by
the
way,
is
not
in
the
current
draft,
but
it
is
inclusive
of
everything
else
that
is
in
the
current
draft.
It
does
not
mention
the
prevention
of
abuse,
because
that
was
left
as
an
unknown,
but
the
other
changes
which
schumann
has
as
enumerated
here
are
are
coherent
with
this,
or
this
is
coherent
with
them,
as
you
prefer.
A
I
do
want
to
say
that
the
res
improve
keyword
has
taken
off.
I'm
happy
to
have
inspired
this
residential
improvement
e-commerce
site-
I
I'm
not
affiliated
here,
is
the
simple
mechanism
and
it
won't
work
partly
because
there
isn't
a
normal
iterative
algorithm
that
would
cause
delegation
revalidation.
A
We'd
have
two
other
problems.
One
is
that
the
revalidation
process
still
has
to
be
described
and
the
other
problem
is
more
than
one
delegating
ns
set
can
be
stale
in
this
way,
and
you
don't.
You
can't
just
go
to
the
closest
encloser,
because
that
may
be
inside
of
let's
say
a
data
attacker's
delegation
hierarchy
and
they
may
put
a
longer
ttl
on
that.
Just
to
frustrate
naive
revalidation.
A
You
really
have
to
be
able
to
look
at
the
entire
upward
chain
to
make
sure
that
the
entire
upward
chain
is
still
valid
in
in
the
sense
of
ttl
coverage
so
that
it
kind
of
holds
up.
If
you
will,
it
becomes
the
the
foundation,
the
virtual
foundation,
under
the
answer
record
that
you
wish
to
use
in
a
response.
A
G
A
That
sort
of
architecture
it
would
be
necessary
to
tag
each
delegation
with
the
one
it
came
from,
so
that
you
can
walk
through
them
up
toward
the
root.
So
that
is
a
a
point
which
was
not
raised
in
the
20
2010
text
but
which
will
be
covered
here.
So
we're
talking
about
the
delegating
or
ancestral
nsr
set,
and
you
know
you
could
say
the
parent
zone,
and
perhaps
that
is
a
change.
I
will
bank
after
hearing
the
previous
part
of
this
working
group
meeting.
A
But
the
idea
is
for
a
delegation.
You
have
to
know
where
it
came
from
and
you
have
to
know
what
it
said.
At
least
you
have
to
remember
what
the
ns
record
set
was
above
the
the
cut
and
what
the
ttl
of
that
was,
and
you
also
have
to
remember
the
ds
ttl.
You
don't
have
to
remember
the
ds
record
set
that
could
be
allowed
to
expire.
If
you're,
not
a
validator,
you
probably
don't
care,
but
you
have
to
remember
what
the
ttl
of
that
was
because
you
need
to
minimize
against
those.
A
So
what
it
means
to
revalidate
is
to
just
determine
whether
the
delegating
ns
record
set
has
been
remembered
for
too
long.
If
it,
if
you
had
it
in
cash
longer
than
the
lower
of
the
two
ttls,
then
you
it's
kind
of
out
of
time.
I
don't
want
to
use
the
term
expired
here,
because
expired
would
mean
you
know
it's
it's
bad
and
it
must
be
refetched.
A
What
you're
doing
is
you're
saying
is:
is
it
still
valid
and
if
it
is,
then
you're
not
going
to
change
anything
in
in
some
cases,
so
the
in
the
language
of
the
following
paragraphs,
the
point
at
which
a
delegation
to
a
delegation
or
actually
any
delegation
point
has
been
discovered
to
be
out
of
time.
That
delegation
is
referred
to
in
the
following
text
as
a
revalidation
point.
A
This
is
the
hard
part
this
is.
This
is
the
part
that
is
still
complicated
in
the
style
of
tooth
2010
and
it
uses
in
bailiwick
and
by
the
way,
the
the
logic
from
2010
was
written
up
after
it
had
been
implemented
in
a
name
server
which
was
not
open
source
and
so
never
saw
the
light
of
day
and
while
rewriting
this
text,
I
found
a
bug
in
the
mechanism
which
in
fact
was
present
in
the
code.
So
this
has
been
useful,
although
that
code
base
is
dead.
A
A
You
know
the
one
you're
you're
considering
and
then-
and
so
I'm
referring
to
that
as
the
second
closest
valid
validation
point
and
that's
that's
tricky,
but
the
ultimate
mechanism
of
revalidation
is
to
send
a
query
for
some,
and
I
apologize
mr
hoffman
in
baileywick
name
for
the
second
closest
cash
delegation.
Point,
because
what
you're
hoping
to
to
expose
here
is
a
response
from
the
delegator
that
tells
you
whether
the
delegation
that
you
want
to
use
is
still
valid
and
that
one
might
also
be
expired.
A
But
you
still
have
to
see
if
the
revalidation
point
says
the
the
servers
at
the
revalidation
point
say
that
the
delegation
you
want
to
use
still
exists
because
if
it
doesn't,
you've
got
a
lot
of
pruning
to
do
and,
and
so
there's
again
this
this
part
is
a
little
bit
crazy.
It's
midnight
talk,
midnight,
speak
and
I'll
improve
this
before
it
hits
the
mailing
list,
but
this
is
where
the
bug
was.
A
So
if
the
response-
and
this
by
the
way
is,
as
I
said
earlier-
inclusive
of
schumann's
earlier
points,
if
the
response
is
that
the
name
you
want
doesn't
exist
anymore,
yet
then
you've
got,
you
got
to
do
some
pruning
if
the
referral
is
to
a
different
name.
In
other
words,
the
hierarchy
has
changed
to
shape
com
used
to
delegate
to
example.com,
but
now
somehow
com
delegates
to
foobar.example
that
that's
allowed.
A
You
can
have
an
in
bailiwick
empty
non-terminal
in
or
an
end
zone,
empty
non-terminal
in
the
parent,
and
so
it
won't
always
be
semantically.
The
parent
zone-
it
is
the
ancestor,
but
if
the
ancestor
is,
is
telling
you
that
the
shape
of
the
hierarchy
has
changed,
then
you
got
some
pruning
to
do
or
if
it
still
the
same
name,
but
it
points
at
a
set
of
name
servers
that
have
nothing
in
common
with
the
one
you
had
cached.
A
That
would
be
another
case
where
you've
got
some
pruning
to
do
now
again,
we're
using
the
term
in
bailiwick
I'll
fix
that,
and
so
you
are
in
this
case,
gonna
have
to
go
purge
some
stuff
out
of
the
cache
and
in
a
non-hierarchical
cache.
You
probably
can't
do
that
in
the
style
of
the
unix
file
system
with
rm-r,
because
you
don't
have
a
hierarchy,
and
so
you'd
have
to
do
something
else,
and
you
know
you
can
approximate
this
in
a
lot
of
ways.
A
A
What
you
have
to
do
is
behave
as
though
the
data
at
or
below
the
re
revalidation
point
doesn't
exist
anymore.
Somebody
asked
for
it.
That
might
be
the
the
point
where
you
lazily,
remove
it
from
cache,
but
either
way
you
can't
use
it
last
slide.
I
promise
so
that
new
referral
is
valid
data.
You
got
it
from
an
authority
and.
G
A
You
were
just
revalidating
and
you're
going
to
repeat
this
either
until
you
reach
a
work
limit,
you
don't
want
to
spin.
You
know:
cpu
loop
flooding
the
network
with
queries,
so
there
always
has
to
be
some
kind
of
loop
detection.
But
you're
going
to
repeat
this
potentially
revalidating
your
way,
all
the
way
up
to
the
root,
because
what
you're
looking
for
is
a
virtual
foundation
which
will
underlie
the
data
you
wish
to
use
and
that's
my
show
I'll,
stop,
sharing
and
turn
it
back
over
to
schumann.
I
A
I
All
right,
yeah
sounds
good
yeah,
so
the
one
confusion
I
had
was
why
the
if,
if
the
simple
algorithm
is
applied
iteratively
to
all
ancestor
delegations,
why
it
doesn't
achieve
approximately
the
same
effect
as
your
complex
algorithm?
But
I
you
know
I'll
wait
until
I
read
your
full
text
to
to
to
try
and
try
and
figure
that
out.
C
D
I
think
warren
is
cute.
Thank
you
so
yeah
a
quick
question
for
paul
vixie
apologies,
but
I
don't
remember
how
much
of
the
original
resin
proof
document
is
not
in
this
document.
I
think
there
were
a
bunch
of
other
useful
things,
and
maybe
once
this
document's
done,
we
can
discuss
actually
doing
the
rest
of
the
resin
proof
dock,
because
I
think
some
really
good
stuff.
A
G
F
Thank
you
yeah.
I
think
we're
all
looking
forward
to
the
new
text
and
I
think
also
we
should
ask
the
the
resolver
implementers
to
look.
Have
a
careful
look
at
the
text.
If
it's
that,
I
think
that's
good
for
for
review.
As
paul
said,
it's
it's
not
it's!
Not
the
sim
well,
as
paul
said
also,
and
it's
good
for
for
have
a
review,
have
a
reference,
implementation,
etc,
etc.
F
C
Worried,
I
guess
I
should
should
also
yeah
yeah,
the
the
we
we
talked
about
some
really
complex
issues
today,
we
you
know
kind
of
dove
into
some
stuff.
That
requires
a
lot
of
careful
thought
and
that's
kind
of
what
why
we
started
doing
the
interims
is
so
that
we
could
focus
on
one
topic
or
two
topics,
for
you
know
a
more
significant
amount
of
time,
but
that's
still,
but
people
still
need
to
go
ahead
and
send
texts
and
review.
C
B
C
F
That
concludes
our
intro
meeting.
Thank
you.
Looking
back
at
our
this
is
a
third
interim
meeting
this
year
and
again
well,
suzanne
already
put
it.
It
was.
I
think
it's
very
useful
that
the
chairs
are
very
happy
happy
with
it.
We
make
good
progress
and
we'll
certainly
plan
more
of
these
interim
meetings.