►
From YouTube: IETF112-DNSOP-20211111-1600
Description
DNSOP meeting session at IETF112
2021/11/11 1600
https://datatracker.ietf.org/meeting/112/proceedings/
C
D
All
right
looks
like
it's
one
after
the
hour,
so
we'll
so
we'll
kick
this
off.
My
name
is
tim
benno.
You
can
kick
off
the
next
slide.
Benno
is
running.
The
slides
suzanne
is
going
to
keep
us
all
on
track
timewise.
I
hope
she
does
a
great
job
on
that.
So
we're
the
chairs
warren
is
our
overlord.
So
now
that
he's
here
we
can
start
and
paul
hoffman's
taking
minutes.
D
I
did
put
the
agenda
in
the
ether
pad,
even
though
he
doesn't
use
it,
but
if
folks
want
to
actually
drop
comments
in
there
about
things,
they
said
to
make
sure
it's
captured
correctly.
Please
you
know
you're
free
to
do
so
and
we
can
integrate
all
that.
That's
what
that's
the
fancy
stuff
we
do
so
next
slide,
sir.
D
This
is
the
note
well
about
paying
attention
to
ift,
ietf
policies,
etc,
etc.
You
by
this
point
in
the
week
most
people
are
pretty
familiar
with
it.
So
please
you
know,
but
if
you're
not,
please
take
a
read
on
it
and
next
slide.
We
also
have
a
new
slide.
This
thanks
to
wes
on
the
code
of
conduct
guidelines,
some
7154.
D
We
feel
these
are
pretty
straightforward
and
please
reach
out
to
the
chairs.
If
you
you
know,
feel
you
know,
things
aren't
being
addressed
in
the
way
you
feel
it's
pro
up,
you
know
should
be
or
or
warren
right
we're
here
for
you,
so
don't
don't
feel
afraid
to
like
reach
out
and
sort
of.
You
know
express
opinions
about
this
thanks.
We
can
go
to
the
next
slide
now,
so
so
some
notes
from
the
chairs
just
a
quick
heads
up
about
the
nom
con
feedback
is
still
open.
D
So
please
go
in
there
and
make
your
opinions
known.
They
will
welcome
it.
We
will
welcome
it.
It's
a
good
thing,
there's
some
folks
in
dns
pretty
regularly
that
are
running
for
a
few
positions.
So
you
know
we
always
like
that
on
another
note,
kim
davies
has
a
document
about
moving
some
stuff
in
in
int
to
historic
and
he's.
D
We
should
be
in
good
shape,
but
thanks
kim
for
working
on
that,
he
also
promised
to
publish
the
zone
after
he's
got
all
this
cleaned
up.
So
I
like
that,
I
don't
know
why,
but
I
like
that.
You
know
that
we
haven't
actually
adopted
work
in
a
while,
and
we've
talked
about
this
and
warren's
talked
about
this
with
us
and
we're.
You
know
we
had
some
ideas,
but
then
it
was
like.
D
Maybe
we
should
just
have
a
poll
and
have
the
working
group
sort
of
chime
in
on
this,
because
you
know
everybody
loves
a
good
poll
right,
so
we're
putting
something
together,
probably
in
the
next
week
or
so,
and
we've
had
we've
had
good
success
with
our
focus
in
terms
you
know
feedback
from
the
authors
as
well
as
as
other
folks,
and
so
we're
going
to
continue
doing
that
on.
You
know
just
one
or
two
documents
and
then
you
know
do
an
hour.
One
or
two
documents
really
get
people
sort
of
thinking
about
that.
D
We
will
reach
out
to
folks,
but
if
you
want
to
sort
of
push
yourself
to
the
head
of
the
list,
you
know
a
good,
a
good
email
to
us
kind
of
move
us
along.
I
think
so.
Thanks
next
slide,
which-
and
this
is
just
some-
you
know-
warren's
like
let's
put
the
pretty
picture
back
in
there.
So
we
put
the
pretty
picture
from
last
time
about
the
active
working
group
documents
and
what
people
feel
is
important
or
not
important.
D
Two
of
the
documents
that
were
really
suggested
by
the
folks
were
the
unisex
bootstrapping
and
the
united
states,
automation,
which
are
both
going
to
be
discussed,
and
we
both
think
are
very
you
know
we
would
love
to
see
the
working
group
sort
of
coalesce
around
some
of
that,
and
also
on
the
some
of
the
new
group
beings.
New
work
being
suggested
suggested
is
the
8109
biz,
which
we
I
believe
we
felt
like.
We
wanted
to
adopt
at
one
point
and
we
sort
of
lost
it
in
the
shuffle,
so
we're
guilty.
D
What
else
are
we
talking
about
here?
So
some
document
updates
we've
got
two
documents
in
the
rfc
status.
7816
biz
is
it's
in
the
editor
thing,
but
they've
assigned
a
number.
I
consider
it
done
so
that's
really
great
and
thanks
to
the
authors
for
sort
of
getting
all
the
work
involved
on
that,
thanks
and
and
on
the
next
slide.
D
We've
got
three
other
documents
that
one
in
the
editor
queue
my
consideration
and
then
two
that
are
going
through
the
ihd
evaluation
and
they
both
are
getting
lots
of
good
comments
and
feedback
and
we're
those
are
being
moved
along
as
well.
In
a
very
you
know,
process
sort
of
way,
so
those
those
things
are
happening
and
that's
great
thanks
for
the
authors
on
sort
of
following
up
on
a
lot
of
those
and
also
almost
done.
We
feel
when
we
were
sort
of
discussing
this
this
week.
Blue
is
not
optional.
D
I
think
there's
one
or
two
outstanding,
there's
like
one
outstanding
item
and
once
we
sort
of
clear
some
of
that
up,
I
think
we're
ready
for
that
one
as
well
as
avoid
fragmentation.
Some
of
I
think,
there's
some
editorial
work.
We
want
to
help
on
sort
of
clearing
some
of
the
fragmentation,
bits
up
and
also
catalog
zones,
which
will
and
we'll
talk
about
tomorrow.
Due
to
his
timing,
phil's
feels
is
basically
done
as
well.
They've
had
some
good
hackathon
results
as
well.
D
Also
the
feedback
from
the
interim
on
dns
error,
reporting
rory's,
got
some
great
feedback
and
he's
working
to
integrate
all
that
and
we've
our
our
view
of
it
is
it's
it's
in
really
good
shape
and
ready
to
go.
So
that
was
really
great.
So
I
know
people
thought
that
was
kind
of
a
strange
interim
item,
but
we
got
a
lot
of
operational
stuff
right
in
there
and
that
was
pretty
great,
the
rr
serial
document.
I
I
know
hugo
is
working
on
some
implementation
stuff.
I
and
I
see
him
in
the
audience.
D
D
5933
33
biz
was
on
hold,
we
chatted
it
out
and
what
we
we
came
up
with
and
we'll
see
what
happens
during
the
working
group
is
changing
it
to
informational
and
then
we'll
proceed
with
a
working
group
last
call
probably
starting
this
weekend,
and
you
know
we
expect
all
you
know.
We
expect
everything
from
that.
So,
but
thanks
to
the
authors
for
being
patient-
and
I
do
think
you
know-
paul's
work
on
sort
of
cleaning
up
some
of
the
the
ionos
stuff
actually
is
really
super
helpful
in
this
case.
D
So
thank
you
paul
next
slide
and,
of
course
our
stuff
is
in
the
data
tracker,
we're
shortening
our
list
and
we
feel
that,
as
we
sort
of
get
get
the
list
down
a
little
bit
more,
that
we'll
start
adopting
stuff
and
we'll
work,
you
know
we've
been
discussing
numbers.
You
know
like
how
you
know
how
many
exact
drafts
can
we
do,
but
I
think
we're
taking
it
on
a
you
know,
we'll
we'll
take
guidance
from
the
working
group
and
from
warren
on
the
best
way
to
do
that.
D
D
As
you
see
it's
more
updates
or
documents
that
people
have
sort
of
wanted
to
sort
of
talk
about
whether
or
not
we
adopt
it
is
sort
of
you
know,
that's
always
a
bigger
discussion
right,
but
we
call
it
new
business
because
it's
it's
not
sort
of
adopted
work.
So
I
apologize.
I
think
the
wording
is
probably
bad.
There.
D
Deck
and
we're
hope
you
know,
we
believe
and
he's
going
to
provide
better
motivation,
upfront
about
what
he's
trying
to
solve
here,
and
I
think
you
know
hopefully
a
sort
of
streamlined
discussion,
so
we
so
there
can
be
comments
because
we
know
we
were
even
with
20
minutes
or
so
we
kind
of
ran
out
of
time
and
deprived,
so
we're
hoping
to
sort
of
help
brian
along
by
you
know,
moving
that
shortening
that
up
thanks
and
I
think
what
what
else
is
going
on.
I
think
that's
it.
D
So
that's
that's
tomorrow's
business,
so
that's
kind
of
ours.
If
anybody
has
sort
of
agenda
bashing
they
like
or
don't
like
what
we're
doing.
Please
speak
up,
you
know
or
adopting
new
work,
not
adopting
new
work.
What
we're
not
focusing
on!
We
really
would
like
to
hear
that.
I
know
you
know
when
we
talked
yesterday,
the
four
of
us.
We
were
all
in
agreement
that
we'd
like
to
hear
from
the
working
group.
You
know
what
what
can
be
more
efficient,
it's
a
good
way
to
put
it.
B
D
F
F
F
It
is
so
close
to
to
being
ready
to
to
serve
so
really
we're
down
to
like
one
point,
which
is
what
we'll
discuss
today,
but
just
as
a
reminder,
sort
of
the
current
you
know,
the
point
of
the
draft
is
to
say
things
like
use.
Nsec.
If
you
can,
you
should.
You
know
ideally
use
zero
as
a
iterations
count,
and
you
know
use
assault
only
if
you're
going
to
change
it-
and
this
is
the
current
draft
table
of
you-
know
what
validators
and
stuff
should
do.
F
So
now
there's
12
000
and
you
can
see
the
fractions
of
the
number
of
zones
that
are
at
various
different
values
of
iteration
counts.
On
the
left-hand
side,
I
did
put
you
know
the
five
nines
in
bold.
So
I
mean
the
good
news
is
for
500
we're
we're
at
five
nines
under
that.
But
but
even
then
you
can
see
that
there
is
a
decent
fall
off
and
and
even
ninety
nine
percent
of
enzo
iii
zones
in
the
world
today
are
under
20
or
under
or
equal
to
20..
F
There
is
a
break
at
zero
and
one-
and
I
think
zero
and
one
is,
is
one
of
the
most
confusing
points
I
didn't
put
one
on
the
slide,
but
there's
a
decent
jump
from
zero
to
one,
and
you
know,
like
most
people,
think
oh
well,
I
want
one
iteration.
Well,
no,
it's
for
one
iteration.
You
actually
have
to
set
a
value
of
zero
and
I
think
that's
confused
people.
F
So
the
remaining
outstanding
question
is:
what
should
we
set
as
the
lower
limit
for
for
validators
and
zone
owners
to
actually
use
the
previous
draft
had
150?
The
current
draft
has
a
hundred
and
then,
as
a
mail
message
I
put
on
the
on
the
dinosaurs.
The
other
day
was
trying
to
see
discussion
around
okay.
Well,
what
could
we
do?
Recently?
Four
implementations,
you
know
have
said
they've
in
their
announcement
text,
have
said
that
you
know
they're
capping
it
at
150..
F
F
Excuse
me
yep
no
problem,
so
this
is
the
final
slide,
and
so
this
is
what
I
think
if
I
summarize
the
conversation
in
the
past
week
for
for
dns
up
on
the
mailing
list,
where
we
ended
up.
So
the
important
thing
to
note
is
one
most
dns
participants
really
want
zero.
It's
just
a
question
of
whether
we
can
state
that
or
not
so
I
think
you
know
I
was
out
walking
around
the
other
day,
and
I
said
you
know
the
right
way
to
handle.
F
This
was
with
should
mace
musts
and
that
type
of
stuff,
and
then
multiple
people
actually
started
saying
the
same
thing
on
the
on
the
mailing
list,
so
that
actually
works
well.
So
I
think
this
is
what
we
we
might
want
to
say,
and
so
what
I
really
want
to
hear
from
today
is
people
that
disagree
with
anything
on
this
slide.
So
to
read
it
out,
you
know
you
should
use
validators
should
treat
iterations
greater
than
zero
as
insecure,
and
that
is
a
bold
change
from
where
we
are
right.
F
You
sh,
you
may
treat
you
know
iterations
of
one
as
you
actually
may
that's.
That
second
line
is
wrong.
It
should
be.
You
may
treat
iterations
of
one
and
you
may
want
to
validate
it
and
and
don't
treat
it
as
insecure,
because
because
of
that,
one
number
that
is
out
and
so
prevalent
that
only
seven
percent
of
the
the
existing
zones
out
there
are
using
zero.
F
You
must
treat
iterations
greater
than
100
as
insecure,
and
you
may
treat
iterations
greater
than
500
is
serve
fail
and
remember.
That
was
something
that
we
decided
as
an
optional
thing.
People
don't
have
to
do
it;
they
can
just
continue
treating
things
as
insecure
and
some
implementations
you
know
may
want
to
return
serve
fail
if
they
want
to
be
a
little
more
aggressive
and
really
yelling
at
people
that
don't
do
that
and
then
you
know
for
the
zone
owner
side
of
things.
F
You
know
whether,
whether
you're
an
operator
that's
managing
a
zone
on
behalf
of
somebody
else
or
whether
you're
actually
controlling
the
iterations
yourself.
You
should
use
an
iterations
count
of
0
and
you
must
use
an
iterations
count
of
less
than
or
equal
to
100.
You
know
which
again
matches
the
must
up
here,
so
these
two
values
should
always
stay
in
lock
step.
F
G
G
F
Well,
I
I
hit
I
that
that's
a
good
question,
so
I
mean
I
should
we
should
hear
from
other
people
my
my
gut
reaction
on
splitting.
What
type
of
resolver
it
is
you
know,
leads
to
problems,
and
you
know
camels
and
things
like
that
of
we
should
just
have
everything.
Do
the
same.
The
reason
for
doing
insecure
versus
you
know
serve
fail
essentially
or
failing
to
to
resolve
it
all.
Is
it
actually
matches
what
insect
three
does
today?
F
So
the
insect
three
draft
says:
if
you're,
using
something
greater
than
4096,
I
mean
the
values
are
just
huge.
You
know
just
treat
it
as
insecure,
so
there's
precedence
for,
for
that
is
really
what
it
came
down
to
and
you're
still
trying
to
do
the
end
goal
of
of
helping
actually
do
a
resolution,
even
if
you
can't
prove
that
I
remember
this
is
for
proof
of
non-existence
right,
so
it
it's,
it's
you'd
still
return
an
nx
domain.
You
just
wouldn't
you
know,
be
able
to
verify
it
right.
E
E
Every
answer
in
the
zone
can
is
then
subject
to
man
in
the
middle
attack.
If
you
get
an
answer
with
a
valid
signature,
sure
you
can
trust
it,
but
you
might
have
gotten
an
unsigned
answer
and
trusted
that
instead,
so
it's
a
very
marginally
secure
zone
at
that
point,
essentially
no
answer
is
secure.
If
a
tld
were
to
go,
you
know
above
the
iteration
limit,
then
all
of
its
child
zones
become
completely
insecure,
so
this
is
pretty
drastic.
E
E
So
it
would
be
ideally
nice
to
keep
that
range
small,
maybe
even
not
have
insecure
fall
back,
but
of
course,
in
practice,
if
you
know
on
the
ground,
not
enough
domains
get
the
message
and
some
people
you
know
are
happy
enough
to
operate
in
this
gray
zone
where
they
think
they're
secure
but
they're
not
rather
than
serve
fail.
We
can
you
know,
let
them
be
that
way.
So
I
don't
know
what
the
answer
is,
but
just
for
clarity,
insecure
is
very
insecure.
You,
you
have
no
security
once
you're
over
the
limits.
F
H
H
In
my
view,
either
a
zone
is
secure
or
it's
not
secure
and
I
think
it's
better
to
return
surf
fail
if
the
number
of
iterations
is
too
high
and
also
the
point
that
victor
was
just
making
about
the
potential
for
denial
of
the
service
attacks
of
spoofing
attacks.
If
the
zone
is
accidentally
mapped
as
insecure
and
it's
not
quite
there.
So
I
I
would
prefer
not
to
do
this
insecure
middle
ground
and
just
take
a
very
big
view
of
it.
Either
the
zone
is
secure
or
it's
not
there's
nothing
in
between.
F
I
So
that
as
a
starting
point,
because
the
problem
now,
if
you
have
a
resolver
that
wants
to
do
the
kind
of
hard
cut,
it
cannot
comply
to
this
graph
because
the
current
graph,
the
must
is
at
100
so
between
100
and
150
bears
or
500.
In
that
case,
there
is
a
behavior
that
is
currently
not
possible
if
you
want
to
just
have
really
hard
cut.
F
Thanks,
you
actually
bring
up
another
point
that
I
meant
to
mention
which
I
haven't,
which
is
that
there
was
discussion
on
the
list
that
we
should
produce
this
rfc
with
the
goal,
with
the
goal
being
zero.
I
think
there's
general
consensus
around
that
and
allow
validators
to
slowly
achieve
that
based
on
measurements
by
you
know,
victor
or
others
in
terms
of
what
actually
happens
in
the
world.
So
you
know
functionally
be
non-compliant
to
the
rfc
when
it
comes
out.
F
F
J
F
K
So
I
think
that
we
should
be
very
strict
for
zoners
and
we
can
be
much
more
relaxed
in
the
specification
for
the
validators,
because
we
don't
even
specify
the
value
for
validators.
It
can
be
just
you
know,
think
about
the
value
before
you
release
your
software
and
do
your
measurements,
because
for
validators
it's
basically
impossible
to
prescribe
the
value,
because
it's
changing
all
the
time,
but
for
zone
owners
we
can
specify
what
they
has
to
do
to
be
interoperable
in
the
long
term.
In
my
view,
we
don't
need
to
like
refine
details.
F
K
Yeah,
I'm
afraid
it's.
It
is
same
same
story
because
right
now
we
cannot
do
say,
fell
above
certain
point,
but
it
will
change
over
time.
So
again,
I
would
just
describe
for
validators
what
needs
to
be
considered
when
the
validator
vendor
is
setting
the
thresholds,
but
we,
I
don't
think
we
have
to
specify
the
values
in
the
draft
actually
because
we
describe
the
logic
they
well.
If
you
you
know
the
current
prevalence
of
iteration
values,
you
will
see
distribution
and
then
you
know
make
up
your
mind,
and
these
are
the
consequences
of
your
decisions.
K
F
B
Okay,
thank
you.
Thank
you,
wes
yeah,
so
indeed
yeah,
no
speaking
now
as
a
as
an
implementer,
I
I
agree
with
better,
also
for
for
well
and
and
also
I
want
to
know
that
the
surveil
behavior
is
new.
The
other
are
caps
caps
on
iterations
the
serve
file
is
new
and
I
think
yeah
we
will
follow
the
drafts
and
the
rfc,
and
also,
of
course,
thank
you
victor
for
measuring
the
current
state
of
the
number
of
insect
iterations
being
used
by
operators.
B
L
We
are
working
on
a
controller
software
that
can
orchestrate
the
whole
multisigner
setup,
joining
leaving
algorithm,
rollo
or
key
rollovers,
and
one
of
the
missing
pieces
for
this
to
be
really
automated
is
that
the
parent
zone
would
have
to
support
season,
and
this
is
actually
what
we
have
been
doing
in
the
swedish
internet
foundation.
We
are
implementing
season
scanning.
L
Let's
see
yes,
okay,
yes,
and
so
this
was
added
by
schumann,
but
I
think
I
can
speak
to
this
too.
Okay,
we,
if
you're
following
the
the
icam
process,
we
there
is
a
dns
day,
basically
at
the
the
ik
meetings,
and
there
is
a
small
on
the
dns
day.
There
is
a
dns
automation
panel
that
steve
crocker
has
been
running
together
with
schumann
and
there's
a
lot
of
work
around
the
dnsec
automation.
L
M
L
Yes,
before
I
come
to
this,
what
I
do
wanted
to
say
that
there
that
we
have
been
working
on
a
way
to
so
one
of
the
the
special
use
cases
of
this
multisigner
is
to
take
a
domain
and
move
it
from
one
signing.
Dns
provide
a
dns
provider
to
another
signing
dns
provider
and
one
of
the
requirements
is
that
bose
have
the
same
algorithm
and
but-
and
this
is
of
course
doable
for
large
organizations
because
then
you
can
pay
for
it,
and
you
can,
you
know,
make
requirements
to
your
service
providers.
L
But
if
you
are
your
person,
but
it's
your
personal
domain,
you
probably
can't
do
that
and
registrars
or
other
you
know.
Hosting
providers
are
not
very
open
to
making
changes
to
their
environment
for
just
your
domain.
So
what
we
in
practice
would
like
to
do
is
to
make
to
be
able
to
move
a
domain
from
one
signer
to
another
sinai,
but
they
have
different
algorithms
for
signing,
and
this
will
need
some
additional
work
and
we
will
have
to
go
back
to
how
dns
egg
is
validated
actually
and
see.
L
What
we
can
do
there
to.
You
know
make
this
work,
and
so
this
will
be
future
work
after
we
have
this,
the
first
one
finished,
and
yes
so,
and
we
would
like
to
ask
the
working
group
for
adoption
for
this
work
so
that
we
yes
get
this
documented
and
defined
how
to
move
your
domains
around
and
how
to
run
them
in
this
more
resilient
setup
of
multisign.
B
N
Okay,
great
sorry,
I
had
to
click
an
extra
button,
so
I
just
wanted
to
say
that
working
on
this
draft
has
helped
us
to
talk
with
implementers
and
manage
dns
providers
alike
to
implement
the
key
management
interfaces
that
allow
multi-signer
operation
to
work
smoothly,
and
that,
in
turn,
helps
us
solve
the
inter-provider
handoff
smoothly
as
well.
So
I
think
we
think
there's
good
benefit
to
the
operational
dns
community
generally,
so
we
would
encourage
the
working
group
to
consider
adopting
this
drug.
O
P
M
M
I
don't
remember
exactly
what
the
circumstance
was,
maybe
schumann
or
if
you
know,
but
wasn't
there
some
requirement
that
you
have
to
have
signatures.
Oh
yeah,
I
remember.
If
you
have
two
providers,
they
have
to
sign
the
dnsk
record,
set
on
each
side
with
their
respective
keys,
and
if
one
provider
decides
to
to
change
the
algorithm,
then
the
the
other
doesn't
use
the
new
algorithm
and
can't
sign
the
dns
key
records
appropriately,
and
I
think
that
requirement
comes
from
some
dns
rfc.
M
I
Golf
weber,
would
you
okay?
So
there
was
a
time
when
there
was
dns
x
that
cared
for
protocol
and
dns
up
that
cared
for
operations
and
then
dns
up
started
to
do
well.
We
would
do
it
all
together,
but
I
think
that
this
is
exactly
the
work
that
belongs
in
dns
up,
and
I
very
much
would
encourage
to
work
to
take
that
work
up
and
adopt
the
crowd.
L
Thank
you
yes
to
this
point.
I
can
say
that,
yes,
we
are
doing
this.
We
implementing
this
controller
software
right
now
and
there
is
actually
a
quite
complicated
state
machine
in
it
to
make
this
work,
and
what
I
can
say
is
that
it
would
be
much
easier
to
implement
like
a
peer-to-peer
version
of
it
in
a
name
server,
because
the
name
server
already
the
signer
already
had
the
state
of
all
the
keys,
but
I
mean
that
is
obviously
in
a
future
development
that
we
could
talk
after.
B
Okay,
I
think,
okay,
that
was
the
queue
any
other
questions.
We
still
have
time
for
one,
no
okay,
thank
you!
Thank
you,
ulrich
and
schumann.
So
yeah
concluding,
I
think,
you're
well
on
your
way
in
writing
the
document
and
and
for
your
own
timeline.
What
do
you
think
so?
Well,
they're
both
operational
you're
implementing
stuff,
but
also
for
the
draft?
How
much
work
do
you
expect.
O
O
B
N
Q
Q
So
just
very
briefly,
what
is
domain
verification?
What
is
your
verification?
So
essentially,
as
folks
probably
know,
many
providers
on
the
internet
need
users
to
prove
that
they
have
some
kind
of
kind
of
control
over
a
domain
and
service
providers
ask
users
to
put
a
dns
record
in
their
zone.
That
proves
that
they're,
the
ones
who
control
their
domain
and
a
good
example.
Q
It
is
let's
encrypt
with
the
dns-01
challenge
and
you
put
the
you
put
the
challenge
text
record
and
then,
once
it's
verified
by,
let's
encrypt,
you
get
issued
a
cert
and
I
won't
go
into
the
whole
draft
because
we
talked
about
it
last
time,
but
just
as
a
refresher,
the
draft
is
fairly
simple.
It
gives
an
overview
of
existing
techniques,
talks
about
text
records
and
cname,
which
are
the
two
ways
in
which
we
saw
that
service
providers
right
now
are
doing
dns
based
domain
verification
and
also
we
give
recommendations.
Q
We
suggest
the
use
of
dnsec
to
prevent
spoofing,
and
I
put
in
a
link
to
the
111
presentation
over
here
and
we've
gotten
a
bunch
of
feedback
on
the
mailing
list
and
the
mic,
and
there
were
some
security
issues
that
were
talked
about
at
the
mic,
especially
last
time
and
we've
been
using
github
to
capture
all
of
that
and
I
think
yeah.
We
know
that
detailed
security
analysis
is
needed,
but
I
think
that
would
really
like
benefit
from
the
involvement
of
the
working
group
and
that's
basically
it
so
yeah.
B
R
B
N
O
Thank
you.
I
wonder,
I'm
just
wondering
other
than
working
more
on
that
security
analysis.
What
would
be
the
next?
Yes
and
I
I
see
it
hasn't,
been
updated
since
the
previous
yeah,
so
I
was
just
wondering
like
what
are
the
reasons
how
to
phrase
this
like
what
has
changed
in
order
like
to
support
adoption
better
this
time,
if
that
makes
sense,.
Q
Q
B
Yeah,
thank
you.
Thank
you,
shiva,
so
joey.
So
indeed
in
in
the
indiana
shop,
we
we
go
to
the
mic
indeed,
so
it's
it's
it's
support
in
the
working
group.
Then
we
take
it
the
call
for
adoption
to
the
mailing
list
and
in
the
on
the
mailing
list,
there's
there's
the
formal
call
of
dot
call
for
adoption.
B
This
is
also
a
result
of
the
well
previous
discussions
of
the
working
group
and
not
about
not
only
the
dinosaur
chairs
and
the
ad,
but
also
the
working
group
participants
that
we
need
to
focus
our
work.
So
it's
not
it's.
It's
not
a
qualitative
statement
not
to
adopt
or
postpone
it's
really
a
managing
workload,
and
we
we
did
hear
you.
We
did
hear
the
different
participants
about
the
importance
of
this
work,
and
maybe
I
should
give
the
word
to
tim,
maybe
and
brett.
You
are
still
in
queue
so
but.
R
B
D
Cool
speaking
as
an
operator,
I
think
this
is
like
way
important
and
I
you
know,
as
I've
sort
of
have
sort
of
hammered
on
schumann
siobhan.
They
should
just
keep
hammering
on
this
because
there's
this
is
good
stuff
so
and
we'll
figure
out
the
whole
chair,
we'll
figure
out
the
whole
adoption
thing
right.
So
don't
stop.
D
B
B
N
Yeah,
so
just
answering
tim,
I
think
that's
fine.
We
can
keep
plugging
it
plugging
away
at
the
draft
shivan
and
I
but
we're
hoping
if
it
was
adopted
early
we
we
would.
We
could
recruit
more
collaborators
to
help
us
with
the
you
know,
security,
analysis
and
more
extensive
analysis
of
these
schemes,
so
that
was,
in
our
opinion,
one
of
the
benefits
of
earlier
adoption.
D
A
B
Q
Q
M
Yeah,
I
don't
know
exactly:
who
is
what
kind
of
parties
are
involved
in
the
bms
apps
group?
I
mean
obviously
name
server,
implemented,
resolver
operators
and
art
operators
and
all
these
people,
and
regarding
this
draft
I
wonder
who
the
address
he
is
because,
for
example,
in
the
case
of
certificate
issuance,
I
guess
that
would
be
something
that
cas
would
have
to
expect
from
the
customers.
So,
for
example,
that's
encrypt
would
have
to
say
you
should
put
this
in
that
record
into
the
dns.
M
Q
Yeah,
I
think
it
is
definitely
like
service
providers
for
sure,
and
I
think
the
idea
is
that
a
lot
of
folks
have
have
come
up
with
like
ways
of
doing
domain
verification
that
they
kind
of
just.
We
talked
about
this
in
the
draft
a
little
bit
like
some
of
them
extremely
well
formatted,
and
some
of
them
are
just
you
know
just
here
here,
put
a
string
and
they
don't
really
talk
about
any
requirements
around
that
so,
and
we
think
this
happened
because
of
the
lack
of
guidance.
Q
N
Again,
so
just
to
follow
up
siobhan,
I
think
peter
to
your
point
yeah.
So
I
I
I
think
our
expectation
is
once
we
develop
this
draft
a
little
bit
more.
We
will
have
to
do
outreach
to
application
and
service
provider
communities
right
to
kind
of
clue
them
in
to
you
know
what,
if
any
recommendations
come
out
of
this
draft
to
see
if
we
can
persuade
them
to
adopt
those
recommendations,
so
I
think
that's.
We
expected
that
to
be
part
of
the
process.
B
Thank
you.
Thank
you
both
any
final
words.
No,
so
thank
you.
Thank
you,
shivan
and
schumann
for
pushing
this
work,
and
definitely
the
chairs
will
have
a
follow-up
with
you
there
and
well
paul
routers
and
also
brett
brett
carr
volunteered
to
help
that's
good,
and
we
will
definitely
make
progress
in
the
next
month.
Yeah.
B
T
T
That
was
one
of
the
deficiencies
of
the
draft
that
we're
superseding.
With
this
that's
mentioned
at
the
bottom
draft,
ready
dns,
hop
error.
Page
we've
received
a
bunch
of
comments.
I
saw
a
bunch
came
in
late
yesterday,
my
time
from
peter,
which
was
was
pretty
cool
and
I'll
talk
about
a
couple
of
those
things
as
we
go
through,
so
the
design
handles
a
commercial
filter
and
an
it
or
parental
operated,
or
you
know,
whoever
is
operating
another
layer
of
filtering
to
filter
whatever
that
they
additionally
want
to
do
so.
T
The
commercial
dns
filter
might
filter
malware,
might
be
a
government
mandated
filter
to
filter
child
porn
sites
and
then
the
it
operated
or
parental
operated.
Dns
filter
might
do
some
other
stuff
all
eventually
going
to
the
client.
So
the
protocol
allows
these
these
filters
and
these
blocks
to
be
propagated
down.
T
Should
the
one
the
the
filter
in
the
middle
decide
that
it
wants
to
propagate
that
down
in
a
lot
of
situations
with
parental
filtering
and
with
it
filtering
the
the
intermediary
needs
to
be
involved
to
resolve
problems
with
filtering
done
by
the
upstream,
because
they
own
the
contract.
They
have
the
the
phone
number
to
call
to
resolve
those
issues
so,
but
that
it
turns
into
something
the
protocol
handles
either
way,
but
there's
operational
concerns
and
issues
there.
T
The
packet
format
is
the
usual,
and
then
this
slide
I'll
update
for
the
meeting
materials.
I
noticed
this
morning
that
there's
a
couple
things
missing
in
it,
but
the
json
that
comes
down
is
is
purposefully
as
tight
as
I
could
figure
out
how
to
make
it.
So
the
the
c
colon
is
intended
to
have
anything
that
the
filter
service
wants
to
include
to
help
it
identify
this
filtered
event.
So
this
could
be
a
time
stamp
like
shown
here.
T
It
could
be
any
unique
value,
a
sequence
number
that
it
wants
to
keep
track
of
for
each
time
it
does
a
filter
could
be
anything
that
it
likes
doesn't
matter.
The
protocol
itself
doesn't
care.
This
is
something
that
is
generated
and
a
responsibility
of
the
the
dns
filter
itself.
The
d
colon
is
the
domain
of
the
doh
dot
server
that
the
user
is
connected
to
this
is
to
detect
if
the
doh
dot
server
is
just
blindly
proxying
and
forwarding
this
traffic
or
is
actually
aware
of
this
extension.
T
We
have
a
discussion
point
later
to
talk
about
what
language
that's
in,
which
is
a
thing
that
causes
me
a
little
bit
of
grief.
Only
the
d
and
the
j
are
mandatory,
as
specified
currently
in
the
draft.
Peter
had
some
comments
on
that
o
is
a
free
form
organization
that
is
doing
the
filtering
and
r
points
off
to
a
justification
for
why
this
filtering
happens
so
might
be
an
employee
contract
for
why
a
job
site
or
a
guns
and
ammo
site
or
whatever,
was
being
filtered
or
point
to
a
country
specification.
T
A
country
requirement
that
child
porn
be
filtered.
If
that
was
the
reason
that
it
was
filtered
so
then,
on
the
client,
it
constructs
the
url
by
prefixing
https
to
the
d
colon
value
and
appending
the
query
parameters
for
c
what
I
missed
here
on
this
slide,
and
I
will
update
in
the
meeting
material.
Is
it
also
appends
the
don't
the
the
domain
queried
from
the
dns
query
and
the
the
record
type
that
was
queried
like
a
or
quad
a
or
whatever
there's
some
security
considerations?
The
one
is.
T
T
So
that's
something
that
needs
to
be
probably
cleaned
up
in
the
client.
How
to
do
that?
We
don't
specify.
Quite
yet,
we
need
to
socialize
that
a
little
bit
more
see
how
we
want
to
handle
that
encrypted
and
authenticated
dns
on
that.
First
bullet
is
mandatory
because
we
don't
want
arbitrary
justification
text
to
be
inserted
into
a
dns
query.
T
Response
pair
would
be
bad
and
then,
if
the
url
is
being
visited
for
the
c
and
the
r
pages
that
are
formed
is
that
that
url
should
be
in
a
constrained
environment
similar
to
what
captive
portals
are
doing
today,
but
keep
in
mind
that
processing
those
two
things,
the
c
and
the
r
fields
is
optional,
because
again
we're
expecting
and
hoping
that
the
j
field,
the
justification
free
form,
contains
enough
information
to
understand
why
this
was
filtered.
That's
why
we're
not
using
predefined?
You
know
error
code
number.
T
One
error
code,
number
two
error
code,
number
three,
which
etsy
is
taking
a
path
of
defining
for
filtering,
but
rather
freeform
text,
so
that
anything
that
the
operator
wants
to
put
in
here
for
why
they
filtered
can
actually
be
put
in
here-
and
this
is
my
last
slide.
So
a
couple
of
discussion
points
that
that
I'd
like
to
get
feedback
on
on
the
list
or
right
now
are
how
to
handle
the
language
in
the
j
and
perhaps
also
the
organization
field,
but
really
the
justification
field
is
the
one
that
is
most.
T
Some
consideration
is,
if
that
comes
back,
a
web
browser
could
itself
with
its
built-in
translate
capability,
just
translate
it
for
the
user
not
terribly
appealing,
but
some
discussion
on
that
would
be
kind
of
nice
and
then
also
the
isolated
browser
environment
and
how
folks
feel
about
that.
There
is
a
increase
in
security
posture
for
the
client
for
that
situation,
but
it
also
means
the
user
doesn't
get
autofill
for
and
and
also
doesn't
get
cookies
to
open
a
ticket
with
their
service
provider.
T
You
know
they're
or
whoever
is
doing
that
filtering,
because
it's
in
this
constrained
environment,
that's
not
going
to
autofill
and
they
have
to
type
everything
manually,
which
is
a
real
pain,
and
I
don't
know
if
this
is
interesting
enough
for
the
working
group
to
consider
adopting
it.
Quite
yet,
or
if
we'd
like
to
go
another
cycle
but
most
interested
in
those
first,
two
discussion
points.
So
that's
my
presentation.
T
U
So,
in
my
view,
there's
no
safe
use
case
here
that
involves
presenting
this
to
the
user,
at
least
not
in
a
web
context,
and
that's
okay.
I
think
there's
actually
value
nonetheless
in
this
in
this
draft,
but
what
I
would
really
like
is
a
a
shift
to
emphasis
on
on
technical
use
cases
and
debugging,
where
the
risk
of
user
harm
is
minimal
and-
and
I
think
a
generalization
here.
U
In
my
view,
access
denied
is
not
is
not
the
only
interesting
use
case
here,
and
this
exact
format
or
technology
could
apply
equally
well
to
diagnosing
other
dns
failures
in
general.
I
think
this
could
be
a
useful,
essentially
a
useful
addendum
to
the
extended
error
codes
draft
to
provide
debugging
at
the
client
with
more
general
structured
information.
U
J
I
I
so
I
I
take
ben's
points
like
I
said:
we've
been
talking
about
this
for
a
while.
I
have
my
views
on
it.
I
think
there
is
a
real
use
case
here
for
debugging.
I
think
there's
a
use
case
here
for
enterprises,
particularly
enterprise
products,
malware
filtering
all
of
this
stuff,
and
I
think
in
you
know
a
world
in
which
I
simply
get
an
nx
domain.
J
I
don't
know
whose
problem
that
is,
if
I
get
an
x
domain
along
with
some
indicator
that
that
next
domain
was
intentional,
you
know
or
or
that
or
was
fabricated
or
whatever.
I
think,
there's
something
in
between
dnsr
codes,
and
here
we're
gonna
go
automatically
load
this
url
for
you,
and
I
think
this
draft
can
talk
about
what
that
is,
and
I
think
that's
you
know
the
direction
to
go
in.
I
think
it
can
provide
guidance
to
iot
device
creators
and
and
browsers-
and
things
like
that.
J
I
take
the
point
about
attacks.
I
have
a
hard
time,
envisioning
an
attack
that
says
I
see
what
you're
asking
for
and
something
is
telling
you
you're
not
allowed
to
have
it.
It
doesn't
give
you
phone
number,
it
doesn't
give
a
url
doesn't
give
anything
just
a
it's,
not
just
you
right.
That
is
the
signal
that
this
could
lose
and
there's
value
in
that.
In
my
opinion,.
C
V
This
actually
gives
visibility
to
that
and
then
second
point,
the
current
user
experience
is
crap,
yeah,
let's
be
honest,
nx
domain
or
some
or
a
blank
screen
is
pretty
hopeless.
You
know,
I
often
remind
people
about
rfc8890.
You
know
the
internet
is
meant
to
be
friend
users
this
this
this
document.
It
gives
us
an
opportunity
to
actually
make
it
a
much
better
end
user
experience
in
enterprises
now
with
malware
etc,
and
I
really
think
the
the
problems
have
been
exaggerated
and
there's
a
really
positive
reason
for
going
with
this.
U
B
U
Audible,
just
yes,
okay
great,
so
I
think
my
opinion
of
this
is
it's
as
far
as
ever,
showing
such
information
ui.
I
think
ben
gave
a
pretty
good
description
of
why
it's,
I
think,
scary,
for
pretty
much
any
client
to
be
able
to
show
such
information
from
the
ui.
If
some
user
types
in
hps
example.com
and
we
stick
something
in
the
the
content-
pane,
that's
not
from
example.com
or
from
the
browser
itself,
which
is
controlled.
That's
just
a
very
scary
security
situation.
U
I
can't
do
anything
anywhere
touching
that,
without
talking
a
huge
number
of
security
consultants
on
our
side
and
figuring
out,
if
there's
any
safe
way,
we
can
do
that
and
at
least
in
the
old,
in
the
old
version.
That's
our
pure
ui.
It
never
rose
to
the
priority
level
where
I
could
even
drive
that
and
get
enough
opinions
to
even
approach
it.
U
Are
we
getting
enough
value
out
of
this
compared
to
edu?
It
would
be
worth
pursuing
to
be
worth
resolvers
sending
this
information.
If
it's
not,
then
I
don't
know
if
this
is
enough
to
do
so.
In
the
very
least,
I
think
we
need
more
information
on
just
how
this
ideally
goes
alongside
ede
before
anyone
can
really
consider
adopting
much
less
consider
implementing
anything.
A
lot
of
these
lines.
P
Dns
server
you've
got
to
make
it
super
super
clear
that
this
did
not
come
from
them,
but
I
am
even
more
frightened
by
the
idea
that
people
think
oh
we'll
just
use
this
in
enterprise
and
dan.
I
know
you've
been
on
both
sides
of
it's
the
whole
internet
or
it's
just
enterprise,
and
I
think
you
know,
with
stuff
you're
doing
at
citrix,
now
you're
more
on
the
just
enterprise
side.
T
No,
I
don't
see
a
reason
to
scope
it
to
just
enterprise
myself,
because
I
think
it's
easy
to
show
that
this
text
that
you're
seeing
did
not
come
from
the
site.
You're
visiting
we're
doing
that
today,
the
industry's
doing
that
today,
with
nx
domain,
it
shows
I
couldn't
get
there.
I
couldn't
find
the
server
right
and
it
shows
a
message
and
and.
P
I
I
I
live
with
a
use
case
where
that
doesn't
work
where
the
person
will
say
the
website
says
this,
when
it's
very
clearly
what
you
just
said,
which
was
it
was
in
fact
safari
saying
this
so
yeah.
I
I
have
some
fears
as
well,
particularly
if
you're
not
feeling
that
it
should
be
limited
to
the
enterprise,
so
just
wanted
to
throw
that
in
there.
T
With
bring
your
own
device
and
and
taking
my
work
computer
to
starbucks,
you
know
which,
which
is
an
enterprise
scenario
and
which
isn't
you
know
and
starbucks
may
want
to
do
filtering
locally
themselves.
You
know
for
for
their,
you
know.
Whatever
their
reasons
are,
you
know
to
use
their
network
for
free,
you
know,
buy
a
coffee
and
don't
view
porn
because
it
upsets
everyone
else
in
the
coffee
shop,
reasonable.
It's
their
network,
don't
know,
but
yeah.
I
don't
see
a
way
to
restrict
anything
to
just
enterprise.
T
M
T
W
W
That'd
be
great
yeah,
okay,
okay,
and
I
know
it's
probably
a
little
bit
unusual,
but
could
I
invite
paul
hoffman
to
the
mic
first,
to
give
me
some
immediate
feedback
on
the
clarity
of
of
what
the
the
goals
are
or
what
the
use
cases
are.
I'm
not
sure
that
I've,
I've
done
a
good
job
of
that
and
if
he,
if
he
can
give
a
little
bit
of
feedback
as
I
go
through,
this
that'd
be
great
thanks.
W
The
goal
is
to
provide
a
complete
package
of
implementation,
guidance
or
specifications
to
allow
a
resolver
to
talk
to
an
authoritative
get
have
the
ability
to
establish
a
authenticated
connection
to
the
authoritative
server,
with
respect
to
a
specific
domain
name
that
it
wants
to
send
queries
about
and
the
all
the
stuff
is
about
how
to
do
the
discovery
and
signaling.
Do
it
securely?
Do
it
in
a
way
that's
downgrade
resistant,
so
next
slide.
W
So
it's
privacy
protection
is
the
the
main
thing,
but
that's
pretty
common
across
all
of
the
a
lot
of
competing
suggestions
or
drafts,
or
proposals
in
deprive.
I
was
taking
this
as
a
as
a
complete
set
of
things,
and
some
of
these
are
involving
different
solutions
to
some
of
the
same
underlying
problems.
W
W
You
need
to
have
a
secure
delegation
to
the
name,
server's
name
the
zone,
containing
that
it
has
to
be
deployable
in
a
reasonably
short
time,
so
I'm
assuming
the
use
of
stuff,
that's
only
in
dns,
with
as
few
new
protocol
elements
as
possible
and
without
requiring
any
major
changes,
or
even
anything
above
the
most
minor
on
the
registry.
Registrar
mechanisms
for
for
transmitting
stuff
upstream
within
the
dns
system,
explicit
signaling,
of
support
and
being
downgrade
resistant
next
slide.
W
W
This
is
a
new
dns
key
algorithm
that
is
used
to
protect
delegation,
ns
records
via
dns
sec
signature
over
a
ds
record,
which
contains
a
hash
of
the
name,
server
name,
it's
the
only.
You
need
to
have
some
way
of
of
validating
the
target
of
an
ns
record
in
the
parent,
the
delegation,
in
order
to
be
able
to
trust
the
name-
that's
being
used
in
that,
since
all
the
rest
of
it,
including
the
the
actual
name
used
in
the
certificate
for
tls,
as
well
as
any
signaling.
W
W
The
second
draft
is
a
thing
called
the
dnst,
it's
a
new
rr
type
and
it's
simply
explicit
support
for
transport
tied
to
the
domain
name
of
the
name
server
and
the
name
server
domain
has
to
be
dnsx
signed.
So
this
becomes
a
protected
signaling
things.
So
it's
downgrade
resistant
and
glue
glue
guidance
is
kind
of
optional,
but
it
it's
useful
potentially
to
compare
the
glueless
guidance
against
what
ds
glue
has
it,
but
I
don't
think
that's
necessary
to
discuss
in
this.
W
W
That
zone
has
to
be
signed
anyway.
So
there's
not
a
lot
of
additional
incremental
overhead
in
saying,
let's
use
a
tlsa
record,
if
you
can
validate
the
tlsa
record,
you're
good
to
go,
you
don't
actually
technically
need
web
ppi
doesn't
mean
you
can't
use
web
web
pki
issued
certs.
It
just
says
that
you
don't
actually
have
to
use
the
web
pki
validation.
W
W
The
it's
used
to
create
a
special
ds
record,
it's
possible
to
use
a
ds
record,
even
if
this
child
zone
is
not
signed.
If
you
look
at
the
last
line
in
this
slide,
it
says
unknown.
Dns,
key
algorithms
are
treated
as
insecure,
rather
than
bonus,
so
nsv
unaware
resolvers,
don't
have
problems
with
this
proposed
edition.
W
So
the
idea
is
you
take
the
name
server
name,
you
put
it
into
a
structure
which
is
technically
a
dns
key
structure.
You
don't
actually
publish
the
dns
key
in
the
child
zone
and
that
avoids
making
the
child's
own
seem
as
if
it's
actually
dns
excited
because
it
doesn't
have
to
be.
You
then
take
the
hash
of
that.
W
New
record
type-
and
that
becomes
your
ds
record
validating
that
is
using
the
parent
nsr
data
so
where
you've
got
an
ns
record,
the
target
name,
which
is
the
right
hand
side
of
the
ns
record,
is
the
name
server
name.
You
follow
the
same
construction
method,
take
the
name
server
name,
you
hash
it
as
as
a
as
if
it
was
a
dns
key
and
compare
that
against
the
ds.
If
it
matches
you're
good-
and
you
can
be
reasonably
assured
that
the
ns
record
in
the
parent
for
the
delegation
has
not
been
tampered
with.
W
The
record
would
simply
consist
of
three
flags
that
are
either
set
or
not
set
and
indicating
support
for
each
of
the
three
different
transport
protocols
that
I
put
in
the
draft
udp,
which
is
obviously
vanilla,
dns,
tcp,
vanilla,
dns
and
dot,
which
is
dns
over
tls
to
authority
it's
using
the
same
owner
name.
But
what
I'll
point
out
is
that
nameservers
can
have
more
than
one
name.
So
if
you
want
to
differentiate.
W
W
What
the
zone
name
is,
do
you
try
to,
or
do
you
want
to
use,
dlt
or
not,
or
rather
has
that
that's
been
explicitly
signaled
by
the
nameserver
operator?
It's
not
required
to
do
this.
I'm
saying
it's
available
as
a
mechanism,
so
an
authority
server
operator
can
do
dlt
to
everybody
dod
to
nobody
or
potentially
do
it
on
a
zone
by
zone
basis
without
actually
having
anything
other
than
the
name
server
name
being
a
differentiator.
W
W
All
of
this
is
about
downgrade
resistance.
That's
why
the
nsv,
algorithm
ds,
hashes,
are
ds.
Hashes
in
the
parent
zone.
They're
signed,
restrict
the
usage
of
ns
to
cases
where,
if
there's
a,
if
there's
a
corresponding
ds
that
the
ds
and
the
ns
are
in
agreement
and
the
children
child
records
in
the
name
server
names
zone,
those
are
also
this
dns
sign
zone
so
they're
signed,
and
that
gives
you
discovery
is
downgrade
resistant
and
certificate.
W
W
W
And
this
is
just
explaining
why
I'm
going
down
the
road
of
it
has
to
be
dna?
Second
tlsa.
It's
so
that
the
clients
have
the
ability
to
validate
using
only
dns
elements.
If
you
don't
require
tlsa
to
be
used,
then
clients
can't
validate
using
dane
and
they're
forced
to
use
web
pki.
So
I
don't
want
that.
To
be
the
case.
That's
why
I'm
saying
it's
got
to
be
tlsa,
and
that
means
it
has
to
be
dnsx
signed.
That's
for
minimum
operability.
W
The
resolvers
have
the
option
of
not
doing
nsx
validation
and
of
doing
web
pki
validation
if
they
wish.
This
isn't
forcing
the
clients
to
do
anything.
It's
making
sure
that
if
the
clients
want
to
do
dane
validation
that
they
can
and
the
only
things
that
actually
have
to
be
signed
are
the
name
server
zones.
Then
the
zones
that
contain
the
names
of
the
name
servers
themselves.
W
It's
such
a
small
draft.
I
think
it
doesn't
require
much
review.
It
could
probably
even
go
straight
to
a
working
group.
Last
call
with
like
only
a
few
reviews
and
getting
an
early
code
point
assigned
so
that
implementations
can
be
done.
It's
trivial,
it's
three
flags.
The
nsv
is
probably
a
little
bit
more
controversial.
W
B
U
U
U
That
draft,
so
that
draft
is,
is
essentially,
in
my
view
very
similar
to
dnst.
I
would
strongly
prefer
not
to
have
two
solutions
there.
You
know
the
the
the
service
bindings
for
dns
draft
is
not
in
last
call
if
you
feel
that
there
are
changes
you'd
like
to
see
in
it,
please
take
those
to
add
and,
and
we
can
discuss
whatever
changes
you
want,
if
you
think
it
should
be
a
different
rr
type,
I
think
add,
and
that
draft
is
the
place
to
have
that
discussion.
W
W
I
I
the
reason
I
went
with
this
simple
flag
mechanism.
Is
it's
so
lightweight
to
actually
implement?
I
agree.
We
shouldn't
have
two
things.
It's
simply
a
question
of
which
is
more
expedient.
Is
there
anything
in
the
service
binding
things
that
actually
add
value
that
can't
be
done
other
ways
in
better
ways?
I
I
think
it's
it's
an
offline
discussion,
but
yeah
okay,.
U
The
other
thing
I'll
mention
is
that
the
glue
list
delegations
we're
kind
of
in
the
wrong
working
group
for
this,
but
the
glueless
delegations
raise
a
bunch
of
very
tricky
privacy
questions
because,
as
I
understand
it,
to
get
the
to
hit
the
performance
targets
that
you're
talking
about,
we
essentially
disable
the
adot
mechanisms
when
we're
chasing
these
glueless
delegations
and
those.
So
it's
assumed
that
the
queries
involved
in
the
glueless
delegation
process
are
no
longer
sensitive.
U
I
think
that's
only
true
if
the
child
zone,
if
the
ns
in
the
child
zone
is
not
only
out
of
bailiwick,
the
original
ns
record
is
not
only
out
of
bailiwick
but
also
itself
non-sensitive.
So
if
I
have
you
know,
companyone.com
and
I
have-
and
I
put
my
name
servers
under
company1.net
they're
out
of
bailiwick,
but
they're
still
disclosing
the
same
piece
of
information,
potentially
so
correct.
Yes,
I
so
I
I
would
like
to
see
a
little
more
discussion
of
that.
I
I
think
it's.
W
W
W
W
It's
mostly
about
the
ability
to
get
the
signal
in
and
actually
that's
the
tlsa
part.
It's
it's
only
the
dnst
that
matters
for
the
signaling,
the
tlsa
part,
could
still
be
underneath
the
individual.
I
guess
it's
just
to
allow
a
more
scalable
population
of
a
zone
if
you
have
the
ability
to
do
some
kind
of
wild
card
and
the
only
way
to
discover
that
you're
able
to
use
that
wild
card
is
if
the
owner
name.
W
That
happens
to
be
the
same,
and
you
can
see
that
in
an
insect,
an
nsec
record
that
shows
that
there
is
no
tlsa
record
at
that
order
name,
but
that's
that's
mostly
for
optimizing.
The
number
of
round
trips
on
a
warm
cache,
not
hot,
but
warm
yeah.
I
I
think
it's
probably
a
thing
to
discuss
on
the
building
this
morning.
S
Okay,
there
I
just
had
a
question
for
you
about
the
nsv
algorithm
type
for
ds,
same
question
that
I
actually
asked
ben
in
the
deprived
meeting,
which
is
have
you
had
any?
Have
you
attempted
to
deploy
this
nsv
algorithm
to
any
parent
zones
that
are
significant?
I
mean,
obviously
you
can
run
your
own
parents
own.
Have
you
attempted
to
deploy
it
to
any
active
ones
and
what
was
the
results
of
that.
W
We
can
actually
do
that
and
send
the
results
up
to
different
plds,
so
I
haven't
succeeded,
but
I
haven't
done
the
the
more
in-depth
trials
on
that
my
suspicion
is
that,
as
long
as
an
algorithm
has
had
a
pull
point
assigned
to
it,
it's
much
easier
to
convince
a
registrar
to
update
their
ui
to
allow
the
code
point
to
be
used.
The
fact.
W
The
main
issue
I
think
is
going
to
be
on
the
the
parental
side
and
whether
or
not
a
registry
is
going
to
be
willing
to
accept
a
plain
text
rather
than
a
hashed
ds
value.
By
sticking
with
an
existing
ds
hash,
I
see
very
little
the
likelihood
of
there
even
being
any
contentiousness
to
this.
It's
still
doing
comparisons
of
hashes
and
the
only
purpose
of
that
is
to
validate
existing
parental
records,
I.e
the
ns
records.
E
Specific
specifically
on
the
question
of
registries,
if
I
remember
correctly.de,
will
not
accept
the
the
nsv
dsr
set,
because
at
the
time
at
which
you
upload
your
ds
record,
they
actually
do
live
queries
against
the
child
to
make
sure
it
has
matching
dns
keys
at
the
zone.
Apex
during
epp
and
they'll
reject
the
the
update.
So
some
registries
will
change
their
practice
yeah.
This.
W
W
B
B
B
During
this
session,
there
was
a
continued
discussion
on
the
insect
3
iteration
guidance
on
on
jabber,
so
we
asked
wes
if
whether
he
was
available
tomorrow
to
continue
this,
this
discussion
in
the
working
group,
so
we
will
reserve
another
10-15
min
minutes
for
tomorrow
to
continue
the
discussion
on
ancestry
and
finally
nail
some
numbers
or
well
suzanne.
You
want
to
say
something
to
that.