►
From YouTube: IETF111-DPRIVE-20210729-2030
Description
DPRIVE meeting session at IETF111
2021/07/29 2030
https://datatracker.ietf.org/meeting/111/proceedings/
A
B
A
Working
group
items
that
we've
been
discussing
so
the
first
one
up
is
going
to
be
ecker.
Talking
about
the
authoritative
recursive
to
author
tortata
servers.
C
Am
I
doing
these
slides
or
are
you
yes,
you
are
tim,
will
move.
C
No
problem
sounds
great
okay,
so
I
guess,
as
people
know,
we
we
proposed
this
draft
on
my
last
itf,
the
very
last
minute
that
was
basically
trying
to
do
the
authoritative
case
next
slide.
Please
so,
like
sorry
about
the
goofy
name,
there's
some
confusion
about
the
latest
tag,
which
gets
stuffed
in
by
martin's
tools
and
then
is
not
actually
supposed
to
be
part
of
the
name
anyway.
C
So
I
mean
this
is
like
kind
of
the
obvious
thing,
and
we
talked
about
some
of
this
earlier,
which
is
it
defines
how
to
do
authenticated,
authoritative,
with
the
assumption
that
the
authoritative
has
got
some
credential,
whether
it's
web,
pci
or
ordained
or
whatever,
and
they
use
the
svc
fccb
record
and
it
depends
on
signaling
in
the
parent
server
and
while
we
think
there's
some
value
and
being
able
to
have
signaling
outside
that,
there's
certain
very,
very
large
number
of
cases
where,
if
you
don't
know
at
the
time,
you
need
the
initial
connection,
you're
not
going
to
get
the
security
you
want,
and
the
draft
goes
in
some
detail
about.
C
Why
it's
the
case,
but
I
think
there's
like
not
too
much
dissent
about
that
next
slide.
So
there's
quite
a
bit
there.
There
are
four
major
classes
of
concerns
raised
here.
C
I
think
I've
bolded,
the
one
that
I
think
is
the
most
salient,
which
is
the
practicality
of
the
child,
svc
at
the
svcb
in
the
child
being
propagated,
the
parent
and
because,
as
I
said,
you
want
to
have
you
want
to
know
at
the
point
where
you
got
to
the
child
server
that
you
have
you
expect
tls
or
or
docs,
then
you
need
some
indicator
there
or
other
things
kind
of
don't
work
as
well,
as
you
would
hope-
and
there
are
a
number
of
concerns
related
to
the
practicality
of
this
paul's
gonna
talk
about
this
like
excruciating
detail,
so
I'm
gonna
bracket
that
mostly
there
are
also
concerns
raised
about
the
authentication
mechanism,
whether
it
should
be
web,
pi
or
dane,
or
both
whether
what
kind
of
transports
we
have
to
allow
dot
versus
doe
for
stoke,
and
also
can
we
equip
to
the
root
like
at
all,
which
isn't
necessarily
requirement,
but
it's
attractive
in
general.
C
So,
okay!
Well,
this
is
a
bad
slide.
I
apologize
so
I
just
started
reading
the
last
point
so
so,
as
I
said,
we
use
the
svcp
record
to
signal
that
you
should
be
that
you
should
be
expecting
tls.
C
This
seems
like
a
challenge
in
the
short
term
because
of
because
of
the
ability
to
get
this
vcb
into
the
parent
and
ben
schwartz
said
warren
kumari
resurrected
this
draft,
which
defines
how
he's
the
ns
record
to
kind
of
hack
around
this.
Now
you
see,
I
have
should
work
now.
I
believe
paul
thinks
it
shouldn't
work
now,
so
I'm
I
I
I
don't
propose
to
I
just
let
him
cover
that.
C
Not
maybe
I
just
want
to
bracket
that
so
people
didn't
think
that
that
I
was
getting
out
too
far
by
skis
here.
I
hadn't
seen
small
slides
so
there's
some
sentiment.
That's
not
the
right
long-term
answer,
but
there's
also
a
fair
minus
m,
but
it
is
the
right
term
long-term
answer.
So
this,
like
last
bullet
point,
it's
not
amazing,
but
I
think
it's
clear
that,
like
there's
a
short-term
answer,
it's
not
amazing.
Okay
next
slide,
so
I
think
this
slide.
C
I
think,
as
I
said,
there's
some
confusion
about
like
paul
versus
my
talks,
but
the
way
forward
that
I'm
proposing
is
the
fallen.
We
dropped
this
draft,
we
we
need
a
for
now
answer
for
signaling
and
I
think
that
we
were
intending
to
point
to
trash
shorts
rather
incorporate
it
they've
been
stock
of
incorporating
it.
I
think
ben's
just
did
we
just
point
to
it.
C
I
think
that
we
prepared
to
and
then
the
other
open
issues
I
put
that
we've
actually
discussed
after
we've
been
after
the
draft,
because
the
idea
is
to
get
to
get
the
thing
in
the
ground
or
do
something.
So
I
think
we
should
prepare
to
remove
svc
being
very
entirely.
If
we
have
to
become
conclusion,
it's
simply
never
going
to
be
viable
and
then
I
think
the
remaining
issues.
C
You
know
these,
these
questions
about
whether
which
transports
we
support
or
what
the
authentication
mechanism
are
seemed
like
break
issues
working
with
discussion,
but
don't
don't
like
necessarily
shouldn't
get
in
the
way
of
deciding
what
we're
generally
going
to
do,
and
eventually
we
know
we
can
argue
with
them
and
take
a
hum
or
whatever.
So
I
think
you
know,
may
take
a
step
back,
even
perhaps
from
this.
C
You
know,
I'd
like
us
to
work
on
this
case,
I'd
like
to
get
to
the
point
where
we
persuade
ourselves
that
it
can
be
solved
and
then
work
on
solving
it.
C
So
I
think
you
know,
I
think
we
just
agreed
to
have
a
whole
discussion
except
for
clarifying
questions
after
paul
presented,
but
I
think
you
know
what
I'd
like
to
get
out
of
this
discussion
is:
do
we
think
this
cannot
be
solved
at
all,
in
which
case
we
could
just
back
it
up
and
not
work
on
this,
or
do
we
think
it
can
be
solved?
C
And
then
what
would
be
the
minimum
showing
of
doing
that
and
the
minimum
direction
forward
to
be
the
point
where
we're
gonna
sort
of
actually
do
that
work,
as
opposed
to
debating
where
that
work
can
be
done,
which
is
where
we
are
now
and
so
I'd
like
I'd
love
to
get
that
soon
because
like
if
we
can't
if
this
can't
be
solved,
I
want
other
things
I
want
to
do
and
if
it
can
be
solved,
I
want
to
do
them.
C
D
C
Echo
sure
I
think
the
problem
I
and
the
problem
to
be
solved
is
an
authenticated
connection
to
the
server
in
a
way
that,
up
before
you
catch
the
server
you
know
it
should
be
authentic.
It
should
be
authenticated.
C
E
Weird,
okay,
there
seems
to
be
bug
if
you
select
the
microphone
once
it
doesn't
work,
but
then
unselecting
a
second
again
works
anyway.
Just
for
me
clarification
because
I'm
I'm
not
entirely
sure
if
you
think
that,
let's
say
svccb
at
parent
wouldn't
work,
I
think
everything
else
would
still
be
worth
doing
in
the
svcp
in
the
adopt
document,
because
I
don't
think
the
protection
of
the
name
server.
E
That's
in
baileywick
is
that
important
and
I
don't
think
that
there's
much
to
be
gained
from
finding
out
the
right
name,
server
name
and
that
that's
too
revealing
about
the
domain
name
itself.
So
I
think,
even
if
svcp
in
parent
and
draft
schwarz
deprive
name
signal
would
not
be
feasible.
I
think
everything
else
still
is
useful
to
do
and
then
maybe.
B
E
Another
better
way
of
doing
what
these
two
things
are
doing.
I
just
want
to
clarify.
I
think
everything
else
is
still
good.
I
think
svcb
in
general
to
convey
this
information
is
good
and
I
wouldn't
want
to
see
that
all
go
away.
C
Right
all
right,
I'm
getting
echo
sorry,
it's
been
a
little
late
in
the
day
for
me,
but
or
early
or
whatever,
but
I
don't
think
it's
a
matter
simply
of
in
bailiwick,
but
I
think
it's
a
matter
also
of
of
protecting
it
which
to
say
that
absent,
dns
sec.
If
I,
the
parent,
doesn't
tell
me
I
can
encrypt
to
the
child,
then
the
attacker
can
force
me
back
down
and
unencrypt
the
posture,
and
so
even
out
of
baileywick
records.
C
I
don't
I
don't
get
privacy,
so
I
think,
if
you're
prepared
to
assume
the
university
of
the
nsac,
yes
you're
correct,
but
if
you
are
not
ursula
university
in
essex,
which
I'm
not,
then
I
don't,
but
I
think
you
actually
need
a
parent.
C
E
Sorry
yeah,
I
think
I
think
you're
wrong
there,
because
if
I
have
securely
resolved
ns1.dreamhost.com,
then
if
I
get
for
another
domain
and
I
get
the
ns
record
then
what
else
do
I
need
like?
I
don't
need.
I
already
know
the
keys
to
that
name
server,
so
I
can
already
set
up
my
encrypted
authenticated
channel.
So
there's
no
there's
no
issue
for
that
target
domain
that
it
doesn't
have
an
svcd
in
the
parent
you
may
not
have
I
mean
if
I,
if
I'm
cached,.
C
E
A
Okay,
let's
move
on
brian.
F
Dixon
so
I'll
start
off
by
saying
ecker
you're
wrong.
Let's
first
say:
okay,
the
in
bailiwick
case,
where
the
name
server's
name,
the
the
zone,
is
being
served
by
a
name
server.
That's
in
the
zone
itself
that
will
never
have
privacy
modulo
some
serious
upgrades
that
are
gonna
take
decades.
That's
never
gonna
happen.
F
If
we
ignore
that
case
of
the
in
bailiwick
name
server,
then
the
real
issue
is
that
when
you're
looking
in
the
com
zone
for
the
nameserverforexample.com-
and
it
gives
you
a
name
server
of
ns1.example.net-
the
the
issue
that
remains
is
how
do
you?
How
do
you
make
a
a
secure
or
how
do
you
validate
the
the
glue
data
for
ns1.example.net
and
currently
that
is
not
possible,
the
the
glue,
the
ns
records
and
the
glue
a
records
if
they're
there
are
not
signed.
So
that's
an
issue
that
extends
beyond
just
adoc.
F
It's
a
it's
a
large
issue,
something
I'm
going
to
tackle
in
dns
off,
but
it's
it's
separate
and
once
that's
solved
then
connecting
to
or
making
a
query
to
ns1.example.net
for
something.
That's
dnsx
signed,
whether
it's
the
the
tlsa
record
or
some
other
thing
to
tell
you
how
to
to
make
the
query
to
ns1.example.net
for
example.com
that
that's
the
the
piece
that
you
want
to
have
tls
on.
But
that's
that's
a
solvable
problem
without
requiring
signaling
at
the
parent.
C
F
Requirement
it's
a.
F
B
All
right
victor,
I
want
to
add
one
thing:
I'm
also
skeptical,
but
we'll
discuss
that
later
about
the
viability
of
parent
site,
signaling
of
the
sort
that
you're
envisioning.
But
one
thing
we
haven't
discussed
is
the
possibility
of
putting
signaling
not
in
the
forward
namespace,
but
in
the
unavoidably
leaking
ip
address
namespace.
B
That
is
when
you
discover
the
ip
address
of
the
name
server
the
signal
link
for
whether
to
use
tls
there
can
come
from
the
arpa
zone
which
can
be
signed
and
so
on
and
so
forth
and
does
not
leak,
even
in
the
in
in
bailiwick
case.
What
the
actual
domain
is
that
you're,
looking
for
you're
wondering
whether
an
ip
connection
to
this
ip
address
for
on
port
53
should
be
tls
or
not.
C
I
think
I
think
a
lot
of
if
a
number
of
other
people
feel
that
way,
then
we're
not
then
adopted
this
draft.
We
premature.
G
Hello
eric.
Can
you
hear
me?
I
can
all
right
first
paul
walter
said
if
food.com
is
on
dream
host
and
therefore
you
have
cash,
that
dream
host
has
dot
or
diskey,
etc,
and
then
bar.com
is
also
on
dream
host.
You
can
reuse
that
information,
an
attacker
that
is
on
path,
might
change
the
delegation
information
for
bar.com,
because
it
is
not
the
nsa,
authenticated
point
you
to
dreamhost,
xxx.com
or
whatever,
and
give
you
the
same
ip
or
even
a
different
ip.
G
So
you
still
have
a
hole
in
that
all
flow
and
as
for
the
victor
set
tying
everything
to
the
ip,
it
has
the
same
problem.
The
glue
data
is
also
unauthenticated,
so
neither
of
those
completely
solved
the
problem
even
on
a
hot
cache.
C
Thank
you,
so
I
I'd
assumed
the
connection
of
the
parent
was
encrypted
as
paul
was
saying
on
jabber,
because
otherwise
I
don't
see
how
this
works
at
all.
But
maybe
I'm
misunderstanding.
You.
G
If
the
connection
to
the
parent
is
encrypted
safely
with
some
authentication,
then
none
of
what
I
just
said
is
relevant
correct,
but
so
far
I've
been
assuming
that
dot
com
will
not
be
going
along
for
a
while.
C
So
yeah,
I
think
so
I
think
what
I
I
mean.
This
is
like
the
the
the
security
logic
behind
the
design
that
I
have
in
mind
is
is
not
too
dissimilar
from
the
the
sort
of
like
from
this
https
design,
which
is
basically
as
long
as
you're
and
as
long
as
you
start
somewhere
secure
and
you
have
an
unchanged
set
of
links
that
are
encrypted.
Everything
is
fine,
but
if
any
of
those
links
are
unencrypted,
then
it
breaks
down.
C
So
the
way
I'd
assumed
to
plan
fix
the
I
mean
I
was
hoping
the
way
we
fixed
this
problem.
So
I
think
I
think
that
the
the
two
two
leds
will
have.
The
tlds
will
have
to
be
encrypted.
It
doesn't
kind
of
work,
but
the
root
of
these
you
could
imagine
not
be
encrypted
and
the
two
tlds
individually
be
encrypted
and
have
the
remember
the
recursive
memorize
that
somehow
I'm
happy
to
have
about
chairs
by
the
way
cut.
C
A
Okay,
we'll
we'll
we'll
cut
the
the
mic
line
at
daniel
and
then
we'll
transition
over
to
paul's
talk.
G
Okay,
so
yeah,
I
agree
the
route
is
uninteresting
because
you
can
download
the
root
zone,
verified,
etc,
but
expecting
the
tlds
to
encrypt
is
a
big
ask,
and
I
fully
agree
that
everything
you're
saying
will
work
if
they
agree
to
do
that.
Sure.
C
Right,
well,
I
think
if
we
can't
get
the
tlds
during
crypt,
we
have
a
big
problem
anyway,
because
so
many
of
the
resolutions
that
are
sensitive
or
the
two
lds.
So
if
you're,
if
my
connection.com
isn't
encrypted,
then
I
just
leaked
that
I
was
go.
What
what
where
I
was
going
in
the
first
place,
so
even
if
we
could,
even
if
we
only
were
at
the
first
top,
we
solved
a
problem.
D
So
two
things:
first
to
the
point
that
you
just
made
echo
scott
hollenbeck
talked
at
the
last
ietf
meeting
here
saying:
verisign
is
going
to
be
very
conservative.
It's
going
to
take
a
long
time
and
such
if
you
do
just
a
quick
look
at
the
ns
records
at
random
ns
records,
the
vast
majority
of
them
end
in
commernet,
and
so
you
may
you
may
be
optimizing
for
that.
D
Going
back
to
a
thing
that
victor
said,
though,
which
is
oh
well,
maybe
we
can
use
a
reverse
tree,
dns
sex,
signing
sucks
in
the
forward
tree
and
it
sucks
even
worse,
I'm
sorry
deployment
of
dns
sec
signing
sucks
in
the
forward
tree
and
it
sucks
even
worse
in
the
reverse
tree.
So
if
you
look
at
random
domain
names,
you
know
not
using
a
most
popular
list,
but
even
looking
at
others
we're
talking
about
four
percent.
D
So
it
would,
in
my
mind,
be
odd
for
this
working
group
to
adopt
a
working
structure
that
just
could
not
be
deployed
unless
dns
sec
deployment
got
a
lot
better.
Icann
has
been
really
really
trying
to
get
people
to
do
the
nsx
deployment
for
a
long
time
and
we've
basically
leveled
out
so
and-
and
I
believe
that
would
even
be
worse
in
the
reverse
tree
going
to
what
victor
was
talking
about.
Thank
you.
C
Thanks,
I
was
unclear
about
that.
So
thank
you.
I
guess
maybe
we're
taking
a
step
back.
I've
heard
a
number
of
times.
People
say
they
don't
think
that
the
the
tlds
will
do
this.
That
may
well
be
true,
but
I
think
if
that's
true,
we
should
have
banned
an
entire
project
because,
like
the
amount
of
the
amount
of
the
amount
of
of
value
we're
going
to
get,
if
all
that
happens,
is
that
example.
C
is
it
you
can
just
is
it
you
can
protect.
People
from
you
know
whether
whether
you're
dereferencing
ns.example.com
or
food.example.com,
like
seems
extraordinarily
marginal.
So,
like
you
know,
I'm
hoping
that
something
will
happen
here
but
like
if
I
knew
first,
a
fact
that,
like
no
major
cld
would
do
this,
then
I
would
just
pack
up.
C
C
C
H
So
I
agree
with
you
that
if
none
of
the
tlds
are
willing
to
do
this,
this
is
a
lost
cause,
because
that's
where
most
of
the
sensitive
information
is,
but
if
even
one
of
them
is
willing
to
do
it,
I
don't
think
this
is
a
lost
cause
right.
I
mean
this
is
a
differentiating
factor
between
tlds
and
I
could
imagine
if
you
were
operating
a
sensitive
network
service
wanting
to
move
to
a
tld
that
does
support
this
as
part
of
your.
You
know,
as
part
of
your
plan,
going
forward
to
protect
your
user
base.
H
H
As
far
as
the
reverse
zone,
I
think
there's
even
more
problems.
Besides
lack
of
dns
sect
deployment
in
the
reverse,
there
are
a
lot
of
name
servers
that
are
out
there
that
are
referred
to
by
multiple
names,
and
it's
not
at
all
clear
that
if
you're
doing
this
sort
of
signaling
on
that
endpoint
that
all
of
them
will
have
authentication
at
the
same
time,
particularly
if
we're
talking
about
authentication
being
named
authentication,
the
certificates
that
are
on
offer
may
support
name
x,
but
not
support,
name
y
and
both
of
them
are
used.
H
And
if
we
say
that
you
can
only
signal
based
on
the
ip
address,
you're
effectively
saying
that
that,
to
signal
hard
fail
for
one
of
the
names
that
this
name
server
is
known
by,
you
must
inflict
hard
fail
on
all
the
other
names.
This
name
server
is
known
by,
and
that
is
not
a
viable
deployment
option.
A
Okay,
so
why
don't
we
go
ahead
and
transition
over
to
paul's
presentation
and
that
way
we
can.
We
can
reserve
the
rest
of
the
of
the
meeting
to
discuss
some
of
these
more
larger
scale
points.
So
paul.
Are
you.
E
Ready:
okay
next
slide.
E
So
just
a
quick
overview,
so
I'm
talking
about
two
drafts
drafts
that
ecker
was
just
talking
about
and
the
draft
that
he
mentions.
Draftswards
deprive
name
signal
zero
zero.
So
I
won't
have
to
explain
what
they're
doing,
because
that
this
is
roughly
explained
so
next
slide.
E
That
is
a
copy
of
what
lives
at
the
child
at
the
parent
that
you
can
then
verify
at
the
child
if
you
want
to-
or
it's
a
record
that
only
lives
at
the
parent
and
not
at
the
child's,
such
as
the
ds
record,
both
have
their
own
set
of
issues.
First
of
all,
you
need
to
update
all
the
major
dns
software.
You
need
to
deploy
this
at
the
tlds
and
and
everywhere
else.
Then
you
need
to
update
the
recursive
servers
everywhere
and
then
the
application
somehow
must
be
sure
not
to
use
this
standard.
E
Dns
resolver
path
that
might
leak
to
might
might
lead
to
unupdated
software
and
starts
leaking.
So
then
it
would
have
to
do
like
some
special
lookups
to
to
to
make
sure
that
it's
using
only
the
the
new
servers.
This
is
gonna
in
itself,
is
gonna.
Take
a
long
time-
and
I
don't
think
this
is
something
that
that
we
can
do
like
I
said
10
plus
year
problem.
I
then
I
think,
that's
really
the
case
next
slide.
I
E
If
you
have
an
updated
epp
protocol
like
a
new
extension,
then
you've
got
to
have
that
deployed
at
the
registries.
You
have
to
get
it
deployed
to
registrars
all
the
registrars
and
subregistrars
have
to
update
their
web
portal
is
often
the
way
these
these
these
records
are
started
and
make
it
out
to
the
to
the
registry,
and
then
we
run
into
the
same
problem.
E
E
So
I
think
you
know
the
working
group
was
two
choices:
either
we're
going
to
say
svcp,
the
parent
is
just
not
going
to
happen
and
anything
that
we
define
as
an
interim
solution
will
become
the
permanent
solution
and
we
just
live
with
that,
and
but
we
make
that
choice
actively
or
we're
going
to
say.
Well
we're
going
to
run
like
this
as
it
is
specified,
but
then
I
think
what
will
happen
is
that
browsers
will
start
using
only
trusted
up-to-date,
dns
servers
that
have
been
updated.
E
It
will
still
take
a
long
time
because
of
the
dle
server
upgrades
that
need
to
happen,
and
I
see
that
that
further
leads
to
more
dns
server
centralization
in
general
and
maybe
even
a
splitting
of
you
know
browser
dns
and
other
dns,
and
I
think
that's
that's
not
good.
So
I
would
like
to
just
like
solve
the
problems.
While
we
know
that
these
problems
are
there
next
slide.
E
So
the
interim
solution-
this
is
actually
been
talked
about
quite
a
bit,
so
just
for
the
people
who
aren't
aware
the
the
solution
is
to
basically
encode
svcb
content
into
a
fake
name,
server,
name
in
a
clever
way
that
it
fits
and
publish
that
at
the
parent.
Now
this
goes
back
to
the
dns
curve,
hack
from
dgb
right
where
he
was
going
to
have
his
curve.
2
5
19
key
encoded
in
the
nameserver
record
name,
but
there's
a
number
of
problems
with
it.
E
E
Is
that
a
sort
of
rogue
tld
could
actually
put
this
glue
in
there
and
pointing
to
its
own
server
and
still
happily
serve
everything
but
get
a
copy
of
all
the
records
that
people
are
caring
about
and
basically
create
like
a
nation-state
man
and
a
middle
type
infrastructure
by
simply
adding
some
unsigned
ns
records
to
that
zone,
which
I
think
sets
the
bar
really
too
low
for
for
people
to
start
doing,
man
on
the
middle
attacks,
iups
or
coffee
shops
could
do
the
same
thing
and
bypass
this.
This.
E
This
path,
which
I
don't.
E
A
good
good
path
forward.
We
have
talked
about
this
in
the
past,
with
peter
van
dyken
in
in
the
working
group
as
well
about
encoding,
something
like
this
in
a
ds
record.
What
is
the
advantage
of
the
ds
record
is
that
it
is
actually
signed
by
the
parent.
It
is
authenticated
by
the
child
because
it
came
in
through
some
authenticated
mechanism
like
epp
or
maybe
cdns
in
the
case
of
the
child,
uses
a
dns
secondary
zone
and
these
mechanisms.
E
So
there
is
a
method
of
transporting
new
kind
of
ds
records.
There
is
some
leeway
that
unknown
or
unexpected
ds
records
that
you
don't
really
know
how
to
process
you're
supposed
to
ignore,
and
you
can
then
pick
the
other
one
that
you
like,
so
it
shouldn't
interfere
with
the
current
dns
resolving
for
which
the
ds
records
actually
used.
So
you
could,
probably
you
know,
overload
it
and
store
that
same
information
and
code
it
there.
E
It
should
require
no
dns
server.
Software
update
and-
and
it
is
also
protected
with
the
nsx.
E
If
the
child
really
cares
about
this
being
authenticated
and
and
it
uses
dns
sec,
it
can
actually
put
a
cds
record
in
the
child
so
that
anyone
trying
can
confirm
that
the
parent
data
is
actually
legitimate
and
conferred
by
by
the
child.
So
then,
a
rogue
parent
will
not
have
to
just
insert
an
unsigned
record.
E
They
actually
have
to
insert
a
signed
record,
which
you
know
they
go
on
on
record
for
proving
that
they
have
abused
their
power
or,
alternatively,
they
have
to
nuke
the
entire
child
zone
and
take
the
whole
childhood
over
to
to
man
in
the
middle
them.
So
I
think
those
are
that's
a
much
better
scenario
than
using
dns
record,
so
I
think
that's
mostly
it.
So
I
think
we
can
go
back
to
the
original
discussion.
A
Okay,
watson
you're
first
in
the
queue.
J
Hello
watson,
thank
you.
I
didn't
regret
this
first.
This
this
presentation
has
made
me
very
sad
about
the
prospects
of
deployment
here,
which
I
think
was
the
intention.
I
do
want
to
push
back
against
the
idea
that
we
should
expect
resolvers
never
have
to
change
a
thing.
J
Resolvers
do
need
if
especially
recursive
resolvers
are
going
to
need
to
deploy
updates
if
we're
going
to
deploy
any
sort
of
query
privacy
mechanism
to
enable
that-
and
we
we
shouldn't,
have
the
expect,
you
know
that's
sort
of
inherent
to
the
problem
space
while
with
sort
of
tlds
etc.
That's
a
little
more,
you
know,
there's
only
one
tldoperator.com
and
you
know
paying
them
to
change.
Things
is
obviously
a
much
harder
thing
than
a
software
update
to
a
recursive.
K
Do
you
mind
going
back
a
slide?
I
completely
didn't
understand
your
second
bullet,
so
the
name
signal
thing
simply
encodes
in
the
name:
server
name
the
fact
that
it
does
dot
or
something
similar.
It
doesn't
have
the
key
there.
So
I
don't
understand
why
changing
name
server
keys
causes
any
issue,
so
it
either
wildly
misunderstanding
something.
E
K
E
But
they
never
heard
they
never
heard
failed,
so
they
never
heart
failed
on
any
of
this
right.
If
we're
going
to
do
a
heart,
fill
based
on
unexpected
authentication
or
like
like
a
different
identities,
then
that
could
be
problematic.
I
mean
you're
right,
it
is
it
is.
It
is
a
better
mechanism
than
just
storing
the
public
key
there,
but
I
think
it's
still.
It's
still
problematic.
K
A
Okay,
eric.
C
Nation
paul,
so
I
think
I
think
I
think
you're
making
a
pretty
strong
case
that,
like
we
need
to
that,
whatever
we
define
that
to
do
now,
we're
going
to
be
living
with
for
a
very
long
time.
So
I
think
that
part
I
agree
with
so
I
guess-
and
if
I
just
summarize,
I
think
if
I
understand
your
position
is
that
you
think
we
should
put
this
information.
The
ds
record
is
that
a
fair
summary
of
a
position.
E
It's
it's
one
proposal
that
I
think
is
worth
exploring
and-
and
I
just
want
to
make
clear
for
the
people
who
might
not
have
understand
it.
I
think
you
can
get
a
ds
record
at
the
parent
without
you
yourself
needing
to
deploy
dns
sec
and,
if
we're
looking
at
mostly
tlds,
all
the
tlds
basically
deploy
dnsx.
So
it's
not
a
requirement
for
the
child
zone
to
run
dns
right.
C
And
thanks
that's
a
good
clarification
so,
and
I
think
that
the
the
you
know
the
properties
of
this
signal,
whatever
it
is,
it
seems
to
me,
have
to
be
the
following.
At
least
one
is:
it
has
to
be
easily
propagated
from
the
from
the
child
to
the
parent
two.
It
has
to
be
only
apply
to
this
particular
child,
if
possible,
not
to
every
not
to
every
child
with
the
same
name.
Those
things
are
the
two
most
important
properties.
C
I
think
you're
implying
there's
another
property
here
too,
which
I'm
a
little
less
like
sanguinom,
which
is
this
bit
about
it
being
being
secure
in
the
exact
security
properties
you're
indicating
here.
I
guess
the
reason
I'm
not
that
sanguine
about
it
is
because
I
say
I
think
most
information
is
being
transmitted
at
this,
like
you
know,
is
being
transmitted
like
like
right
here,
which
is
to
say
like
if
you
know,
if
I
go
to
com
right,
so
I
had
to
use
commas.
C
In
example,
if
I
go
to
com
right-
and
I
say,
give
me
example.com
and
it
like
lies,
so
they
can
set
up
like
a
tap
right.
Well,
I
mean
it
already
knew
I
wanted
to
go
example.com,
so
it's
just
like
you
can
just
cipher
that
information
up
anyway.
So
I'm
not
as
I'm
not
as
worried
at
this
particular
tactic.
C
E
C
So
I
think
in
the
case
the
the
case
of
the
his
in
question
is
that
I'm
going
to
like
I'm
going
to
com-
and
I
wanted
to
reference
example.com
and
we'll
say
that
and
we'll
say
that
the
real
server
is
example.net
but
like.
But
execute.com
is
going
to
hurt
me
to
evil.com.
Is
that
your
example.
C
Maybe
we
should
write
this
down
because
I
think
I'm
getting
confused,
but
so
I
guess
anyway,
like
I
am
like,
as
I
hope
is
clear.
I
am
like
actually
quite
indifferent
to
exactly
how
this
is
spelled.
So,
if,
like
ds
works
better
than
like,
then
like
this
name
server
hack,
I,
like
I'm
perfectly
fine
with
ds,
and
I
I
think
your
point
about
like
the
fact
that
the
parent
zones
are
like
large
assigned
like
fairly
compelling.
C
I
would
prefer
that
to
require
dns
sec
but
like
given
that
I
think
most
information
is
in
it
between
the
one,
the
tld
and
the
2ld.
That
seems
like
it's
like
largely,
would
be
probably
livable.
So
I'm
a
little
concerned
by
this
discussion
that
I'm
seeing
and
then
chat
about
whether
dso
actually
works,
but
perhaps
we
could
actually
investigate
that
problem
in
some
way.
A
Okay,
victor.
A
B
Go
ahead
right,
so
I
think
to
eckers
point.
I
think
paul
was
actually
assuming
that
there
are
some
further
labels
in
the
domain
name
that
you
may
not
want
to
disclose
to
dot
com.
Indeed,
the
second
level
is
most
of
the
sensitive
data,
but
not
always
all
of
it.
B
So
sometimes
the
specific
subdomain
is
is
sensitive
and
relevant.
So
to
that
extent,
dot
com
might
still
gain
some
additional
information
by,
if
that
they
wouldn't
otherwise,
but
ds
indeed,
is
far
more
viable
than
service
be
provided.
We
don't
try
to
encode
keying
information
into
the
ds
record
that
commits
the
name
server
to
having
a
particular
certificate
or
a
particular
public
key.
B
So
that
would
be
the
simplest
model
where
ds
signals.
The
desirability
of
tlsa
lookup,
which
you
otherwise
wouldn't
want
to
do
when
most
domains
don't
have
them
most
name
servers,
don't
have
them
and
you
would
incur
significant
lookup
penalties
and
maybe
even
look
up
failures,
because
some
domains
are
stupid
enough
to
drop
tlsa
queries
or
do
various
other
unfriendly
things.
E
Just
to
clarify,
but
if,
if
if
the
svcp
content
is
basically
pointing
to
a
fully
qualified
domain
name
for
a
for
a
name
server,
then
that
could
be
web
pki
authenticator
too
right
like
it.
It's
not.
B
In
principle,
yes,
the
new
ds
record,
yes,
can
be
a
an
fqdn
and
and
an
implied
authenticated
via
web
pki.
You
know,
I'm
skeptical
whether
the
dns
is
a
place
where
you
can
expect
web
dki
to
work
reliably
in
the
browsers
when
web
pki
fails.
Users
interactively
have
various
other
options
and
various
signaling
to
tell
them
exactly
what
went
wrong.
B
Dns
is
control
plane
and
when
things
break,
they
break
in
mysterious
ways
and
if
I'm
told
to
use
some
ca,
I
don't
trust
you
know
whatever,
but
that
that
I
guess
that's
an
aside.
So
I
don't
know
it's
a
good
model.
Yeah.
E
B
Yes,
pretty
much,
you
just
have
to
make
sure
that
you
don't
try
and
encode
keys
there.
That
would
be
a
disaster.
I
Great,
so
I
first
let
me
just
say
that
the
ds
hack
sounds
promising.
I
I
would,
I
agree
with
ecker
that,
whether
it's
if
we
can
get
the
reasonable,
minimal
semantics
in
there,
the
fact
that
it's
semantic
overload-
and
you
know
as
says
peter-
was
putting
in
the
in
the
chat,
not
not
good
aesthetics.
I've
shipped
uglier
things
I
can
live
with
that
if
it
works,
but
let's
investigate
that
and
see
if
we
can
get
it
going.
I
But
I
also
wanted
to
point
to
this
and
say
that
doesn't
necessarily
mean
that
this
is
going
to
go
from
10
10
years
down
to
to
to
no
years,
and
I
think
we,
what
we've
got
to
be
a
little
bit
practical
about,
is
it's
okay?
I
If
this
takes
a
while,
if
we
had
actually,
I
think
I
wanted
one
before
that,
where
you
you
went
through
the
epb
drafts
and
all
of
that,
but
the
you
know
if
we
have
to
go
and
write
ebp
drafts
if
we
have
to
go
and
persuade
operators
that
they
need
to
update
how
ds
records
are
provisioned
by
clients
in
order
to
allow
this
to
be
provisioned.
That's.
B
I
We've
all
been
involved
in
efforts
that
took
more
than
10
years
at
the
itf
or
longer
rtc
web.
Its
buff
was
in
2011,
and
I've
got
a
a
a
meeting
later
tonight
that
I'm
sharing
having
shared
that
original
above
that's,
okay,
what's
not?
Okay
is
looking
at
that
and
giving
up
because
then
you
never
get
there.
If
we
give
up
saying
we're
we're
never
going
to
get
there,
because
it's
going
to
take
10
years
rather
than
recognizing
for
things
as
core
to
the
the
way
the
internet
works
as
the
dns.
I
Yes,
sometimes
it
does
take
a
long
time,
but
you
still
have
to
start-
and
I
think
my
argument
here
isn't
do
we
do
we
immediately
pick
svcp
or
or
ds,
I
think,
figuring
out,
which
one
is
the
best
one
to
go
with
and
working
that
through
is
fine,
but
I
really
want
to
strongly
urge
the
working
group
that,
even
if
it's
10
years
keep
at
it
because
it
may
take
10
years,
but
it's
still
a
major
upgrade
to
get
this
done
so
that
that's
me
cheering
you
on
from
the
position
of
not
currently
a
dns
operator
or
or
software
provider,
but
a
consumer
of
the
the
results.
E
L
Hi
ben
schwartz-
I
had
to
step
out
so
I
I
missed
some
of
this
conversation.
I
apologize
if
I'm
on
the
wrong
track
here,
so
I'm
obviously
I
I
think
that
the
name
hack
thing
has
some
merit,
or
I
wouldn't
have
contributed
to
writing
it
up.
That
said,
I
am
also
supportive
of
people
who
want
to
to
pursue
a
ds,
hack,
essentially
encoding,
this
kind
of
information.
Somehow
in
a
ds
record,
I
do
want
to
push
back
against
some
of
the
arguments
here.
L
So
I
think
that
that's
a
not
really
a
difference
between
these
approaches,
also
in
terms
of
the
amount
of
software
modification
required.
I
I
think
it's
important
to
note
that
cdns
key
does
not
work
here.
L
You
need
cds,
because
the
what
we're
trying
to
inject
into
the
ds
record
here
is
not
a
hash
of
anything.
It's
some
arbitrary
data.
So
so
we
actually
need
cds.
We
need
the
the
client
to
be
able
to
inject
that,
and
we
also
need
new
new
hash
algorithm
types
for
the
ds
record.
In
order
to
be
able
to
inject
this
arbitrary
non-hash
data
into
the
into
the
ds,
and
that
may
require
software
updates.
Also
c
d,
s
and
c
the
nsk
are
far
from
universally
deployed
today.
L
So
I
think
it's
entirely
conceivable
that
there
are
going
to
be
some
zones
where
the
ds
hack
is
is
just
non-usable
as
non-deployable
in
some
tlds,
for
example,.
E
So
I
think
it's
fair
point
did
especially
your
last
point.
I
agree
with
like
the
the
cds
might
not
be,
might
not
be
as
deployed
as
we
hope
and
it
is
or
not
as
well
supported.
E
I
do
want
to
again
clarify
the
svcp
at
parent.
It's
it's
only.
It's
only
additional
function
is
that
in
bailiwick
name
servers
can
get
protection,
everything
else
we
already
have
without
svcp
and
parent.
So
we
are
talking
about
a
really
small
part
of
the
problem
that
we're
fixing
a
part
of
the
problem
that
I
think
is
unfixable
anyway,
because
an
in
baileywick
name,
server,
you're
going
to
get
a
fully
encrypted
bunch
of
information
and
then
you're
going
to
connect
to
an
ip
address.
E
Of
that
you
know
hidden,
name
server,
name,
and
then
everybody
knows
you're
going
to
connect
there
anyway.
So
there's
very
limited
value
like
I,
I
can
rolled
out
all
of
this
on
noetz.ca,
but
sorry
there's
only
10
domains
there.
So
everybody
already
knows
what
is
being
visited
there
like
I've,
already
lost
my
privacy,
and
so
this
is
like
a
lot
of
changes
for
a
very
small
problem
and,
like
you
know,
a
10-year
project
for
a
very
small
problem
seems
a
bit
like
overkill
to
me.
L
So
I
do
think
that
you
know
one
of
the
things
that
one
of
the
larger
questions
here
really
you
know
for
the
chairs
and
such
is
trying
to
understand
what
kind
of
an
effort
this
is
and,
in
my
view,
deprive
is,
is
a
big
change.
It's
almost
as
big
a
change
as
something
like
dns
sec,
and
so
it
should
be
no
surprise
that
we
have
to
go
in
and
really
think
hard
about
how
the
how
the
delegation
system
works
and
potentially
add
new
records.
So
you
know
we've
added
in
terms
of
new
new
glue
records.
L
You
know
it
started
with
just
ns
and
a
and
then
you
know,
quad
a
was
added.
Ds
was
added,
and
I
think
this
is
another
one
of
those
instances
and
I
think
it's
it's
comparable
in
scale.
So
I'm
comfortable
with
that
and
I
want
to
be
able
to
move
faster,
and
so
I
think
we
need.
We
need
some
kind
of
hack.
L
I
think
it's
even
conceivable
that
we're
going
to
end
up
wanting
both
of
these
hacks
because
they're
deployable
in
different
situations,
because
they
have
different
properties,
I'll
mention
one
more
thing,
which
is
that
if
you
care
about
protecting
the
second
level
domain,
then,
as
eric
has
probably
mentioned,
you
actually
need
your
top
level
domain
to
be
doing
to
be
fully
encrypted.
L
You
need
it
to
be.
Do
it.
If
you
want
fully
authenticated
encryption
to
protect
the
second
level
domain,
the
the
example
in
example.com,
then
you
need
the
tld
to
be
doing
authenticated
adot
and
if
the
and,
if
the
parent
is
doing
authenticated,
adot,
then
then
the
name
hack
becomes
fully
authenticated
encryption,
as
does
adox
generally.
L
H
H
That's
not
really
offering
ds
any
bugs
that
it
flushes
out
are
bugs
that
we
would
be
seeing
if
we
wanted
to
upgrade
algorithms
in
ds
anyway,
and
so
there
is
a
sense
that
if
we
do
this,
we
are
actually
getting
out
ahead
of
other
bugs
and
we
were
prepping
the
dns
sec
infrastructure
for
the
ability
to
migrate
to
a
new
algorithm
speech.
Should
we
need
to.
I
think
that
most
of
those
bugs
have
already
been
flushed
out
with
the
curdle
work.
H
But
I'm
just
you
know
saying
that
if
running
into
these
bugs
in
this
case
would
actually
be
healthy
and
I
don't
think
that's
a
problem.
The
second
thing
that
I
want
to
identify
is
that
I
apologize
that
I'm
still
a
little
bit
fuzzy
on
this.
So
I
agree
with
earlier
speakers
who
have
said
that
this
signal
should
really
only
indicate
a
couple
of
bits
like
hard
fail
or
not,
and
what
particular
mechanisms
we
expect
to
be
available.
H
H
H
A
Okay,
so
a
couple
things,
I'm
gonna,
I'm
gonna
cut
the
mic
line
after
paul
hoffman
and
I'm
just
going
to
you
know.
Maybe
for
for
dkg's
benefit,
I
mean
we've
talked
about
whether
we
want
to
do
per
server
or
zone
authentication
and
encryption
so
that
that
is
an
open
topic
that
needs
to
be
worked
through
next
in
the
queue
is.
H
Eric
bro,
sorry
brian,
just
to
just
to
clarify.
I
understand
that
we've
talked
about
that.
I'm
saying
that
for
the
ds
proposal,
it's
not
clear
to
me
how
it
would
work
like.
I
think
I
see
how
it
would
work
in
the
per
zone
mechanism.
I
don't
necessarily
see
how
it
would
work
for
the
per
server
mechanism,
you'd.
A
M
One
thing
I've
been
wondering
is
whether
we
need
to
like
it
seems
like
there
is
a
bunch
of
jumping
directly
into
implementation
solutions
without
necessarily
writing
down
exactly
what
all
the
requirements
are.
So
I
think
there's
there
are
cases
here
of
of
saying
this
won't
work
because
of
these
requirements.
M
These
won't
work
because
these
requirements,
I
think
that
we
would
a
might
go
a
long
ways
from
actually
writing
down
enough
of
what
some
of
those
requirements
are,
because
I
do
agree
with
ted
here
that
we
should
ideally
be
looking
for
something
that's
a
long-term
solution,
even
if
it
takes
10
years
to
go
there,
and
ideally
one
of
the
requirements
may
be
seeing
if
there's
an
incremental
path
that
allows
us
to
get
the
10-yard
security
properties
we
want,
but
with
incremental
deployment
that
doesn't
break
our
ability
to
get
there
in
the
long
term.
M
One
potential
path
around
this
is
which
is
expired
now,
but
draft
on
t
april
ns2.
It
has
some
similarity
to
eric's
eckers
draft,
but
spent
a
bunch
of
time,
thinking
more
about
some
of
the
deployability
issues
and
how
it
would
work
with
parent
zones
and,
in
particular,
one
of
the
things
that
it
did.
Was
this
svcb
record
equivalent,
which
in
that
case
was
ns2
that
lived
in
the
in
the
parent
zone
was
typically
not
a
service
mode
record.
M
So
it
didn't
actually
contain
the
keys
itself,
but
would
generally
in
the
if
it
was
in
a
a
parent
zone
for
tld
would
be
an
alias
mode
record
so
that
the
actual
keys
could
live
alongside
the
name
server
name,
because
I
think
that's.
M
One
of
the
properties
that
is
going
to
be
important
is
making
sure
that
the
the
key
configure
all
of
the
configuration
on
keys,
as
well
as
all
the
configuration
on
name
servers
lives
along
with
the
name,
server
and
and
the
owner
of
the
name
server,
not
with
the
the
the
zone,
along
with
the
zone.
A
All
right
thanks
eric
and
yeah,
though
the
one
thing
that
you
said
there
that
that
has
been
a
kind
of
a
point
of
frustration
is
his
requirements
discussion.
We
we've
had
a
document
to
try
to
do
that.
We
weren't
getting
any
kind
of
input
on
it,
so
you
know
we're
kind
of
going
in
circles
here,
so
the
working
group's
going
to
have
to
figure
out
what
they
really
want
to
do
in
order
to
identify
what
kinds
of
solutions
they
want.
F
F
The
content
of
the
record
would
be
a
concatenation
of
the
nsr
data
for
the
the
child
zone,
but
that
is
simply
linked
to
the
ns
records
which
are
independent
of
the
the
child
zone
itself.
So
all
of
the
all
of
the
characteristics
are
tied
to
the
the
authority,
authoritative
server
and
by
just
joining
the
r
data
and
then
hashing
it.
You
don't
need
a
new
hash
algorithm.
You
only
need
a
new
ds
algorithm
and
it
would
not
be
tied
to
the
child.
F
The
actual
zone
itself
being
signed.
If
the
absence
of
the
or
this
being
has
a
very
specific
algorithm
would
be
the
exception
to
the
child
needing
to
have
a
dns
key
and
indicating
that
the
child
is
signed,
it
would
be
orthogonal
to
normal
dns.
It
would
simply
be
a
way
of
putting
data
in
the
parent.
F
That
is
something
that
would
be
authoritative
in
the
parent
and
signed,
because
that's
what
ds
records
have
as
a
property,
it's
on
the
parental
side
of
the
zone
cut,
but
it's
the
the
the
it's.
It's
basically
protecting
the
hash
and
signature,
the
ns
records
of
the
delegation
and
those
would
be
directly
tied
to
any
changes
to
the
ns
set.
F
So
the
the
downside
of
that
is
obviously
you
have
to
get
that
into
the
parent
zone,
which
currently
would
be
epp,
but
it
being
an
existing
path,
would
not
require
the
tlds
or
the
registries
to
do
any
work
other
than
permitting
the
new
algorithm.
F
So
I
think
I
hope
that
has
explained
the
that
it's
not
tied
to
the
the
child
zone.
That's
tied
to
the
name,
servers
it's
based
off
of
the
name,
server's
actual
our
data,
the
ns
records
r
data,
so
it
is
based
specifically
off
of
the
names
of
the
name
servers
and
would
be
possible
for
the
registrar
whenever
it
sees
a
change
to
the
ns
records
to
make
those
changes
submit
the
updated
ds
records
and
that
would
allow
authenticated
or
validatable.
F
Validatable
ns
delegations,
which
is
what's
missing
currently
in
dnsec
generally
and
as
a
requirement
for
jumping
over
the
parent
to
child
piece.
A
Okay,
victor.
B
So
I
want
to
say
that
with
the
ns
signaling
clarify
to
not
carry
keys,
I'm
more
sympathetic
to
it.
If
it
just
carries
a
couple
of
bits
of
data
signaling,
a
mechanism,
then
it's
roughly
equivalent
to
ds
modulo
the
fact
that
we
don't
have
parent
signing
of
ns,
and
so,
if
that's
desirable,
then
we
have
to
look
at
the
pros
and
cons
of
ds,
assigned
ns,
isn't
and
what's
exactly
our
threat
model,
and
we
can
look
at
that.
B
I
think
after
the
meeting
and
debate,
the
fine
points,
but
otherwise
the
two
are
both
in
a
much
better
adoption
probability
space
than
service
b,
and
there
are
just
minor
differences
between
ns,
signaling
and
dia
signaling,
mostly
around
the
integrity
of
the
data.
If
your
connection
to
the
parent
is
not
encrypted
and
authenticated,
of
course,
that,
as
ecker
observes
has
brings
its
own
issues
to
light,
and
so
there
we.
A
Are
right
thanks
victor
eric.
C
Hi,
video,
okay,
yeah,
I'm
trying
to
figure
out
like
honestly
what
the
way
forward
is
here.
I
think
I
guess
I
have.
I
think
three
hopefully
very
quick
points.
C
First,
is
I
think
if
we
were
to
do
if
we
were,
if
we
were
in
fact
to
change
the
the
unauthenticated
in
the
way
that
I
indicated
the
email,
I
just
sent
the
process
on
the
microphone
earlier,
then
I
believe
that
that
would
get
us
a
fairly
large
part
of
the
way
there,
and
I
think,
if
you
believe,
paul's
analysis,
which
is
that
the
important
thing
is
is:
is
it
actually
that
covers
many
of
the
cases
because
you'd
cache
the
information,
then
actually
maybe
you'd,
be
quite
far
along?
C
Second,
I
think
that
there
is
some
like
need
to
flush
out
the
threat
model
about
whether
or
not
like.
We
believe
that
the
cash
for
the
for
the
for
the
for
the
for
the
recursive
for
the
authoritative
that
is
being
delegated
to
has
to
itself
be
hot,
because
if
it
doesn't
have
it
because
we've
been
assuming
that
it
was
cold,
which
meant
you
had
to
get
the
information
that's
encrypted.
C
Initially,
not
getting
encryption
then
again
revising
up
to
encryption,
and
I
think
so
I
think
that'd
be
helpful
to
flesh
out,
and
the
third
thing
I
think,
is
you
know
if
we
could
agree
on
the
information
set
that
was
in
this
in
this
value,
then
then,
perhaps
we
could
debate
exactly
how
it
was
propagated,
apparent
separately
or
dug
it.
That's
as
I'm
something
to
figure
out.
C
D
So
super
briefly,
if
the
working
group
goes
towards,
for
this
use
case
goes
towards
ds
peter,
and
I
can
actually
change
the
signal
that
we're
using
to
being
some
sort
of
like
new
record
type
of
ds
and
child.
That
has
exactly
the
same
information
in
the
same
format.
So
that
goes
back
to
the
desire
that
people
have
for
us
to
be
having
things
in
the
same
format.
D
Might
even
fix
the
cds
problem
where
it's
like
cds,
for
which
and
stuff
like
that
is
it
could
be
that
we
just
come
up
with
this
new
child
record.
That
has
just
the
bits
that
we
want
as
described
before,
and
that
gets
copied
into
a
ds
and
the
parent.
So
we're
we're
totally
open
to
that
and
if
that
helps
the
working
group
move
forward
on
both
drafts.
All
the
better
thanks.
A
B
The
the
ds
record
in
the
child
is
unnecessary.
Cds,
plus
a
new
kind
of
dns
key
algorithm,
as
suggested
by
brian
dickson,
would
do
the
job,
so
even
cdnskey
would
work,
provided
that
the
data
that's
published
in
the
parent
were,
in
fact
a
hash
that
would
do
the
right
signaling.
It
wouldn't
need
to
be
in
the
clear.
B
The
algorithm
would
indicate
everything
you
need
to
know
and
the
hash
would
just
authenticate
the
name.
Server
names,
making
sure
that
they're
not
tampered
with.
So
there
are
some
there's
lots.
B
Right
so
anyway,
there
are
there's,
there's
a
bunch
of
room
in
the
design
space
there
there's
more
than
one
thing
we
can
play
with.
I
think
service
b
is
the
least
likely
to
get
there
in
a
reasonable
manner,
but
the
other
options
have
some
some
credibility.
A
All
right,
thanks
victor,
so
we
are
over
time
tim
and
I
are
going
to
there's
there's
a
bunch
of
topics
that
that
are
going
to
need
some.
Some
engaged
work
group
discussions,
so
we're
gonna
go
through
the
the
various
points
have
been
raised
and
try
and
start
kicking
off
discussions
on
the
mailing
list
so
that
we
can
kind
of
flesh
these
out.
If
people
have
particular
topics,
they
want
to
make
sure
that
we
cover.
A
Please
let
us
know-
and
if
you
have
you
know,
proposals
like
brian
ticks
and
that
or
similar
type
approaches
that
you
would
like
to
work
with
to
consider
plea.
A
Please
consider
documenting
those
and
and
thinking
about
what
what's
the
as
eric
as
acura
was
saying
things
like:
what's
the
threats
that
you're
you're
addressing
and
what
are
the
implications
on
on
the
operational
side
of
the
world
that
would
that
would
help
us
keep
things
moving
in
the
working
group
with
that
we'd
like
to
thank
you
for
participating
in
in
deep
private
ietf
111,
and
we
will
see
you
on
the
mailing
list.
Thank
you
all.