►
From YouTube: IETF108-DNSOP-20200729-1100
Description
DNSOP meeting session at IETF108
2020/07/29 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
E
C
I
thought
I
already
pushed
all
the
buttons
that
that's
where
in
my
screen.
Sorry
sorry
welcome.
This
is
the
dinosaur
working
group
meeting.
We
have
two
sessions
this
afternoon
for
me
afternoon
for
you
early
morning
or
later
in
the
morning.
This
session
is
one
hour
and
forty
minutes.
We
have
a
packed
agenda.
C
My
name
is
ben
o'friender.
My
co-chairs
are
suzanne
wolff
and
tim
bisinski.
C
C
C
B
Yup,
let's,
let's
jump
through
them
that
skip
that
one!
We
went
through
that
one!
That's
the
note!
Well,
I
think
we've
all
sort
of
seen
the
note.
Well,
please
be
respectful
all
that
good
stuff,
and
so
the
next
slide.
B
Okay,
yep
the
agenda.
You
know
it's
just
some
updates
on
the
old
work
and
some
current
working
group
business
and
a
little
bit
of
new
working
group
business,
and
so,
if
anybody
has
any
suggestions
about
that,
just
please
speak
up.
So
let's
go
to
the
next
slide.
B
So
here's
some
document
updates
that
we
have.
If
we
go
to
the
next
slide,
we
have
four
documents
in
the
rfc
editor
queue
there.
We
go
and
they've
been
sitting
there
for
a
while.
So
that's
fairly
good
and
we
finally
got
2845
biz
in
the
same
state.
So
I
think
I'm
pretty
happy
with
that.
The
next
slide
we've
got
a
few
sort
of
updates
on
server
cookies.
B
There
is
there's
some
as
you
can
see.
They've
got
some
proof
of
concept
implementations
and
they
feel
they're
ready
for
working
group
last
call
so
we'll
probably
see
that
in
the
next
month
or
two
and
the
catalog
zones
draft
is
they're
working
on
some
interoperability
testing.
B
As
you
can
see,
and
I
think
they've
made
some
good
progress
and
they
want
to
they
before
what
the
next
iatf
meeting
they'd
like
to
get
some
some
good
testing
going
on,
and
we
we
always
love
implementation.
So
we
totally
agree
with
them
on
that.
B
So
if
we
go
to
the
next
slide-
and
we
recently
adopted
a
bunch
of
this
work
and
so
which
was
surprising
even
to
myself,
some
of
this,
I
think,
there's
a
couple
of
very
short,
straightforward
ones,
especially
mark's
glue,
is
not
optional,
that
I
feel
the
working
group
can
work
through
rather
efficiently
and
so
that's
kind
of
good
and
I'm
glad
to
see
some
of
that,
and
so
people
seem
interested
and
then
the
first
two
are
actually
going
to
be
discussed
this
this
morning,
they're
in
the
first
sort
of
discussions,
so
good
for
that.
B
So
on
the
next
slide,
there's
one
that
we
updated.
We
did
adopt
the
5933
biz
that
equally,
everybody
equally
was
unhappy
about
adopting
this
and
we
adopted
it.
As
you
know,
as
well
and
including
the
chairs,
it
was
a
bitter
pill
for
everybody,
but
they
have
a
quest
for
a
code
point
and
that's
part
of
the
whole
process.
B
So
part
of
this
discussion
came
about
also
adopted.
They.
There
was
a
whole
sort
of
threat
about,
oh,
let's
sort
of
relax
the
registry,
but
I
personally
feel
that
fails
to
actually
take
operational
considerations
into
account
to
just
sort
of
add
more
dena
sec
algorithms,
without
sort
of
addressing
any
sort
of
operational
issues,
and
we
are
an
operations
group
and
we
need
to
sort
of
address
those
type
of
issues
and
failing
to
do
so,
I
feel
is
we're
just
laying
down
on
the
job.
B
One
thing
that-
and
I
sort
of
brought
up
a
few
times-
was
the
great
table.
That's
in
86
24
that
paul
and
andre
put
together
about
you
know,
recommendations
using
the
2119
language.
The
problem
is
diana
and
the
ion
registries
don't
really
seem
to
allow
that
sort
of
flexibility,
but
I
feel
that
maybe
the
iana
retrieves
we
have
right
now
need
better
guidance
from
implementers.
B
There's
some
there's
some
ref.
You
know
there's
some
relevant
stuff
in
what
tls
folks
did
in
terms
of
recommending
implementation
versus
not,
and
so
I
that
may
need
a
deeper
dive.
I
I'd
love
to
see
some
folks
sort
of
think
about
that
and
see
how
we
can
do
it
sort
of
go
about
that,
but
to
just
sort
of
you
know,
make
it
easier
to
add
more
algorithms
without
really
sort
of
thinking
of
the
long-term
consequences.
Just
seems
like
that.
B
You
know
like
just
bad
bad
math,
all
the
way
around,
so
just
my
personal
opinion.
So
next
slide
there's!
Oh
yes,
this
one
we've
been
talking
with
with
we
went
through
the
chairs,
went
through
all
the
sort
of
current
drafts
back
in
april
and
and
was
looking
for
sort
of.
We
were
sort
of
thinking
about
this
language
thing
figuring.
This
was
going
to
come
up
and
I
guess
we
were
just
sort
of
lucky.
B
We
were
ahead
of
the
curve
a
little
bit
and
there
are
some
updates
in
84.99
that
we
could
do
to
sort
of
make
that
better.
One
idea
was
to
just
publish
an
update
document
kind
of
like
that
terminology:
tour
thing
that
that
made
those
updates,
but
that
just
seems
like
it's
to
me
that
doesn't
seem
like
it
just
seems
like
it's
it.
B
It
just
seems
weak,
I'm
not
sure
how
how
else
to
say
it,
and
I
would
prefer
we
just
republish
84.99,
with
all
the
changes
we
want
to
make
and
sort
of
clean
that
up,
rather
than
having
people
chase
through
documents
to
find
those
sort
of
to
sort
of
those
updates.
But
I'm
you
know
we're
going
to
throw
that
out
and
let
the
and
see
what
the
working
group
feels
about
some
of
that.
What's
the
right
way
to
go
with
that,
so
we'll
you
know
we'll
take
you
guys
anyway.
Next
slide.
B
I
think
that's
the
bulk
of
it.
There's
our
data
tracker
and
stuff
in
our
github.
What
else
we're
working
on
we?
Actually,
since
we
adopted
a
bunch
of
things,
we're
going
to
be
busy
for
a
little
while,
so
I
guess
that's
good,
I
guess
that's
good
also
next
slide
so
for
agenda
in
the
underworld.
Current
group,
mr
ridgewater
science,
going
to
talk
about
the
fragmentation
avoidance,
which
we
hope
we
get
more
people
reading,
because
we
think
it's
getting
pretty
getting
much.
B
You
know
pretty
cleaned
up
and
we
like
to
see
it
move
along
as
well.
The
service
binding
parameter
specification.
That's
the
service
b
draft,
as
you
all
know,
and
they've
been
making
a
lot
of
progress
and
and
and
that's
been
really
great.
What
they're
doing
and,
of
course,
dna
delegation
only
dns
key
flag
and
there's
some
new
working
group
business
on
the
next
slide.
B
These
are
for
the
next
pretty
much
the
end
of
this
session
and
the
second
session,
the
ns2
and
s2t
draft.
I
think
tim's
actually
presented
that
before,
but
we're
coming
back
around
request
to
actually
update
the
resolver
primary
query:
8109
draft
paul's
draft
about
ionic
considerations,
which
I've
sort
of
already
vented
on
a
little
bit.
B
Dns
access,
denied
error
page
and
that
last
one
probably
a
time
permitting
is
on
this
nat
64,
optimization
stuff
you'll
want
to
look
at
the
slides,
it's
it's!
It's
yeah
you'll
want
to
look
at
the
slides.
That's
all
I
can
say
it's.
It's
definitely
people
doing
guinness
and
ways
that
we've
never
actually
thought
about
doing
dns
for
better
or
for
worse.
So
that's
what
we've
got
on
the
agenda
for
today.
F
F
C
Thank
you.
Oh
my.
C
G
C
Excuses.
Thank
you
I
like
to
remind
everyone.
The
session
is
recorded
and
also
the
blue
sheets
are
automatically
generated
from
the
participant
list
in
the
media,
echo.
Okay,
then
I
want
to
go
to
fujiwara
sun
one
moment
I
will
stop
sharing
my
screen
and
open
another
one.
Okay,.
C
F
C
C
C
C
A
H
These
are
differences
between
dracula,
georgians,
of
avoiding
fragmentation,
zero,
three
and
drastic
dns
of
avoid
fragmentation;
zero
one,
please,
please
click
this
link
to
show
differences,
main
differences,
changed
was
working
draft
and
added
density.
With
the
countermeasure
in
introduction
and
removed,
section
7.2
dns
packet
size
moved
details
of
minimum
responses
to
appendix
a
and
added
reference
to
directly
hcpwd
datagram.
C
H
C
H
F
F
F
C
C
Okay,
can
I
invite
ben.
E
E
E
If
you
tried
to
separate
all
these
pieces
of
information
out
into
separate
rr
types
and
make
separate
queries
for
them
from
the
client.
Apart
from
requiring
a
lot
of
queries,
there
would
be
no
guarantee
that
you
get
coherent
answers
back,
so
this
ensures
that
you
can
get
a
coherent
bound
set
of
information
out
of
the
dns
to
help
you
connect
to
some
endpoint
next
slide.
C
E
C
E
So
this
is
just
a
one
of
the
motivating
examples
for
this.
There
are
a
lot
of
different
use
cases,
but
one
of
the
key
motivating
examples
is
to
be
able
to
take
a
domain
point
it
at
two
different
cdns
and
have
each
cdn
have
a
bound
set
of
connection
hints
or
metadata
that
are
associated
with
that
specific
cdn.
E
One
of
the
key
reasons
for
this
is
that
that
is
that
this
record
is
the
designated
type
to
deliver
encrypted
client,
hello,
public
keys
for
tls
connections,
and
those
keys
are
only
going
to
work
if
you,
if
they're
bound
to
a
correct
server
pool
if
you
try
to
use
them
with
the
wrong
server
pool
you'll
get
a
fatal
connection.
Error
next
slide.
I
C
E
Is
the
this
was
previous
called
previously
called,
alias
form?
We've
changed
that
name
to
alias
mode,
to
reflect
the
fact
that
there's
only
one
wire
format
for
this
record
type,
but
there
are
two
different
modes
depending
on
the
indicated
priority,
and
in
this
mode
the
record
acts
a
lot
like
some
variation
on
a
name
or
alias.
It
also
acts
quite
a
bit
like
srv,
it's
essentially
a
simple
indirection.
E
E
So
that
was
all
background
which
I
wanted
to
get
through
as
fast
as
I
could.
These
are
the
really
the
relevant
slides
for
the
meeting,
so
there
have
been
quite
a
few
changes
since
our
last
meeting
we've
gone
through
several
intermediate
drafts,
including
a
name
change
which
caused
the
draft
version
numbers
to
reset.
E
So
let
me
just
talk
down
this
list
briefly,
so
some
iana
updates.
We
now
have
assigned
type
numbers
through
the
early
allocation
process.
That's
very
exciting!
E
We
have
changed
the
ayana
instructions
to
reserve.
The
most
important
change
is
that
half
of
the
key
range
is
now
first
come
first
served.
This
was
requested
by
some
implementers
who
wanted
a
an
easier,
lower
friction
way
to
experiment.
So
the
hope
is
that
this
will
allow
dynamic
experimental
uses
while
ensuring
that
they
can't
exhaust
the
code.
Point
range
since
the
other
half
is
expert
review.
E
The
this
is,
we
argue
that
this
is
safe,
because
clients
normally
ignore
unrecognized
keys.
So
if
somebody
puts
something
strange
in
one
of
these
keys
that
was
allocated
on
a
first
come
first
serve
basis,
most
clients
will
just
ignore
it
unless
they've
specifically
been
configured
to
have
awareness
of
that
key
chain.
Length
limit
is
something
that
we
discussed
in
the
working
group
at
length.
A
previous
draft
said
something
like
eight
question
mark,
which
generated
a
great
deal
of
controversy.
E
Otherwise
there
could
be
loops
or
other
abuses,
but
your
limit
must
not
be
zero,
so
you
must
follow
at
least
one
one
step
of
chain
and
beyond
that,
the
draft
does
not
attempt
to
specify
which,
as
far
as
I
can
tell
puts
it
in
the
same
puts
it
in
the
same
category
as
cname,
which
similarly
doesn't
seem
to
have
a
mandated
particular
chain
like
limit,
so
hopefully
that
hopefully,
that
captures
the
intent
of
the
working
group
there's
a
new
key
called
mandatory.
I
E
Are
necessary
in
order
to
use
this
rr?
So
if
you
look
in
the
list
of
mandatory
keys-
and
you
see
a
key
number
so
that
those
are
all
16-bit
type
codes,
if
you
see
a
type
code
that
you
don't
recognize,
then
you
should
just
discard
that
record,
because
you
don't
have
the
information
required
to
use
it.
E
E
E
Yeah,
oh
good,
the
there
have
also
been
a
bunch
of
less
substantive
changes.
We've
renamed
a
bunch
of
terminology
here,
most
importantly,
the
record
name
itself
has
now
been
changed
to
https.
E
That
was
the
result
of
a
a
poll
taken
in
january
in
the
working
group,
and
that
is
now
confirmed
in
the
early
code
point
allocation
and
there
are
a
bunch
of
of
small
clarifications
and
improvements
in
on
all
different
kinds
of
topics.
We
can
talk
about
more
if
you
want
next.
E
Slide
so
the
the
text
still
has
several
to
do's,
which
I
think
we
can
actually
just
remove
at
this
point.
Apart
from
that,
it's
time
for
working
group
last
call
and
interop
testing.
We
actually
have
a
document
now
that
you
may
have
seen
on
the
mailing
list
where
people
have
been
putting
in
notices
of
work
on
implementation
and
I'm
very
happy
to
see
a
number
of
different
major
implementations
coming
online.
There
that's
very
exciting,
so
hopefully
we
can.
We
can
start
to
do
some,
some
more
interrupt
testing.
C
No
questions,
thank
you
ben,
so
so
the
dinosaur
chairs
are
also
thinking.
We're
close
to
working
group
last
call
for
interrupt
testing.
We,
I
think
it's
good
to
have
some
coordination.
Are
you
coordinating
that
or
do
you
want
to
delegate
it
to
the
to
the
chairs?
You
are
in
contact
with
open
source
developers
and
other
developers.
E
C
E
E
I
think
we've
we've
just
sort
of
been
expecting
that,
because
the
implementers
consist
of
a
range
we
now
have
people
who've
committed
to
or
or
publicly
indicated
that
they
intend
to
implement
for
stub,
resolvers,
recursive,
resolvers
and
authoritative
servers
that
hopefully
those
people
will
naturally
be
testing
against
each
other
excellent
good.
C
You
yeah,
I
know
tim
or
I
or
suzanne,
will
also
contact
you
to
to
see
how
that
goes
or
if
we
can.
C
The
the
developers
to
do
the
inter
interrupt
testing,
and
so
we
can
go
for
a
working
group
law
school.
Sorry,
suzanne.
J
Just
that
interop
testing
seems
particularly
important
for
those.
I
think
I
think
it's
it's
an
important
part
of
what
the
working
group
will
be
interested
in
and
not
just
not,
and
quite
possibly,
not
only
danatop.
So
this
does
seem
like
something
where
we
need
to
make
sure.
We've
got
an
adequate
cross
area
review.
I
E
So
we
should
make
sure
that
that's
covered
in
some
of
this
interop
testing
and
yeah.
It
would
be
nice
to
have
one
of
those
one
of
those
little
compatibility.
C
E
C
Okay,
tommy:
please
go
ahead.
K
J
K
Great
yeah,
so
just
on
the
topic
of
testing,
so
we
at
apple
have
built
an
implementation
of
this
in
the
next
beta
seed
that
we'll
have
of
ios
and
mac
os.
That
will
be
using
the
official
code
points
so
first,
if
anyone
wants
to
test
out
what
happens
when
clients
are
requesting,
it
should
be
as
simple
as
just
installing
those
on
a
device,
and
so
you
know
please
try
that
out
and
let
us
know
if
you
see
issues
there,
that
particular
version
does
not
the
the
particular
version.
A
Yes,
sorry
so
I
was
just.
K
Going
to
say
also
in
one
of
the
upcoming
betas,
we'll
have
everything
to
do
following
aliases,
one
deep
doing
the
aopn
inference
and
doing
any
alternative
ports,
so
people
can
kind
of
test
out
that
behavior
and
make
sure
that's
working
for
their
deployments.
K
K
Not
play
well
with
new
r
types,
particularly
we've
seen
reports
from
vodafone
italia
that
their
networks
are
seeing
some
level
of
issue
when
they're
receiving
our
types
that
they
don't
recognize
and
it
seems
to
be
affecting
other
dns
queries.
There's
seems
to
be
some
bug
in
their
dns
infrastructure.
So
that's
something
that
people
should
be
aware
of
as
they're
testing,
and
if
anyone
has
contacts
there,
we
should
let
them
know
that
we
should
make
it
safe
for
these
new
r
types.
C
L
Oh
yeah,
can
you
hear
me
yes.
L
Hi,
I'm
alison
mankin,
very
nice,
clear,
talk,
ben
and
I'm
I'm
very
impressed
with
the
progress.
I
was
hoping
that
we
could
focus
when
we
get
to
interrupting
on
operators
and
that's
large
dns
operators,
because
it'll
be
really
important
to
see
if
they
to
get
them
used
to
this
very
new
type
of
record,
and
I
I
think
it'll
be
really
valuable
for
adoption
if
it
is
available
from
those
providers.
So
we
deal
with
a
lot
of
vendors
and
we'll
try
at
salesforce
we'll
try
to
encourage
them.
L
F
C
Any
other
questions,
no
okay,
thank
you
so
summarizing
some
interrupt
testing,
also
well
as
tommy
also
mentioned
apple,
is
also
testing.
This,
with
a
new
code
point
interrupt
testing,
including
application
level
and
then
proceed
with
the
process
and
working
group
last
call
is
that
correct.
Did
I
miss
something?
Okay,
please
working
group
have
do
review
the
documents
and
send
feedback
to
the
authors
and
we'll
continue
thanks.
C
J
Yeah,
we
definitely
want
to
make
sure
that
there's
been
adequate
review
on
this,
as
we
said
so,
if
you've
been
waiting
until
it
seemed
to
be
mostly
cooked,
please
review
and
if
you
have
an
interest
in
testing,
please
do
consider
that
thanks.
C
Thank
you.
The
next
presenter
is
paul
wowters
with
his
draft
delegation
only.
C
C
F
C
A
moment
I
will
rescale
it
again,
sorry
that
that
works
consistently.
Oh
next
slide.
D
And
so
just
a
small
reminder:
the
delegation
only
flag
is
a
dns
key
flag
that
you
can
set.
That
basically
indicates
that
you're
only
delegating
in
your
zone,
you
don't
sign
anything
within
your
zone,
and
so
the
idea
is
that
you're
sort
of
yielding
power
that
that
you
have
over
over
your
children,
and
you
commit
this
publicly
in
your
dns
key
flag,
which
means
it's
encoded
in
your
ds
record.
So
so
people
can
can
track
and
monitor
this,
and
this
does.
D
D
So
the
biggest
change-
and
I
indicated
here
by
by
just
showing
the
bit
of
the
abstract.
D
So
the
the
main
change
other
than
some
spelling
errors
is
the
the
change
that
talks
about
what
data
is
or
isn't
allowed.
So
we
had
some
confluted
language
saying
if
you're
crossing
a
dot
or
if
you're,
having
a
a
zone
cut,
then
then
those
records
should
only
be
delegation,
records
and
glue
and
should
not
be
signed
and
paul
vixie
contacted
me.
Is
that,
like
you,
you
should
just
talk
about
answers,
because
that's
really
what
you're
talking
about
you
don't
really
care
if
you're
crossing
an
empty
non-terminal,
you
only
care
about
that.
D
Whatever
they're
sending
is
not
an
answer,
but
is
blue
records
and
authority
sector,
so
that
is
really
the
biggest
change,
which
means
that
empty
non-terminals
are
no
longer
an
issue
and
I
think
it
clarifies
the
text.
I
did
add
some
language
into
the
security
considerations,
just
in
case
like
like
sneaky
answer,
section
material
would
end
up
in
the
authority
section
or
the
additional
section,
so
that
should
be
ignored
there.
D
So
that
was
the
main
change
and
I
think
where
the
document
is
good
to
go
or
like
good
for
for
more
reviews
and
more
feedback.
D
Some
people
that
do
like
the
the
idea
of
like
making
dns
sec
a
little
bit
more
repeatable
to
the
larger
audience
that
say
like.
Oh,
my
god,
there's
one
boot
key
that
can
it
can
control
everything.
D
So
so
there's
definitely
interest,
but
maybe
because
the
target
audience
is
also
outside
of
really
ietf
working
group
participants.
The
the
interest
within.
F
C
Yes,
sorry
yeah!
Please,
please
review
the
documents,
send
comments
to
the
to
the
mailing
list,
so
we
adopted
this
document
as
a
working
group
document,
so
the
working
group
should
also
be
actively
involved
in
this
document
and
send
feedback
suzanne
tim
any
other
things
we
should
mention
here.
J
L
J
I
C
Okay,
excuse
me.
C
So
tim,
if
can
you
put
up
the
presentation?
Maybe
I
can
give
you
access
to
the
to
screen
sharing.
C
M
I
F
F
C
There
we
are
sorry,
thank
you
alex
for
the
suggestion
tim.
Do
you
see
the
screen
yep.
F
I
do
yeah,
okay,
so
well
good.
M
So
this
is,
I
brought
this
up
at
the
last
meeting.
There's
been
a
few
changes
since
then
taking
some
feedback
from
the
slide
from
the
list
next
slide.
Please.
M
A
quick
overview
this
this
was
all
presented
last
time.
There's
this
is
a
new
r
are
two
new
rr
types
that
allow
for
delegation
from
a
parent
to
a
child
with
additional
parameters
about
the
delegation.
So
it's
basically
enabling
alternate
transport
for
dns
protocols.
M
M
M
The
record
can
exist
in
both
places.
It
ideally
would
exist
in
both
places,
but
to
aid
in
rollouts.
It
can
exist
in
the
child,
but
not
the
parent.
It
would
be
signed
in
the
child
zone,
not
in
the
parent
very
similar
to
how
ns
is
done
now
and
it's.
It
has
extra
parameters
which,
if
you
want
more
details
about
exactly
what's
in
it,
there's
a
slide
and
a
couple
more
that
will
show
the
different
values
that
are
currently
allowed.
M
I
hadn't
noticed
until
ben
was
talking
that
the
name
of
the
record,
the
name
of
the
types
of
records,
have
changed.
So
it's
I'm
gonna
have
to
go
back
through
and
change
it
from
alias
form
to
alias
mode
and
same
thing
with
service
and
then
next
slide.
M
The
other
record
type
is
the
ns2t,
which
is
basically
expands
to
the
name
server
to
target
record
type
where
this
would
exist,
where
there's
not
a
zone
cut,
so
you
may
use
the
alias
form
from
one
zone
to
another
and
then
that
zone,
since
it's
not
a
zone
cut.
At
that
point,
you
would
use
the
ns2t
record
and
it's
basically
similar
to
a
c
name
for
a.
M
Very
similarly
to
the
svcp
draft
there
is,
there
can
be
a
chain
of
these.
I
haven't
added
the
language
to
the
draft
yet,
but
the
I
was
going
to
pretty
much
copy
the
the
hop
count,
suggestions
from
the
svcb
draft,
so
that
it's
up
to
the
implementers
of
how
many
hops
to
actually
fall
to
how
many
to
chase
when
resolving
and
then
next
slide
so
going
over.
Some
of
the
changes
between
the
zero
zero
and
the
zero
one,
the
main
ones
where
the
ds
information
has
been
removed
from
the
record.
M
So
that
can
be
signed.
And
then
the
ipv
four
and
six
hints
has
been
removed
from
the
allowed
parameter
keys,
because
that's
basically
just
the
glue.
That
would
also
exist
in
the
parent.
At
the
same
time,
which
leaves
the
next
slide
as
the
service
parameter
keys
that
are
defined
for
these
record
types.
M
And
the
other
changes
are
mostly
from
the
feedback
on
the
mailing
list
of
the
ns2t
record
is
no
longer
it's
not
very
clear
that
it
should
not
be
signed
in
the
parent
and
then
tried
to
just
basic
housekeeping
of
cleaning
up
things,
adding
a
privacy
consideration
section,
adding
more
clarity
about
when
to
expect
these
records,
and
then
there
was.
M
I
don't
remember
if
it
was
on
the
list
or
in
private
conversations,
but
there
was
some
talk
about
something
similar
to
the
cdns
key
record
type,
but
that
currently
putting
that
out
of
scope
for
this
draft
and
then
a
clarity,
piece
of
ns2
and
ns2t
should
not
exist
for
the
same
name
in
the
same
zone
and
the
final
slide
are
there's
a
few
open
questions.
Thanks
to
ben
schwartz,
I
thought
I
had
replied
your
email.
I
guess
I
haven't.
I
will
do
that
later
today.
M
M
Oh,
there
is
one
more
slide
of
just
if
any
questions,
comments
or
reviews
are
welcome
and
then
there's
the
open
question
I've
had.
I
don't
know
if
there's
been
any
progress
from.
M
I
was
talking
to
tim
about
this,
maybe
last
week
of
whether
or
not
it
has
been
decided
where
this
should
live,
not
entirely
sure
if
dns
offers
the
right
place
for
this
to
continue
working.
G
Please
go
ahead.
You
have
the
microphone.
This
is
paul
hoffman.
The
question
I
had
was
exactly
what
you
brought
up
at
the
end,
which
is
where
should
this
be
done,
deprive
which
is
meeting
later
in
the
week,
has
a
very
different
draft,
with
a
very
different
set
of
parameters,
a
very
different
use
case,
which
is
narrower
and
such
it's
not
been
adopted
by
deprived,
but
I
I
actually
prefer
this.
G
You
know
the
use
cases
for
this
draft
much
more
than
the
ones
that
are
in
being
discussed
in
deprive,
but
the
chairs
need
underscore
need
to
figure
this
out,
because
if
we
have
these
two
going
forwards
at
the
same
time
and
they
have
different
use
cases,
that's
going
to
mess
everyone
up.
Thank
you.
I
J
C
Yes,
okay,
okay,
yeah,
okay
yeah!
I
did
see
paul
showing
up
again,
but
apparently
he
didn't
get
the
the
bike.
So
next
in
cue,
is
benjamin
ben
sorry
ben!
Please
go
ahead.
Hi.
E
Yeah
I,
in
addition
to
the
to
the
deprived
question,
I
also
just
want
to
highlight
that
there
is,
in
my
view,
as
I
mentioned
several
times,
considerable
overlap
here
with
the
with
the
adaptive
dns
proposal.
That
is,
that
has
been
in
add.
E
And
you
know
in
in
terms
of
the
so
there
are
these
three
drafts:
there's
the
dot
signal
and
pin
and
deprived
there's
ns2
here
and
there's
that
one
in
add.
I
actually
like
them
all
and
I'd
like
to
see
if
we
can
unify
them
all
into
at
least
a
coherent
set
of
proposals.
C
Yeah.
Okay,
thank
you!
Thank
you
ben.
So
it's
also
an
action
point
for
the
well.
I
I
won't
count
them,
but
six,
seven
working
group
chairs
of
add
deep,
private
and
dinosaur
to
coordinate
the
this
and
to
make
yeah
yeah
consistent
document
either
merged,
or
at
least
consistent
at
one
place.
I
N
Sorry
about
that,
I
I
see
that
you're
allowing
these
records
only
at
the
parent.
You
say
it's
preferred
to
be
in
both
and
have
you
thought
about
the
processing
rules
when
a
record
is
only
at
the
parent.
M
Maybe
that
maybe
I
misspoke
I
was
it
should
be
in
the
child
and
it
may
be
in
the
parent
as
well.
Ideally
it
should
be
in
the
parent,
but
to
manage
rollout.
N
M
C
C
Yeah,
thank
you
will
do
and
then
make
sure
that
there's
some
code
well
synchronization
according
to
or
update
in
the
other
working
groups,
maybe
by
the
chairs,
in
a
very
short
yeah
update.
J
F
C
Q
Q
Q
Minimum
another
point
is
the:
there
is
another
draft
from
schumann,
huck
and
I
believe,
paul
fixie
around
ns
revalidation.
I
haven't
thought
about
whether
this
also
needs
some
discussion
on
that
topic,
but
it's
something
to
think
about.
C
E
To
clarify
my
previous
comment
to
say,
I
don't
think
that
we
necessarily
need
to
reduce
this
down
to
one
draft.
I
think
that
there
are
a
lot
of
pieces
here,
and
maybe
it
is
too
much
for
one
draft
and
we
have
a
lot
of
authors
who
might
have
separate
areas
of
expertise,
but
I'd
like
to
find
a
constellation
of
drafts
that
work
together.
C
Thank
you,
paul
indexing
queue
and
you're
dropped.
Hopefully,
not
by
me
can
you
reapply
can.
G
G
Hopefully
this
will,
I
don't
know,
so
I
think
what
I'm
about
to
say
is
going
to
piss
a
lot
of
people
off,
but
I
think
it's
needed.
The
different
giraffes
have
different
use
cases
and
I
mean
his
touches
on.
G
I
think
what
ben
was
about
to
say,
but
was
too
polite,
which
was
that
the
different
authors
really
want
their
own
use
cases
pushed
forward
and,
quite
frankly,
there
are
drafts
that
have
not
even
been
written
that
could
be
in
this
space
because
we
were
waiting
on
dpriv
and
you
know
on
on
the
previous
work
in
deprive
to
set
up
the
use
cases
and
that
that
just
sort
of
got
lost.
I
went
when
when
this
discussion
happens
instead
of
saying.
Oh
look,
we've
got
a
bunch
of
drafts.
G
G
I
again
this
draft
to
me
is
a
lot
cleaner
than
the
one.
That's
being
discussed
in
deprived-
and
I
to
me
that's
that
is
an
advantage,
but
the
folks
in
the
peter
van
dyke
and
folks
in
deprived
have
a
very
specific
use
case
that
this
would
not
follow.
So
please
don't
look
at
you
know
please
chairs
and
that's
the
chairs
here
and
and
the
chairs
everywhere.
It
seems
like.
Please
don't
look
at
these
as
drafts,
but
as
use
cases.
Thank
you.
C
C
No,
so
the
working
group
chairs
will
discuss
this
with
each
other.
The
add,
deprived
and
dinosaur
working
group
chairs
will
coordinate
this,
how
to
go
go
further
and
make
sure
that
it's
either
at
least
it's
a
coordinated
way
forward
between
the
two
three
drafts.
G
Sure,
if
you
want
to
do
video,
that's
fine
with
me.
I
sort
of
believe
in
since
none
of
us
are
seeing
each
other
in
the
hallway
in
in
spain
right
now
sort
of
nice
to
have
humans
around
and
given.
I
can't
tell
if
medico
is
showing
my
my
lovely
face
or
not,
but
it
doesn't
really
matter
as
long
as
you
can
hear.
G
G
Okay,
so
excellent,
which
means
it's
statistically
likely
that
you
see
me
as
well,
so
this
is
proposed
new
work,
although
it's
really
a
revision
of
work
that
we
finished
not
that
long
ago,
next
slide.
G
So
rfc
8109
is
about
priming.
It
was
published
just
just
a
couple
years
ago
by
the
standards
of
this
working
group
and
it
explains
how
to
do
priming.
You
know
for
dns
for
with
the
root,
so
the
working
group
worked
on
it.
We
got
an
okay
amount
of
input
during
the
pub
you
know
during
the
discussion
we
published
it
and
then
a
bunch
of
people
asked
questions
after
it
was
published.
So
this.
If
it
was
one
question
I
might
say:
okay
well,
maybe
we'll
just
do
a
little.
G
But
in
fact
there's
a
bunch
of
questions
that
people
have
been
asking
since
8109
was
published.
The
first
one
is
well:
what
is
the
relationship
with
hyperlocal
or
what
is
now
rfc
8806,
which
was
7706.?
G
G
I
look
at
the
the
priming
list,
such
as
the
one
from
iana,
and
it
has
domain
names
in
it,
but
that's
not,
you
know
actually
covered
in
rfc8109,
and
so
we
we
actually
need
to
say
to
people
what
is
what
is
used
in
a
configuration
list
and
then,
of
course,
one
of
the
favorite
topics
of
this
working
group
was
what
about
the
tc
bit
and
in
specific.
If
you
send
a
priming
query
to
root
servers
and
you
are
not
using
edns0,
so
you
have
a
512
byte
limit.
G
The
answers
that
come
back
do
not
have
the
tc
bits
set
on
which
shocks
some
people
and
is
completely
the
correct
thing
for
others.
So
something
needs
to
be
discussed
about
that
and
then
someone
asked
and-
and
I
I
should
have
anticipated
this-
what
if
I'm
on
a
private
network?
What
you
know
like
what
should
I
do
about
priming
so
next
slide.
G
So
the
purpose
of
the
draft
here
is
to
make
small
updates
just
to
answer
these
questions.
That
is,
keep
the
vast
you
know,
keep
the
text
as
we
have
it
put
in
little
additions
for
each
of
these
questions,
plus
maybe
folks
in
the
working
group,
will
ask
the
questions
that
would
have
come
up
after
we
publish
this
now
but
again,
so
the
idea
is,
keep
8109
and
add
sentences
and
paragraphs
here
and
there
we
can
take
advantage
of
this.
G
Also
to
do
something
rsac
published
a
document
recently
on
terminology,
or
it
republished
that
also
as
a
dis
where,
in
that
document
they
actually
have
much
clearer
wording
for
things
that
are
in
you
know
about
the
root
zone.
So
right
now,
8109
talks
about
the
root
name,
server
name,
which
is
a
bit
confusing
rsac
itself.
G
I'm
sorry
for
those
of
you
aren't
familiar
with
with
all
the
icannes
rsac
is
the
root
server
system
advisory
committee,
which
is
a
formal
group
within
icann
that
advises
the
icann
board
on
root
server
stuff,
but
it's
it's
comprised
of
all
the
root
server
operators,
so
their
terminology
document
now
has
a
a
single
name
that
they
use
for
this,
which
is
called
the
root
server
identifier.
So
we
might
as
well
throw
that
in
to
clarify
here
so
next
in
the
last
slide.
G
So
if
this
is
adopted,
I
think
it
can
move
quickly.
I
don't
want
it
to
move
so
quickly
that
people
have
questions
after
we've
published
the
next
rfc,
but
it
I
don't
believe
that
there's
anything
controversial
here
other
than
additions
for
what
we've
had
already,
and
that's
it
for
this.
If
people
have
questions
or
comments.
C
Very
easy
yeah!
No!
I
we
will
definitely
put
this
also
as
one
of
the
chairs
actions
to
the
mailing
list
later,
but
well
as
a
chair.
We
would
like
to
hear
some
support
here
already.
C
F
C
G
But
again
I
these
are
mostly
responses
to
things
that
actually
some
some
folks
who
are
on
in
this
meeting
have
asked
me
privately.
So
I
would
hope
that
they
would
want
to
see
them
documented.
C
Yes,
indeed,
so
I
think
yeah
again,
chair
hat
off
personal
opinion
here,
I
think
it's
useful
work.
C
C
I
C
Okay,
yeah
yeah.
You
have
to
log
on
again
to
a
different
room,
good.
C
C
R
Yeah
I
was
just
going
to
comment
that
I
think
a
couple
people
were
saying
you
know.
Maybe,
since
you
have
the
time,
perhaps
you
do
take
a
hum
to
see
if
there's
actual
interest
in
130
people
who
are
on
here
about
doing
something.
With
this
last
draft
and
paul
yep,
just
the
suggestion,
there
are
a
couple
of.
R
C
C
J
I
J
We
will
go
ahead
and
and
ask
a
question
and
see
what
happens.
We've
had
discussion,
we've
had
this
presentation
of
this
new
draft
from
from
paul
hoffman,
and
the
question
is
whether
we
want
one
of
the
sufficient
interests
to
adopt
it,
review
it
and
eventually
publish
it.
We
will
start
the
hum
now
we
get
35
seconds
and
you
should
be
able
to
see
a
little
menu.
C
S
Yeah,
so
you
also
need.
J
C
J
Yeah,
so
we
will
ask
if
we
now
ask
the
inverse
of
the
inverse
question.
Do
people
think
that
we
should
not
adopt
this
draft?
J
Okay,
the
home
is
now
over.
One
thing
that
I
think
has
come
up
on:
the
working
group
chairs
list
is
whether
35
seconds
for
the
home
window
to
be
open
is
too
loud.
It's
too
long
or
not
long
enough.
So
any
opinions
on
that
and
the
results
we'd
have
some
middle.
Some
positive
middle
middle
range.
S
J
Yeah,
it's
very
hard
to
there,
there's
nothing
here.
That
shows
me
and,
and
frankly,
I
don't
want
to
know
how
many,
but
if,
if
what
you're
saying
is
true,
that's
that's
that's
good
to
know.
Frankly,
I
wouldn't
take
this
as
anything
except
an
experiment,
but
at
least
now
we
know
how
to
use
the
tool.
So
thanks
for
every
thanks,
everybody
that
stuck
around-
and
we
will
be
back
shortly
for
the
final
three
draft
discussions
for
dinosaur
ietf108
see
you.