►
From YouTube: IETF110-DNSOP-20210311-1430
Description
DNSOP meeting session at IETF110
2021/03/11 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
A
I
think
we
can
just
start
with
this
with
the
chair
slide,
so
tim
will
do
the
introduction
give
the
notewell
agenda
and
the
status
of
the
of
the
documents
yeah.
Okay,.
A
D
No
thank
you
benner
good
morning,
all
yep,
so
why
don't
we
move
on
with
the
chair
slides,
we'll
make
it
quick
yep,
I'm
still
there.
D
There
we
are,
let's
get
to
the
note.
Well,
you
know
me,
I'm
tim,
that's
benno
and
suzanne's
suzanne's
there
being
quiet
for
the
moment,
and
I'm
sure
you've
all
seen
this
by
now,
and
please
be
aware
that
everybody's
being
recorded
et
cetera,
et
cetera.
So
if
we
move
on
we've
got
two
meetings
back
to
back,
so
I
think
I
put
the
whole
agenda
down
in
here
later
on.
If
we
move
on,
then
it's
like
this
morning.
D
Session,
we'll
we'll
do
a
quick
update.
We've
got
some
current
work
that
we're
going
to
talk
about
and
some
hackathon
updates
from
willem
and
then
the
second
session
is
mostly
new
talks.
New
discussions,
things
of
that
nature.
So
the
next
slide,
sir
quick
note
coming
up
tomorrow,
there's
a
buff
called
danish.
It's
on
dane
authentication
for
iot
service
hardening.
I
they
probably
spend
a
lot
of
time
working
on
that
name.
It's
interesting
because
it's
you
know
it's
more
dane
stuff!
D
It's
it's
schumann
and
victor
plan
on
taking
over
the
world,
so
they've
got
two
things
to
talk
about.
Is
his
clients
cert
the
client,
cert
work,
they're
working
on
and
there's
some
interesting
stuff
going
on
there.
So,
if
you're
interested,
I
I
think
you
all
should
sort
of
make
a
note
to
pay
attention.
D
I
think
michael's
gonna,
one
of
the
things
he's
gonna
mention
at
the
end
of
the
second
session,
has
something
to
do
with
this
as
well
and
he's
one
of
the
chairs,
as
well
as
mr
hartiger,
so
if
either
of
them
want
to
sort
of
speak
up
and
say
something
they're
more
than
welcome
to
otherwise
you
know
it's
we
think
it's
interesting.
Oh
wes
wants
to
speak.
A
D
All
right
next
slide,
sir,
we're
doing
some
quick
updates
on
some
documents
and
we've
had
one
since
the
last
one
we
finally
got
zone
die
just
published
it's
89.76,
so
thank
you
dwayne
and
others
for
all
the
work
on
that
one.
So
currently,
server
cookies
is
in
the
editor
queue.
D
The
yang
document
needs
the
shepard
write
up
and
7816
biz.
It's
an
interesting
thing:
ralph
has
a
new
job
and
he
sort
of
dropped
off
the
face
of
the
earth
for
a
little
bit
and
he
seems
to
hold
the
pen
and
so
we're
trying
to
actually
track
down
what
to
do
there.
We're
not
letting
it
slide
we're
just
sort
of
in
in
flux
there,
and
I
have
to
finish
up
the
insect
ttl
working
group
last
call
and
sort
of
get
that
sorted
up,
peter
my
my
bad
on
that.
D
So
we'll
get
I'll
get
that
sorted
out
here
in
the
next
few
days,
so
the
currently
on
service
b.
That
seems
to
be,
as
I
sort
of
stated
earlier
this
week,
service
b
is
a
new
text
records
for
the
21st
century.
They're
they're
we've
been
they've,
been
doing
lots
of
work
and
there's
a
couple
things
they've
done
recently.
They've
sort
of
they
want
to
change
the
parameter
registry
to
first
come
first
serve
ben,
had
a
good
talk
with
diana
about
that.
D
We've
been
awaiting,
we've
been
sort
of
watching
because
the
the
ech
work
going
on
in
tls,
it's
kind
of
they're
going
to
be
tracking
each
one.
Each
document
so
they'll
probably
end
up
getting
batched
up
as
they
go
through
the
editor
queue.
There's
been
a
small
change
on
changing
echo,
to
fig
to
ech
and
there's
some
discussion
on
code
points
and
testing
that
we're
going
to
sort
of
settle
out,
but
we
do
think
we're
ready
for
working
group
last
call.
D
D
So
I
want
to
bounce
up
two
more
after
service
b
there's.
I
did
a
short
write-up
from
the
authors
about
delegation.
Only
there
we
go,
there's
been
some
work.
They've
addressed
these
issues.
The
zone
cut
label
the
empty
non-terminal
issue
resolved
in
the
latest
draft.
D
There's
a
blue
workaround
described
and
if
there's
a
better
solution,
they
really
want
to
hear
from
folks.
We
do
feel
all
the
protocol.
Technical
issues
have
been
raised.
If
there's
others,
we
know
this
is
a
controversial
one
and
I'm
sure
people
are
sort
of
going
to
push
back
on
some
of
this.
So
we're
I'm
waiting
to
see
what
gets
sort
of
said
along
the
way
here-
and
you
know,
is
this
ready
to
move
forward?
Are
we
going
to
move
forward
with
it?
Are
people
just
going
to
be
like?
No?
D
This
is
just
you
know,
so
we
I
know
this
is
sort
of
this
is
one
of
the
more
controversial
ones
so,
but
I
think
a
lot
of
stuff's
been
addressed,
so
we
welcome
to
hear
from
folks
so
jump
to
the
next
one.
We
do.
We've
got
a
couple
of
things
that
are
really
working
for
working
group
last
call
tcp
requirements,
it's
been
sitting
there
and
it
it's
more
been
sort
of
a
timing
thing
with
vote
with
some
of
the
chairs.
I
do
think
dns
revalidation,
that's
been
recently
updated.
D
I
think
it's
very
close.
If
not
it's
ready
already.
The
5933
biz
is
really
working
sort
of
waiting
on
this
sort
of
ionic
consideration
discussion
and
that
that
paul's
going
to
have
later,
because
I
think
paul
did
show
up.
He
said
he
may
not.
So
I
appreciate
glad
to
see
that
he's
made
it
and
84.99
biz.
D
D
A
couple
of
these
documents
have
expired
and
we've
been
trying
to
track
the
authors
down.
I
I
think
daniel's
gonna
update
validated
requirements.
We
do
you
know
we.
I
think
the
working
group
needs
to
figure
out.
Are
we
gonna
move
forward
with
these?
Are
there
worth
discussions?
You
know?
Are
we
just
gonna?
Let
them
expire.
D
We
should
just
not
let
them
expire
quietly.
We
should
really
sort
of
make
a
decision.
You
know.
Even
if
no
decision
is
the
right
decision,
we
should
at
least
state
that
so
that's
kind
of
my
feeling
on
that
one.
So
thanks,
let's
go
on
to
the
next
one,
there's
not
too
many
left,
oh
yeah.
We,
I
have
nothing
to
say
on
this
right
now.
I
usually
don't.
D
I
try
to
be
quiet
about
this
thanks
panel
and
this
one
we
were
gonna
basically
try
to
put
out
a
call
for
adoption
for
a
few
months
ago
and
I
think
it
got
lost
in
the
shuffle
after
the
last
meeting
around
the
holidays,
all
right,
so
I
think
this
will
be
revisited
and
probably
moved
out.
We'll
probably
do
that.
So
next
one,
I
think.
That's
really
our
main
things
are
working
on.
Roy
would
like
to
speak.
G
Hi
thanks
really
quick
on
private
use,
top-level
domains,
and
I
understand
that
the
iab
has
used
this
liaison
process
to
to
ask
a
question
to
the
iso
working
group
on
3166
country
codes.
Sorry,
I'm
trying
to
gather
my
thoughts
here.
So
that's
that's
the
statement
of
this
document.
I
think
we're
waiting
for
that
that
that
response
see
what
you
see
what's
going
on.
D
D
So
so,
thank
you.
Our
stuff
is
all
in
the
data
tracker.
It's
all
also
in
git,
so
folks
are
welcome
to
sort
of
check
in
and
sort
of,
tell
us
what's
going
on,
and
I
think
that's
it.
On
the
first
agenda,
willem's
going
to
talk
about
the
sort
of
hackathon
stuff
they've
worked
on
he's
going
to
talk
about
catalog
zones
and
paul
is
going
to
chat,
that's
kind
of
our
first
hour
and
then
session.
D
Two
we'll
we'll
have
some
more
sort
of
mr
drawer
son's
gonna
talk
about
avoid
fragmentation
as
we
decide
where
to
go
with
that
and
then
a
bunch
of
new
business
insect
three
guidance:
dynastic
automation,
et
cetera,
so
that's
the
essential.
What's
going
on
so
it's
it's
gonna
be
three
hours
sort
of
back
to
back,
so
we
hope
everybody
sort
of.
Has
you
know
nice
and
relaxed
and
ready
to
sort
of
get
going?
So
that's
all
I
have
to
say
and
I'll
stop
talking
and
let
people
sort
of
get
down
to
business.
A
Yeah,
thank
you.
Thank
you
tim.
So
one
correction
is
my
fault,
is
that
the
presenters
of
catalog
zones
will
be
libor
and
peter
peter
van
dyke,
but
that
will
is
probably
in
the
agenda.
It's
my
fault,
no
problem,
okay,
okay,
willem!
Are
you
ready?
I
will
share
your.
A
Oh,
yes,
you
have
screen.
Your
screen
is
granted
by
the
magic
powers,
so
I
will
stop
and
then
you
can.
I
H
So
yes,
we,
there
was
a
dns
hackathon
the
week
before
this
itf
week
on
working
days
from
the
march
1st
of
march
till
the
5th
of
march.
H
So
in
the
beginning
of
february,
our
last
in
the
previous
hackathon
at
the
itf
109,
I
we
used
the
dns
orgs
metamouse
to
talk
between
the
participants
of
the
hackathon
and
which
is
by
the
way
open
for
everybody.
I
have
a
link
on
the
hackathon
wiki
page,
where
you
can
subscribe
to
this
chat
service,
but
all
the
dns
developers
are
already
there.
So
it's
sort
of
convenient
place
to
talk
amongst
each
other,
and
I
renamed
the
channel
name
from
hackathon
109
to
hector
110,
and
then
some
people
began
sort
of
complaining.
H
It's
a
pity
that
we
cannot
have
in-person
hackathon
and
because,
like
hobby,
shedded
or
better
from
dyke,
you
know
hackathon
week
will
see
me
doing
three
small
15
minutes
things
over
that
week
with
a
hackathon
weekend
in
person
hackathon,
you
either
do
a
lot
of
stuff
or
absolutely
nothing
because
you're
only
chatting.
H
H
Do
the
winners
open
and
everything
that
yeah
so
matthias
came
saturday,
the
6th
of
march,
which
was
really
nice.
So
here's
my
ties
entering
on
the
6th
of
march
march,
so
before
the
hackathon
started,
there
were
quite
some
ideas
from
dns
developers
that
I
wanted
to
work
on
like
dns
over
quick
and
we
wanted
to
work
on
the
new
catalog
zone
stuff,
which
will
be
talked
about
later,
but
yeah
dns,
like
like,
I
showed
you
before.
Dns
developers
really
have
to
work
during
the
week
and
they
have
little
spare
time.
H
So
most
of
that
didn't
happen,
though,
there
was
also
a
plan
to
work
on
salt
and
that's
not
the
sentient
species.
That's
on
wikipedia
the
wikipedia
in
the
star
wars,
universe,
but
zone
transfers
over
tls.
H
H
But
there
was
a
the
people
listed
on
the
slide
she
found
pallavi
and
han.
They
had
a
small
group
working
from
the
united
states
and
we
had
a
new
developer
at
elnett
laps
tom
carpe,
who
worked
on
the
extended
dns
errors
vouter.
He
reviewed
all
chiffon
ballast
enhance,
commits
and
pedophile
diagrams
making
worked
on
results
for
paradigmas
and
for
bind,
oh
because
we
also
wanted
to
do
interoperability
testing.
And
for
this
I
registered
the
domain
name
zotrox
and
span
up
a
few
virtual
machines
to
do
interoperability,
testing
and
play
with
name
servers
and
salt.
H
Basically,
so
what
got
done?
Well?
Tom
coppay?
He
worked
on
extended,
dns
errors
in
nsd
and
he
found,
for
example,
when
going
over
all
the
air,
dns
error
or
error
codes
in
nsd
that
some
could
use
a
extra
code
point
for
as
a
extended
dns
error.
For
example,
when
a
dname
expansion
becomes
too
large
right.
So
there's
this,
it
returns
for
our
code.
Yx
domain,
which
means
some
name
that
ought
not
to
access,
does
exist.
H
That
doesn't
say
that
much
now,
this
combination
of
d
name
in
yx
domain
might
tell
you
that
it's
expansion
became
too
large,
but
we
also
noticed
that
other
name
servers,
return
surf
fill,
so
maybe
a
ede
code
for
this
would
be
nice.
So
we
did
now
with
other
pallavi
and
han
worked
on
access.
Controls
to
provide
sounds
results
only
of
course,
if
you
provide
sounds
over
tls,
you
do
not
want
them
to
leak
over
other
transports.
H
So
this
is
what
the
access
control
list
entry
looks
like
in
nsd
and
also,
if
you
make
access
control
to
provide,
sounds
for
the
whole
internet
without
a
t-sec
key
as
configured
in
the
above
pane,
then
nsd
will
warn
you
or
error
actually
that
this
is
not
allowed,
because,
if
you're
offering
over
tls,
you
do
not
want
other
ones
to
see
your
sound
content
and
if
you're
offering
it
to
everybody
without
authentication,
then
that's
probably
not
what
you're
meant
to
do
so.
I
tricked
for
testing
purposes
nsd
into
surfing
a
zone
to
everyone.
H
H
So
I
reused
the
same
access
control
mechanism
and
but
I'm
showing
this,
this
broke
the
name
server,
I'm
showing
you!
Why?
Because
you
know
to
do
a
zone
transfer
the
secondary
needs
to
do
a
shower
query.
First.
So
with
this
access
control,
I
prevented
server
queries
and
I'm
sharing
this,
because
I
think
it's
interesting
well
maybe
show
you
on
the
next
slide
bye,
because
maybe
you
also
do
not
want
to
leak
what
zones
you
are
serving
if
you're
offering
it
over
a
result
by
query.
H
So
maybe
you
want
to
prevent
server
queries
so
that
the
nameserver
cannot
discover,
which
sounds
are
served.
So
this
is
explicitly
not
part
of
the
vod
draft,
because
there
are
many
parts
which
will
leak
which
zones
are
served
like
a
notify,
for
example,
or
the
shower
query
preceding
a
transfer,
but
on
the
catalog
zones
we
have
an
option
with
a
talk
will
follow
after
this
one
in
which
the
serial
numbers
can
be
distributed
to
the
secondaries
via
the
catalog
zones,
potentially
over
a
tls.
H
H
H
Creating
the
the
secondary
primary
relationships
between
the
different
pieces
of
software,
and
what
did
we
learn?
You
know?
Maybe
it
would
be
nice
to
start
thinking
about
updating,
extended,
dns
errors
with
all
the
new
stuff
that
we
don't
have
nice
codes
in
ede
if
people
are
implementing
that
privacy.
H
E
A
Indeed,
thank
you
up
next,
unless
there
are
very
urgent
questions
here,
let's
check
in
the.
A
Okido
not
in
the
not
in
the
chat
room
either
yeah
then
I
like
to
invite
libra,
pelan
and
peter
van
dyke
for
the
next
presentation
shall
I
run
the
slides.
C
Thank
you
there
is.
There
is
quite
much
going
on
around
catalog
zones
and
there
are
things
to
be
discussed.
So
I'm
looking
forward
for
the
discussion
section
of
this
presentation
and
we
prepared
just
a
new
version
of
the
draft
just
before
the
iitf
meeting
deadline.
So
sorry
for
that,
but
yeah,
let
me
start
with
the
with
the
request:
what
catalog
zones
are
in
their
history
next
slide.
Please.
C
C
C
So
this
work
that
welded
for
the
operator
that
needs
several
groups
of
member
zones
with
different
configuration
in
each
group.
He
was
expected
and
we
actually
encouraged
him
to
operate.
Several
catalog
zones
where
each
catalog
zone
contain
the
members
with
the
same
configuration,
for
example
the
nsx
signed
and
in
the
second
group
unsigned
in
the
strategy
group,
for
example,
insect3
and
so
on.
C
But
a
problem
appeared
on
this
problem.
Was
that
once
the
operator
needs
to
transfer
the
member
zone
from
one
catalog
to
another,
he
just
needs
to
like
remove
it
from
the
one
catalog
zone
and
add
it
to
another.
One
next
slide
please,
but
this
process
can
be
like
synchronized.
When
you
modify
two
different
zones,
there
is
no
guarantee
that
the
xfl
to
the
secondaries
will
get
synchronized
or
gets
will
get
just
at
once.
C
C
It
was
quite
difficult
to
be
implemented,
but
I
managed
to
make
a
working
prototype
and
for
the
operator
it
was
quite
easy
to
operate,
but
not
entirely,
and
it
took
two
steps
because
it
can
be
done
at
once,
so
it
was
a
kind
of
roll
over
and
we
were
expecting
to
to
use
this
and
to
finally
solve
all
the
problems
of
catalog
zones.
But
please
next
slide.
C
Another
requirement
emerged
that
somehow
the
catalog
zones
you
are
removing
the
member
from
shall
have
control
over
which
in
other
catalog
zone,
is
the
member
transferred
to.
Please
wait
for
the
second
half
of
the
presentation
for
peter
who
explains
the
details
about
it,
but
overall
next
slide,
please
so.
C
C
B
B
Beyond
that,
we
found
that
some
operators
might
be
running
catalog
zones
from
multiple
users,
multiple
operators,
which
means
that
if
you
remove
a
zone
from
one
catalog,
you
do
not
want
that
zone
to
pop
up
randomly
in
some
other
users
catalog
that
that
list
has
listed
that
zone.
That
would
basically
be
hijacking
as
a
service.
B
So,
instead
of
that,
a
poweriness
contributor
called
case
monsauer
proposed
a
change
of
ownership
property
where
the
catalog
zone
that
is
about
to
remove
a
member
zone
can
tell
the
secondary.
I
want
this
member
zone
to
go
to
this
specific
other
catalog.
B
B
The
use
cases
for
that
have
not
been
described
in
our
draft
yet.
The
second
question
is,
as
I
mentioned,
that
the
signaling
of
serial
numbers
right
now
uses
c
sync
in
the
example,
which
seems
quite
appropriate
because
it
has
the
serial
number
and
a
couple
of
flag
fields
that
we
might
put
a
good
use.
B
Other
people
have
suggested
we
should
just
use
txt,
which
might
be
okay
because
it
does
live
at
the
same
separate
name
label
under
the
unique
id,
and
also
these
zones
are
not
for
querying.
If
we
ignore
the
first
question
here,
a
previous
version
of
the
draft
also
suggested
defining
a
new
serial
type,
holding
just
32
bits
of
a
number.
B
A
J
Hello,
everybody
peter
lieber,
thanks
thanks
for
creating
that
new
version,
and
I
I
talked
to
our
operators
team
before
and-
and
they
said
it's
absolutely
a
requirement
that
they
can
see
the
the
serial
number
of
the
zone,
the
catalogue
zone,
because
otherwise,
as
you
as
you
very
well
know,
we
need
to
bombard
the
primary
name
servers.
We
saw
our
queries
all
the
time
and
that's
very
frustrating,
so
one
of
the
main
use
cases
for
us
would
be
to
have
essentially
a
catalog
of
serial
numbers.
J
So
that's
much
appreciated,
no
matter
what
form
it
takes.
We
don't
really
mind
if
it's
messy
or
not.
I
mean
from
the
operational
perspective,
of
course,
but
as
long
as
the
serial
number
is
there,
it's
good.
B
Right
yeah,
the
plan
is,
for
the
draft,
of
course,
to
be
not
messy
in
the
end
as
well,
and
you
do
make
a
good
point.
Some
people
do
not
need
catalog
zones
to
tell
their
secondaries
what
domains
they
have,
but
some
people
do
have
a
serial
signaling
problem,
and
I
feel
that
the
intention
is
that
we
can
solve
that
too.
B
A
A
I
Yes,
so
yeah,
I'm
concerned
about
the
serial
signaling.
Actually,
I
think
there's
far
too
little
discussion
either
on
the
list
or
in
the
draft
about
how
these
serial
numbers
will
be
kept
up
to
date,
because
it
kind
of
either
implies
that
the
catalog
zone
itself
on
the
primary
server
has
to
either
be
synthetic
and
generate
those
values
on
the
fly
based
on
the
other
zones
that
are
present
or
to
have
some
other
active
band
process
automatically
update
the
catalog
zone
using
dns
update,
I
mean
I
mean
if
the
feature
is
optional.
B
B
I
Yeah,
I
mean
that's
good,
I
mean
we
are
actually
using
catalogues
in
production
at
ifc
for
our
lots
of
other
domain
names,
not
our
core
domain
name
and
yeah
it
would.
It
would
require
a
change
in
process
if
the
serial
stuff
became
mandatory.
A
So
what
so
to
the
author?
So
you
did
talk.
Oh
sorry,
liber!
Please
go
ahead
before
I
start
summarizing.
C
It's
baked
just
before
this
idf
deadline
and
we
were
expecting
much
more
like
discussion
around
either
approval
of
this
new
approach
or
or
denial,
or
something
like
that
yeah
besides,
my
my
personal,
like
if
my
personal
feel
fear
around
the
serial
property,
is
that
the
catalog
zone
will
be
updated
very
frequently
and
in
the
operators,
which
I
guess
is
the
usual
usual
use
case
for
catholic
zones,
which
have
very
many
member
zones,
it
might
lead
to,
like
the
huge
catalog
zone,
is
updated
frequently
and
this
other
properties
that
do
not
really
work
together.
C
B
B
I
Yes,
so
on
this
question
of
the
serial
signaling,
whether
that
be
text
t
or
c
sync
or
something
else,
I'd
like
to
reiterate
what
I
said
on
the
list
a
few
weeks
ago-
that
I
don't
think
it
should
be
c-sync.
I
I
That
said,
a
new
type
is
not
necessarily
the
right
answer,
because
then
we've
got
to
define
an
rr
type,
which
is
only
essentially
different
interviews
within
catalog
zones,
which
is
not
a
problem
in
terms
of
the
allocations
and
the
number
of
rr
types
that
are
available,
but
it
might
have
implications
here,
should
it
be
recorded
as
a
meta
type,
for
example,
or
indeed
there
are
new
type
of
types.
A
Thank
you
peter,
go,
please
go
ahead,
or
is
there
a
reply
by
one
of
the
authors.
B
K
Yeah,
although
yeah
so
the
comments
I
wanted
to
make
are
not
specifically
on
how
the
cereal
on
how
to
signal
the
cereals.
I
proposed
the
c-sync
thing
because
it
contained
the
field
for
cereal
and
I
don't
think
it
would
be
such
a
semantic
abuse.
But
I
don't
have
any
eggs
in
that.
K
So
I
raised
my
hand
here
to
comment
on
something
else,
which
was
the
catalog
zone
size
and
the
frequent
changes.
If
you
include
properties
like
serial
and
yeah,
it's
true
that
the
the
catalog
zones
can
become
pretty
large,
but
I
think
there
may
be
other
ways
around
that
that
are
different
from
just
avoiding
the
large
size.
K
For
example,
you
could
do
an
ix
r
instead
of
an
ax
fr,
which
of
course
not
all
server
software
supports,
but
so
that
might
be
something
to
be
considered,
because
if
you
do
an
ixfr
between
two
catalog
zone
versions,
then
the
diff
you
get
essentially
tells
you
the
recipe.
What
to
change
in
the
secondary
which
zones
to
add
to
remove
and
for
which,
once
the
serial
has
changed.
K
So
that's
pretty
much
a
minimal
set
of
what
you
would
want
to
know
in
such
a
case
and
also
so
that
is
from
the
conceptual
side,
not
from
the
implementation
side.
Of
course,
implementation
for
that
is
also
significant
work
and
all,
and
second
one
could
do
sharding
like
for
ip
reverse
zones,
which
are
usually
not
all
in
one
zone,
but
there
are
sub
zones
depending
on
the
graphics.
K
One
could
do
a
similar
thing
for
catalog
zones,
so,
for
example,
if
the
unique
id
that's
listed
here
at
the
top
bullet
would
be
some
sort
of
hash
of
the
member
zone
name,
then
you
could,
for
example,
split
up
the
catalog
zone
in
16
sub
catalog
zones,
for
example
by
the
last
or
first
digit
of
that
hash.
K
I'm
not
saying
that
should
be
done,
but
I'm
saying
that
if
you
do
such
sharding,
then
the
size
sort
of
reduces
exponentially
and
the
the
update
frequency
also
may
reduce
significantly
or
you
might
find
some
other
sort
of
grouping
for
frequently
and
non-frequently
changing
stuff,
for
example.
So
I
think
there
are
solutions
around
that
yeah
and
somebody
has
said
that
catalog
zones
will
not
be
publicly
queried.
K
That
may
be
not
the
current
intention,
but
I
can
first
see
use
cases
where
that
may
be
useful.
So
what
we've
discussed
on
the
dns
catalog
metamouse
zone-
sorry
not
zone
channel,
was
an
idea
that
I
had.
K
If
you
have
a
new
domain
and
you
communicate
the
ns
record
set
to
the
registry,
for
example,
to
dot
de
then
one
question
in
dns
setups
is
how
you
get
the
ds
records
that
provision
for
the
first
time
and
one
approach
could
be
to
take
the
host
names
in
the
ns
record,
set,
for
example,
ns1.whatevernameserver
and
use
that
as
a
catalog
zone,
have
sub-domains
of
the
nameserver
hostname
itself,
where
the
registry
can
query
properties
of
that
name,
service
member
zones
and
get
the
cds
records
from
there
to
provision
ds
for
the
first
time,
and
that,
of
course
works
only
if
the
name
server
zone
itself
is
signed
and
there's
other
issues
for
that.
K
A
Okay,
thank
you.
I
close
the
session
of
this
this
agenda
item.
Thank
you.
All
there
has.
There
is
an
metamouse
instance
channel
to
discuss
the
more
implementation
details.
So,
of
course,
the
protocol
discussion
needs
to
be
take
needs
to
take
place
on
the
the
mailing
list.
The
dean
is
up
mailing
list,
but
ask
the
authors
if
you're
interested
to
be
to
be
involved
a
little
bit
more
into
the
details
and
the
implementation
ask
them
how
to
get
on
the
metamouse
oarch
channel
for
the
catalog
zones.
A
It's
open
for
everyone,
okay,
any
other,
maybe
well,
let's
go
forward
to
the
next
session
to
the
next
item.
L
Okay,
so
greetings
and,
as
someone
said,
we
need,
we
need
a
new
term
that
is
not
good
morning
good
evening
good
afternoon.
L
So
it's
good
morning
for
me,
so
this
draft,
basically
you
know
we
discussed
it
at
the
last
meeting,
we're
here
now
and
I'd
like
to
give
just
a
very
brief
overview
and
then,
if
there's
more
discussion,
I
think
it's
best
on
the
list.
We
did
a
lot
of
mike
line.
The
last
time
that
didn't
go
to
the
list.
I
would
rather
see
stuff
on
the
list
next
slide.
L
So
this
you
know
after
the
last
meeting
I
had
done
this
as
personal
document.
It
was
adopted
as
working
group
document
after
the
last
meeting,
which
was
in
november,
which
I
guess
everything
is
still
in
march
of
2020.
I
published
the
zero
zero
in
january.
L
It's
really
short,
if
you
remove
the
normal
front
and
back
stuff,
it's
like
a
page
and
a
half
of
tech.
So
if
you're
wanting
to
read
a
short
draft,
this
is
this
is
your
draft,
but
there
was
no
discussion
on
the
list,
modulo
something
that
just
got
posted
this
morning,
which
is
cool,
but
I
you
know
clearly.
If
people
have
you
know
concerns
it,
they
should
be
on
the
list.
L
L
So
there
are
two
motivations
here:
one
is
the
goss
bist
draft,
which
again
needs
to
be
on
standards
track,
which
means
we
have
to
prove
it
as
a
standard,
even
though,
basically,
none
of
us
understand
it
and
and
I'm
not
picking
on
gost
at
all,
it's
a
national
standard
but
other
working
groups.
Other
protocols
don't
require
standards
track,
they
require
rfc,
published
and
so,
for
example,
just
literally
just
yesterday
for
tls
a
new
chinese
national
standard,
whose
name
I'm
actually
forgetting,
but
it's
in
rfc
8998
was
published.
L
Informational
went
through
the
independent
submissions.
Editor
had
plenty
of
comments
from
tls
active
people,
because
the
independent
submission
editor
always
does
that
anyways.
L
L
There
are
already
a
bunch
of
proposals
and,
in
the
last
few
weeks,
nist
proposed
that
it
might
in
fact
not
pick
one,
but
it
might
say,
let's
try
a
whole
bunch
of
these
for
a
while
and
then
we'll
pick
one
which
would
mean
if
and
since
we're
not
going
to
know
ahead
of
time,
which
ones
we
want.
It
would
mean
putting
a
zillion
of
these
on
standards
track,
which
is
much
more
heavy
weight
than
just
saying
rfc
required.
So
these
are
the
two
motivations
next
slide.
L
So
before
this
draft
was
was
even
started,
we
had
rfc
6014,
which
dnsx
did
in
2010,
which
made
all
of
the
the
dns
registries
rfc
required,
except
they
forgot
dns,
ds
and
nsac
records,
and
there
was
no
justification
for
forgetting
ds
and
nsac.
They
probably
just
forgot
them,
but
we
also
in
this
working
group
just
recently
did
rfc
8624,
which
is
algorithm
implementation
requirements
and
usage
guidelines.
L
Also.
I
also
had
the
motivation
of
trying
to
keep
it
under
two
pages.
I
think
I
did
that,
so
what
this
draft
does
is
that
it
updates
6014
to
make
it
rfc
required.
It
updates
8624
to
automate
automatically
make
these
non-standard
track.
Algorithms
may
implement.
L
L
If
there
is
a
point
later
where
a
national
standard
is
widely
adopted
or
that
the
working
group
wants
it
to
be
widely
adopted,
then
you
can
upgrade
in
you.
You
can
update
8624
to
say,
and
I
think
we
are
going
to
update
8624
in
the
future
anyways
to
say
this.
One
now
has
gone
from
made
should
or
whatever
my
third
bullet,
where
I
say,
that's
all-
is
actually
incorrect.
L
As
vladimir
pointed
out
in
the
one
comment
that
came
in
about
this
an
hour
and
a
half
ago,
which
is
that
I
also
in
the
iana
considerations.
I
also
make
the
nsec
3
and
nsec3
parameters.
Flags
also
be
rfc
required
and
vladimir
asked
isn't
that
dangerous.
We've
only
got
a
few
of
them,
there's
like
seven
left
or
whatever,
but
no
it's
not
dangerous
in
that.
If
all
of
a
sudden
they
start
filling
up,
we
change
that.
L
L
The
assumption
is
we're
going
to
be
following.
What's
going
on,
none
of
this
is
going
to
happen
behind
our
backs.
So,
for
example,
let's
say
someone
comes
out
and
has
a
new
insect
3
parameter
that
they
want
a
new
flag
for
dns
op
is
going
to
be
alerted
of
it.
Certainly
the
isg
is
going
to
be
alerted
of
it,
even
if
they
go
through
the
independent
stream.
L
Editor
there's
going
to
be
reviews
and
some
of
the
reviews
might
say:
hey,
don't
do
this
or
whatever,
and
so
we're
not
going
to
get
blindsided
by
by
all
of
a
sudden
running
out
of
flags
or
anything
like
that
or
we're
not
going
to
get
blindsided
by
someone
saying
I
didn't
even
know
that
there
was
such
a
new
national
algorithm.
There
will
be
stuff
sent
to
the
list.
It's
really
a
question
of.
Does
the
working
group
have
to
make
a
standard
for
each
one
next
slide
and
I
think
that's
it
or
maybe
that's
it.
L
You,
okay,
so
that's
all
modulo
the
one
thing
that
that
vladimir
brought
on
the
list,
so
I'm
open
for
questions.
But
again
my
preference
would
be
that
we
actually
discussed
this
on
the
mailing
list.
So.
M
Okay,
I
will
try
speaking
in
the
queen's
english.
I
think
this
is
a
lovely
little
draft
and
long
overdue
paul.
I
think
we
should
just
go
straight
to
last
call.
I
don't
think
we
need
to
have
further
discussion
about
this.
To
any
great
extent,
there
might
be
some
meta
issues
around
things
like
the
choice
of
algorithms
having
me
or
recommended
those
shoots
associated
with
them,
but
I
don't
think
that
affects
this
draft
in
any
way.
M
I
think
that
stuff
probably
needs
to
go
into
a
separate
document
that
explains
to
people
that
are
doing
dns
sex
stuff
with
new
crypto.
What
their
choices
are.
Crypto
algorithms
might
mean
from
the
point
of
view
of
interoperability
or
security,
because
the
fact
they
may
or
may
not
be
validated
as
they're,
not
necessarily
recommended
algorithms.
That,
I
think,
is
inside
an
entirely
separate
issue
and
not
something
for
this
document.
I
think
we're
just
going
ahead
and
get
this
thing
out
the
door
as
quickly
as
possible.
N
A
Thank
you,
jim
you're,
in
queue
very
brief,
and
we,
if
necessary,
we
do
have
some
five
minutes
in
the
next
session,
but
please
go
ahead.
A
Okay,
excellent
and
it's
up
again,
okay,
thank
you.
Thank
you
for
your
feedback.
Working
group,
indeed,
as
paul
asked,
also
send
some
comments
or
feedback
on
the
mailing
list
and,
as
I
understand,
and
also
the
question
of
the
author,
but
also
from
jim
and
maybe
others
up
to
a
working
group,
last
call
in
well
a
couple
of
weeks.
We
will
coordinate
it
with
the
author
and
the
dnos
hope
chairs
is.
A
A
E
E
That's
that
concludes
our
first
session.
Please
don't
forget
to
sign
out
of
this
meet
echo
session
and
join
the
other
one
because
they
are
in
separate.
This
sessions
are
in
separate
rooms,
but
we
do
have
two
hours
for
the
next
one
and
that
begins
in
exactly
half
an
hour.
So
go
get
some
refreshment
take
a
walk
around
the
block
and
we
will
see
you
shortly
for
session.
Two
thanks.
Everybody.