►
From YouTube: IETF-DNSOP-20210915-0100
Description
DNSOP meeting session at IETF
2021/09/15 0100
https://datatracker.ietf.org/meeting//proceedings/
A
B
Looks
like
it's
the
top
of
the
hour
I'll,
give
people
a
few
minutes,
but
I
think
we're
ready
to
start
and
thanks
all
for
showing
up.
I
know
I
know
this
is
sort
of
a
wacky
time,
but
we
did
it
to
for
the
authors,
mostly
for
the
authors,
for
because
it's
much
more
prevalent
for
their
time
zone.
So
thanks
for
sticking
in
there
folks
dinosaur
interim,
you
know
us,
benno
is
sleeping.
So
let's
not
wake
him
and
paul
did
you
it
looked
like
you
showed
up
paul.
B
B
B
Our
agenda
is
pretty
straightforward
and
we'll
try
to
jump
into
it.
First,
christopher
drawer
son
is
going
to
talk
about
avoid
fragmentation
and
we
really
have
there's
two
questions
that
come
up.
He's
got
a
couple
of
slides,
but
mostly
is
it
a
saint
you
know:
can
we
pick
a
single
value
or
a
range
of
values
and
is
one
preferable
to
the
other
and
is
one
you
know?
B
Where
can
we
go
from
that
and
then
the
second
question
is:
if
it's
a
range
of
values,
what
are
those
appropriate
values,
singular
or
plural
though,
and
then
the
second
one-
and
these
are
both
like
30
minute
slots,
so
we'll
see
how
they
go.
The
glue
is
not
optional.
There's
two
two
sort
of
opening
questions.
B
I
think
the
first
one's
really
been
answered,
what
to
say
about
orphan
glue
and
then
is
sibling
glue,
optional
required
and
schumann
and
dwayne
have
a
couple
of
slides
to
kind
of
kind
of
run
through
that
and
some
good
questions
there.
So
we'll
keep
it
simple
and
straightforward
and
we'll
jump
right
into
that.
I've
just
got
a.
A
B
E
A
A
F
F
Then
I
think
it
is
a
trivial
issue
and
also
will
add
techniques
and
reference
to
the
paper
at
weakness
by
the
fragmentation
text.
Identifying
the
section
next
slide.
Please
and
the
discussion
that
I
do
and
under
discussions
about
id11
both
mentioned
that
he
expected
a
single
value
in
a
pcp
document,
while
victor
is
fine
with
a
set
of
values.
F
F
If
network
efficiency,
both
now
and
in
the
future,
is
to
be
maximized,
maximized
and
adaptively
after
single
failure,
adaptively
after
silent
period,
should
be
done
beginning
beginning
with
a
large
value
and
trying
small
values
or
beginning
with
small
value
and
trying
to
join
large
values
similar
to
architecture,
proximity,
discovery
rx8899
by
nine
to
eight.
In
all
cases,
fragmentation,
either
by
an
endpoint
or
gateway
mass
gateway,
must
be
avoided
in
a
different
future
in
additional
future.
B
Please
your
pleasure
thanks:
can
we
go
back
one
slide,
suzanne
yep
yeah,
the
good
questions?
Okay,
let's
can,
let's
start
off
with
the
first
question,
I
want
to
hear
what
people
think
about
you
know
a
set
of
good
sizes
or
a
single
value.
I
thought
the
table
in
in
this
in
this
deck
was
actually
very
good.
It
was
a
very
good
way
to
sort
of
sort
of
lay
it
all
out
for
folks.
So
I'd
like
to
hear
you
know,
we'd
like
to
hear
some
some
folks
on
that.
G
It
might
be
valuable
to
give
consideration
to
the
the
sizes
in
which
direction
from
the
authority
server
versus
the
resolver
to
the
authority
versus
the
client
to
the
resolver
or
the
resolvers
of
the
client
they
might
be.
Even
if
we
pick
a
single
size,
they
might
be
different
sizes
for
different
reasons.
C
So
this
is
paul
hoffman
if
we
want
a
set
of
sizes
which
it
sounds
like
you
want,
because,
as
you
said,
tim
this
table
is
fairly
good
for
the
different
reasons
and
as
kazunori
said,
you
know
in
the
future,
you
know,
like
you,
don't
even
know
if
you
want
to
start
low
and
count
high
or
count
high
and
go
low
with
different
use
cases.
I
think
we
can
do
that.
I
think
it's
just
then
not
a
bcp,
it's
an
informational
document
with
lots
of
good
information.
C
H
H
G
G
We
don't
want
to
go
too
low
in
what
the
must
not
exceed
is
for
reasons
that
I
think
jeff
houston
has
previously
in
presentations
shown
that
if
you
go
too
low,
there
are
other
bad
things
start
to
happen,
but
you
definitely
do
want
to
make
it
a
bcp
so
that
everyone
realizes
no.
This
is
really
really
important.
G
I'm
I
have
not
yet
written
up
some
example
test
tests
that
I've
done
a
long
time
ago
for
reasons
that
had
to
do
with
not
wanting
to
give
information
to
bad
people.
That
would
allow
them
to
actually
do
bad
things,
but
I
think
it's
probably
overdue
that
actually
write
up
some
examples
of
just
how
bad
it
can
be
informally
and
maybe
shared
amongst,
like
the
orc
or
the
dns
folks.
Okay,
thanks
yeah
anyway,.
I
Yeah
thanks
tim
hi
good
morning
peterco
here
I
on
on
the
on
the
one
versus
was
this
list
of
values.
I
could
live
with
a
single
value
as
a
default
recommendation
to
software
vendors,
but
I
think
operators
need
a
bit
more
leeway
and
be
able
to
apply
certain
considerations,
which
brings
me
to
the
second
issue
of.
I
Does
it
have
to
be
a
single
value
if
it
is
going
to
be
bcp,
I
don't
buy
that
connection.
The
good
practice
is
actually
applying
these
considerations,
so
following
an
advice
that
makes
operators
be
able
to
pick
from
from
a
set
of
values
for
good
reasons,
seems
perfectly
fine
for
bcp
to
me.
Thank
you.
B
H
H
J
We
should
really
be
looking
at
that.
If
we're
not
encrypting
looking
at
moving
servers
to
using
something
like
that,
rather
than
sitting
do
not
fragment
on
udp,
do
not
fragment
on
udp
leads
to
black
holes.
We
do
not
have
control
over
every
router
and
every
link
mtu
in
the
internet.
Why
don't
we
use?
J
J
J
K
J
J
B
B
G
G
Should
it
be
putting
in
the
largest
value
that
it
will
accept
or
what
it's
like
what
is
configured
with
since
it's
answering,
but
it
has
that
value
available
to
to
put
in
so
that
clients
can
learn
rather
than
just
putting
in
some
canned
value.
Like
some
implementations
do
so
that's
a
that's
a
separate
question.
Maybe
it
doesn't
need
to
be
answered
now,
but
it's
a
thought.
I
think
something
to
think
about.
That's
my
that's.
My
two
cents.
C
C
E
I
I
have,
I
have
a
thought
here
that
might
help
us
a
little
bit.
I
like
I
like
what
paul
was
saying,
but
also
it
occurs
to
me
that
we
might
be
looking
at
this
slightly
backwards,
in
the
sense
that
the
bcp
that
we
are
quite
firmly
recommending
is
don't
just
blindly
pick
a
number,
and
the
rest
of
the
document
goes
very
clearly
to
defending
the
proposition
that
good
practice
consists
of
examining
the
discussion
in
the
document
examining
what
your
particular
use
cases
and
your
particular
concerns
are
and
framing
it.
E
B
And
and
the
draft
does
sort
of
spell
out,
operators
or
authoritative,
servers,
resolvers
and
then
clients
such
as
stub
resolvers,
but
maybe
it's
not
it.
They
need
to
be
broken
out
a
little
bit.
It
made
a
little
bit
more
obvious
and
that's
something
I
could
we
can
chat
with
the
authors
about,
but
it's
yes,
I
think
there
is
some
discussion
about
the
various.
If
you're
this
person,
you
should
look
at
it
this
way.
If
you're
that
person,
you
should
look
at
it
that
way.
B
So,
okay,
we're
going
to
try
to
summarize
this
and
take
it
to
the
mailing
list,
but
and
we'll
probably
it
we'll
go
for
a
vote
on
this
and
see
see
where
things
go
and,
and
hopefully
we'll
come
up
with
a
with
it.
We'll
come
up
with
a
good
ques,
we'll
come
up
with
questions
that
we
could
get
answered
one
way
or
the
other
and
can
move
this
forward,
because
we
do
think
this
is
really
good
stuff.
E
E
B
E
E
L
E
E
L
L
L
You
might
also
consider
that
more
of
an
optimization
than
rather
robustness
requirement.
The
reasons
for
should
is
that
technically
sibling
glue
is
not
really
required
for
resolution,
except
for
the
the
loop
case.
As
mentioned
above
you
know,
a
name
server
can
query,
can
issue
a
second
query
for
sibling
glue
if
it's
needed-
and
you
know.
K
L
So
we
want
to,
you,
know,
have
further
discussion
on
that
and
maybe
try
to
reach
a
decision
on
that.
Hopefully,
okay,
so
let's
go
to
the
next
slide,
which
will
be
related
to
the
to
the
first
issue.
Three,
something
that
we've
talked
about.
As
the
authors
is
should
should
the
draft
you
know
mention
or
accommodate
the
idea
of
sibling
glue
loops.
L
Should
there
be
an
example
showing
what
such
a
loop
looks
like
and
does
the
does?
The
working
group
feel
that
you
know
a
a
configuration.
A
real
world
configuration
with
sibling
gloops
is
something
that
should
be
supported
and
reasonably
expect
it
to
work
or
is
it
you
know
broken
and
anomalous
and
not
something
that
we
should
enable.
L
E
G
That's
the
only
way
to
resolve
sibling
glue
loops,
but
I
think
that
that
would
be
a
reasonable
approach,
allowing
the
cases
where
it's
not
necessary.
The
simply
glue
is
not
necessary
to
resolve,
but
if
there's
a
resolution
of
failure
that
there's
a
a
way
around
the
problem
that
is
encoded
in
this
document,
that's
basically
it.
D
D
I
would,
I
would
prefer
language,
maybe
here
that
makes
explicit
that
name
server
site,
that
zone
operators
must
not
construct
cyclic
name
server
relationships
like
sibling,
glue
loops
and
that,
basically,
you
know
that
it
if
they
do
that
the
authoritative
server
is,
is
free
to
reject
this
in
some
fashion.
You
know
treat
this
as
as
an
invalid
configuration
on
the
topic
of
setting
tc
equal
to
1
issue,
2.
D
I'd
like
a
little
more
clarification
on
whether
whether
this
is
intended
to
be
a
performance
optimization
because
it
seems
like
it's
not
an
effective
performance,
optimization
you'd,
your
b.
If
any
of
this
glue
is
not
actually
required,
you
are
better
off
getting
you
know,
essentially
just
making
the
follow-up
query
and
getting
the
additional
records
you
need,
rather
than
repeating
the
query
over
tcp.
J
D
J
D
D
C
K
I
think
you
mean
that
that
that
it
has
to
that
that
that,
if,
if
there
are
nrrs-
and
you
can
only-
and
you
can
only
fit
n
minus
one
truncated
but
but
a
reasonable
english
reading
would
be
that,
if
that
it's
okay
to
include
at
least
one.
So
I
hope
this
means
that
you
need
to
include
all
of
them
and
I
think
you
should
fix
them
ready
to
make
that
clearer
and
as
far
as
as
as
with
respect
to
sibling,
clue
ben
said
what
I
was
going
to
say.
I
don't.
K
J
A
L
L
K
K
H
Thank
you
hopefully
mine's
nice
and
easy.
Your
very
last
slide
has
a
question
on.
Should
there
be
an
example-
and
I
think,
regardless
of
whether
or
not
you
know,
we
say
that
sibling
blue
is
reasonable
or
not.
I
think
it
would
be
useful
to
have
an
example
just
to
explain
what
it
is.
You
know
it's
like
here's
an
example.
Don't
do
this.
N
E
G
Brian
sympathetic
to
the
concept
of
getting
rid
of
sibling,
blue
loops,
notwithstanding
code
bases
and
zones,
there
is
a
heck
of
a
lot
of
deployed
stuff
out
there
that
may
never
get
updated
or
may
get
updated
slowly,
and
that
includes
both
the
software
for
supporting
authority
servers,
as
well
as
the
zone
configurations
themselves
and
we're
talking
about
potentially
arbitrarily
deep
in
the
dns
tree.
So
the
stuff
that
we're
I
think
ben
may
have
been
thinking
about
is
mostly
at
the
tlb
to
second
level.
G
That's
probably
fine
to
really
point
people
to
say
you
shouldn't
be
doing
this,
but
I
don't
think
it's
feasible
to
just
say:
okay,
if
you
don't
have
things
done
right,
your
stuff's
gonna
break.
I
I
don't
think
that's.
I
don't
think
that's
an
appropriate
direction
for
the
working
group
to
take,
but
I
think
it's
fine
to
say:
let's
allow
removal
of
sibling
glue
with
the
tc
equals
one
done,
even
if
you
know,
even
if
both
the
sibling
glue
and
the
regular
glue
would
fit.
D
Responding
to
brian
so
that
to
to
add
some
nuance,
what
I
I
think,
ideally
we
would
see,
is
a
must-not
instruction
that
says:
don't
create
a
loop
and
a
may
instruction
that
says
you.
You
may
configure
yourself
in
a
way
that
that
makes
these
loops
unresolvable
on
the
authoritative
side
and
so
as
an
authoritative
server.
Implementer,
that's
up
to
you
whether
you
want
to
go.
You
know,
go
break
those
configurations.
If
that
simplifies
things
for
you
in
some
other
way
or
or
whether
you
want
to
continue
supporting
those
out-of-spec
configurations.
G
C
It
is
fairly
clear
because
it
just
talks
about
glue
and
we
have
lumped,
or
the
draft
currently
lumps
sibling
group
glue
with
traditional
glue.
If
it's,
if
it's
important
enough
to
to
separate
those
out,
then
we're
going
to
have
to
make
this
longer.
I
still
think
it'll
be
understandable,
but
just
be
aware
that
we're
not,
then
simply
making
a
one
sentence.
D
What's
the
benchwards
just
a
quick
follow-up
to
brian
dixon's
comment,
it
sounds
like
you're
you're
talking
about
the
the
portability
between
implementations
of
zones
that
that
rely
on
a
sibling
glue
loop
and
I
so
I
guess
my
view
is
that
I'm
not.
I
don't
think
that
that
portability
is
is
a
very
high
priority.
G
I
was
saying
this
interoperability,
not
portability,
so
I
don't
want
this
to
cause
the
behavior
of
resolvers
and
authority
servers
to
result
in
breakage
in
the
case
of
somebody
updating
their
software,
but
not
updating
their
results,
and
there
could
be
the
case
depending
on
where
the
sibling
glue
actually
lives.
It
could
be
further
down
the
tree
than
is
necessarily
visible
to
the
single
authority.
Server
that
updates
its
software.
G
E
Okay,
I
do
have
two
two
things.
First,
there's
a
I.
I
have
seen
about
half
of
a
discussion
in
the
in
the
chat
that
and
I'm
going
to
encourage
the
folks
talking
there
if
you
want,
if
any
of
what
you're
saying
or
hearing
should
be
added
to
the
draft,
please
send
text
also
dwayne.
What
are
you?
Are
you
getting?
What
you
need
from
from
this?
Do
you
see
a
way
forward
out
of
this
discussion.
L
L
L
L
E
G
Some
of
the
sibling
glue
fits,
but
not
all
of
it,
and
I
think
my
concern
is:
it
should
be
permissible
to
implement
a
narrow
glue
policy
that
requires
that
non-sibling,
glue,
fit
or
be
truncated
for
sure
has
to
be
served
and
if
there
exists
sibling
glue
that
is
omitted
because
of
the
narrow
glue
policy
that
tc
equals.
One
should
be
also
the
case
if
it
exists
and
that's
so
that
a
follow-up
over
tcp
will
permit
resolution
of
anything
that
involves
the
requirement
of
simply
glued
it
actually
resolved
by
the
loops.
G
L
E
D
G
E
Well,
we
will
try
to.
We
will
make
sense
of
what
we've
heard,
reminding
people
that
there
will
be
a
recording
which
I'm
sure
tim
and
I
will
be
listening
to
to
make
sure.
We've
we've
heard
and
considered
everybody's
comments
and
I
think
it'll
be
you
know,
it'll
be
publicly
available
for
anybody
that
wants
to
go
over
it
and
think
further
about
this
tim.
Do
you
have
anything
to
add
before
we
wrap.