►
From YouTube: IETF111-DNSOP-20210726-2300
Description
DNSOP meeting session at IETF111
2021/07/26 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
So
as
on
the
agenda,
we've
got
some
updates
some
current
business
and
basically
a
lot
of
discussion
of
sort
of
all
business.
I
think
is
probably
the
better
way
to
put
this
and
we
have
a
questionnaire
that
we're
sort
of
wrapping
up
in
a
couple
days
and
there's
been
some.
You
know
we're.
We
got
some
interesting
feedback
already,
which
is
pretty
good
and
we'll
discuss
that
on
on
thursday,
as
well,
more
in
detail
so
going
through.
Our
document
updates.
A
We've
had
two
rfc
since
our
last
meeting,
the
server
cookies
9018
and
just
the
other
day,
the
insect
ttl,
congratulations,
peter
1977,
finally,
sort
of
been
published
and
that
those
are
both
pretty
they're,
both
very
happy
about
that.
We've
got
four
that
are
sort
of
sitting
in
various
ies.
You
know
either
in
the
editor
queue
or
in
the
isg
states
and
they'll,
be
like
something
like
service
b
may
sit
there
for
a
little
bit,
because
it's
sort
of
sitting
on
the
esni
draft,
which
is
still
kind
of
hasn't,
been
finished.
A
A
Last
call
the
glue
is
on
optional
draft,
which
I'm
glad
we
were
able
to
sort
of
bring
that
back
from
the
from
the
missing
and
we've
got
a
short
presentation
on
that,
and
we
think
that,
with
a
lot
of
the
sort
of
work
in
the
past
few
weeks
on
that
we're
probably
ready
for
working
group
last
call
as
well,
because
it's
very
it's
very
short
and
to
the
point
same
thing,
with
the
avoid
fragmentation.
There's
a
short
presentation
today,
and
we
should.
We
should
be
able
to
move
that
one
along.
A
I
think
there's
one
or
two
one
thing
that
sort
of
was
outstanding,
that
I
remember
that
I
believe
we
may
have,
but
other
than
that
we're
in
good
shape.
So
we've
got
a
bunch
of
responses
to
our
poll.
So
thank
you
for
all
that,
and
it
was
sort
of
helpful
to
help.
You
know
to
sort
of
see
about
the
prioritization
of
work,
and
that
was
really
great
and
a
little
a
little,
I
wouldn't
say
surprising,
but
just
you
know
like.
A
Oh
that's,
that's
kind
of
good
to
hear
from
the
working
group
sort
of
thing.
So
some
of
the
things
that
we
saw
high
interest
in
which
was
sort
of
interesting
was
the
glue,
is
not
optional,
which
we
kind
of
expected
would
be
sort
of
a
high
interesting.
The
nc3
guidance
had
a
lot
of
positive
feedback.
That's
going
to
be
talked
about
later
today,
as
well
also
industry,
validation
and
the
error
reporting
they
both
had
some.
A
You
know
a
little
higher,
you
know,
and
we
sort
of
expected
those-
and
we
just
sort
of
were
surprised
to
see
a
good
sort
of
positive.
You
know
from
from
folks
so
there's
something
on
the
private
used
tld,
one
which
I'm
gonna
let
suzanne
talk
about.
She
spent
a
lot
of
time
talking
with
the
liaisons
and
the
iab
about
this.
So
I
won't
say
this
because,
whatever
I
say
is
gonna
be
just
wrong.
B
B
A
Okay,
thanks
yep,
so
that's
a
good
way
to
sort
of
put
that.
Thank
you.
Suzanne
and
you
know
our
stuff
is
in
the
data
tracker
in
github,
so
people
can
look
and
see
what
we're
up
to
and
sort
of
comment
and
give
us
feedback.
We're
always
welcome
to
that.
Today,
on
some
of
the
current
business
insect
3
guidance,
wes
is
going
to
talk
a
little
bit
about
that
schumann's
got
an
update
on
the
glue,
is
not
optional.
A
They've
been
working
pretty
hard
on
sort
of
cleaning.
Some
of
that
up.
So
we're
really
glad
about
that.
Mr
fujiwarasan
has
an
update
on
avoid
fragmentation
and
paul's
got
some
comments,
but
I
I
ain't
in
consideration
which
we
really
do
want
to
the
the
chairs
really
kind
of
want
to
move
forward
on.
We
know
it's
kind
of
not
interesting
dns
work,
but
it's
stuff
that
actually
probably
needs
to
get
done
on
sort
of
the
ietf
side.
A
A
So
I'll
take
feedback
on
that
and
I
believe
so
and
then
of
course
session
two
we're
going
to
sort
of
talk
about
some
of
the
the
feedback
from
the
from
the
poll
and
then
sort
of
listen
to
the
basically
get
a
lot
of
feedback
from
the
working
group
as
to
what
you
think
we
should
be
working
on
and
how
we
should
sort
of
order
some
of
the
business.
We
know
we
have
a
lot
going
on
a
lot
of
it.
A
We
always
let
the
kind
of
the
working
group
kind
of
move
stuff,
but
sometimes
that's
not
always
the
right
thing,
and
so
because
that
always
lets
sort
of
the
the
louder
voices
get
heard
first,
and
maybe
that's
not
always
the
right-
the
right
way
to
go.
So,
let's
so,
let's
get
started
on
stuff,
we'll
keep
things
on
track
and
I
believe
wes
is
the
first
speaker
so
suzanne's
going
to
sort
of
do
some
work
with
the
slides
here
and
make
this
all
work.
C
D
B
E
E
D
Go
all
right,
see
it
yep
okay.
So
this
is
about
draft
etf,
dns
ben
tech,
three
iterations,
which
is
a
a
short,
very
short
draft
by
myself
and
victor
duveny.
His
name
is
on
the
slide,
sorry
victor,
so
real
quick
status
on
the
draft
first
off.
What's
the
point,
I
think
probably
most
people
have
read
it,
but
you
know
essentially
we're
recommending
a
few
things
in
it.
One
use
nsec
if
you
can
instead
of
three
insect
three
iterations
recommendation
in
the
draft,
is
a
zero.
D
So
you
really
shouldn't
do
iterations
beyond
one.
It
really
doesn't
help
as
much
as
I
think
we
were
helping
hoping
it
would
way
back
when,
if
you're
using
an
n63
salt,
you
should
only
use
it
if
you're
going
to
change
it,
because
otherwise
the
salt
is
pretty
much
useless
and
then
for
validating
resolvers.
D
There's
a
new
proposal
for
ranges
to
put
into
place
for
what
you
can.
You
should
consider
insecure
and
things
like
that.
So
the
range
essentially
goes
from
0
to
100.
That's
a
valid
range
for
insect
three
iterations
and
you
should
validate
it
from
101
to
500.
You
should
treat
it
as
an
insecure
zone
and
previously
in
the
original
insect
three
specifications,
those
numbers
were
quite
a
bit
higher,
but
that
caused
various
problems
and
then
for
501.
D
F
D
I
really
wanted
to
have
this
discussion
first,
so
the
remaining
items
to
discuss
are
one,
whether
authoritative
overhead,
how
much
authoritative
overhead
you
know
requirements
are
necessary
and
how
much
that
hurts
authoritative,
servers
and
then
the
second
to
decide
if
the
ranges
are
right
that
I
had
on
the
previous
screen,
which
I'll
reiterate
here
right.
Are
these
an
acceptable
set
of
ranges,
as
the
working
group
feel
comfortable,
that
this
is
the
right
answer?
D
So
a
lot
of
data
about
that
so
victor
in
his
one-man,
marching
band
of
contacting
every
server
on
the
planet
that
has
bad
values
and
convincing
them
to
switch.
This
is
as
of
yesterday,
so
the
he
measured
a
whole
bunch
of
zones
as
many
as
he
knows
about
that
are
running
nc3
on
the
internet,
looking
for
their
latest
set
of
parameters.
So
this
is
a
cdf
of
where
the
iterations
are,
and
you
can
see
the
the
100
line
is
in
black
there
and
the
500
line
is
in
black
over
here.
D
So
you
can
see
that
this
curve
nicely
goes
up
above
90.
You
know,
as
we
start
approaching
100.
if
we
zoom
in
you'll
see
that
actually,
if
you
start
looking
at
this
upper
right
hand
corner
there's
a
lot
of
there's
a
decent
amount
of
zones
at
100.
But
if
you
remember
in
my
chart
that
was
an
acceptable
number
and
then,
if
we
zoom
in
even
more,
you
can
see
that
the
number
of
zones
at
101
or
more,
is
you
know
down
into
this
really
really
small
percentage
of
the
range?
D
D
In
other
words,
99.94
percent
of
zones
were
less
than
100
or
100
or
less,
and
then
five
nines
for
for
500
or
less
so
it
seems
to
me,
like
you
know,
this
range
of
values
is
is
seems
to
be
accepted.
So
a
lot
of
various
places
have
come
down
and
victor
can
talk
at
length
about
the
the
major
providers
that
have
actually
you
know,
toned
down
their
iterations
quite
a
bit
in
the
last
few
months,
due
to
his
pushing
and
other
people's
pushing.
D
D
My
real
question
to
people
today
and-
and
this
is
really
encouraged
to
spark
discussion,
and
if
we
roll
over
my
10
minutes,
we
should
certainly
give
it
all
up.
But
my
question
today
is:
does
anybody
disagree
with
these
ranges
and
if
so,
we
should
speak?
You
know
now
we're
on
the
mailing
list
and
with
that,
that's
actually
it.
This
is
a
very
short
update,
very
short
document,
and
we
should
be
getting
close
to
ready
to
last
call.
If
we
agree
on
this-
and
I
see
jim
in
the
queue.
D
G
G
D
That's
fair,
then
we
have
then
we'll
get
into
the
debate
of
of
what
is
the
right
impact
to
a
validator,
and
how
do
we
measure
that,
given
multiple
validators
and
you
know
unknown
code
ranges
and
unknown
cpus
and
acceleration,
and
things
like
that,
so
why
don't
you
bring
that
up
on
the
mailing
list?
I
think
that's
a
great
idea
to
consider
doing
it
and
we
need
a
volunteer
to
actually
you
know.
Do.
H
Am
I
there
yeah
yep,
so
a
couple
of
things
to
jim's
point?
We
did
have
an
off
list
discussion
with
a
number
of
folks
right
who
are
building
resolvers
and
have
been
making
measurements
of
their
impact.
They
just
have
to
go
public
with
some
of
the
numbers
that
we
were
talking
about
back
in
april
right,
so
the
folks
I'm
not
and
buy
and
isc,
and
so
on
should
be
able
to
provide
data
on
that.
H
The
other
thing
I
wanted
to
mention
is
that
that
steep,
you
know
spike
at
100
will
actually
mostly
disappear
in.
My
sense
is
about
a
month
or
two
because
trans
ip
who
is
responsible
for
something
like
96
or
more
percent
of
that
100s
are
migrating
all
of
their
domains
to
zero,
as
recommended,
but
that's
just
beginning
so.
D
H
J
D
D
H
Answer
all
right
security
of
positive
responses,
not
many
things
rely
on
negative
responses
being
secure
being
one
of
them,
but
for
dane
you
know
if
you're
out
there
in
the
wrong
range,
you
know.
Are
we
really
doing
people
a
favor
by
blocking
their
mail
rather
than
delivering
it
without
pain
when
they
specify
more
than
100
durations,
given
how
few
of
them
there
are,
I
think
insecure
is
about
right.
People
were
concerned
that
nobody
would,
however,
notice
the
signal,
and
they
would
hang
out
there
forever.
H
D
D
K
K
So
a
bunch
of
other
folks
whose
names
you
see
on
this
title
slide
are
now
also
involved
along
with
mark
in
helping
to
complete
and
hopefully
push
this
out.
So
can
you
advance
the
slide
all
right?
So
the?
What
did
the
original
draft
say?
It's
stated
what
glue
records
are
which
are
address
records
for
name
servers
that
are
contained
in
the
delegated
zone.
K
K
Actually,
so
that's
the
latest
version
if
you're
reading
it.
So
a
quick
summary
of
the
changes
from
synth-0
are
that
first,
the
example
provided
in
the
original
draft
of
misbehavior
by
the
dot,
gov,
authoritative,
name,
servers,
that's
actually
already
been
fixed.
They
now
set
tc
equals
one
appropriately,
and
so
we
note
that
it's
it's
historical
we
discuss
sibling
glue
specifically
and
what
the
corresponding
processing
requirements
for
such
glue
are
and
I'll
get
to
that
in
a
bit.
K
There's
some
discussion
of
cross
zone
ns
records
with
circular
dependencies,
which
I
think
we've
taken
out
in
the
latest
version,
but
I'll
discuss.
What
was
there
originally
and
there's
some
discussion
of
orphan
glue?
Which
again,
is
you
know,
a
topic
worthy
of
debate,
whether
it
belongs
in
this
draft
or
not?
K
So,
let's
move
on
to
the
next
slide,
so
sibling
goo,
as
far
as
I
can
tell
sibling
glue,
is
not
defined
in
any
itf
document
to
date,
so
we
provide
a
definition-
and
maybe
this
can
be
referred
to
in
the
next
update
of
of
dns
terminology,
and
the
definition
is
that
these
are
glue
records
that
are
not
contained
in
the
delegated
delegated
zone
itself.
That
is
the
zone
that
the
referral
is
being
produced
for,
but
in
another
delegated
zone
from
the
same
parent.
K
So
in
most
cases
these
aren't
strictly
required
in
the
referral
response
for
resolution
to
work.
This
is
because
the
resolver
can
typically
make
additional
queries
to
resolve
the
name,
server
addresses
and
then
follow
the
referral
for
the
sibling
zone
to
get
them.
However,
this
causes
unnecessary
additional
traffic
from
the
resolver
and
most
competent
name
server.
Implementations.
We're
aware
of
always
provide
sigmund
gloom
in
the
response
next
slide.
Please.
K
So
after
some
discussion
amongst
the
four
of
us,
the
main
proposal
in
the
draft
in
terms
of
processing
requirements
is
that
sibling
glue
must
always
be
provided
in
the
referral
response
too,
and
it
too
is
subject
to
the
tc
equals
one
truncation
requirement
if
the
glue
doesn't
fit
and
the
rationale
for
that.
That
is
twofold.
K
K
K
So
we
don't
expect
this
to
work.
I
mean
in
theory
the
zones
could
arrange
to
have
cross
zone
address
records
returned
gratuitously
in
the
referral
response,
but
the
question
is:
why
would
resolvers
actually
accept
those?
This
is
data
from
an
entirely
unrelated
zone,
not
under
the
purview
of
the
delegating
authority,
and
most
resolvers
are
paranoid
about
what
they
accept
anyway.
So
our
proposal,
when
we're
discussing
this
is
to
remove
this
section
entirely,
which
we
have
now
done
in
dash
o2.
K
But
if
folks
want
to
push
back,
we
can
have
a
discussion
about
whether
it's
worth
keeping
it
in
just
as
a
kind
of
a
precautionary
example
of
what
not
to
do
next
slide.
Please
and
there's
a
small
section
that
talks
about
quote
unquote
orphan
glue.
I
just
want
to
note
first
that
this
is
not
really
a
dns
protocol
term.
K
So
our
question
for
the
working
group
here,
I
think,
is
what,
if
anything
should
be
said
about
this
practice
right,
so
one
option
is
we
can
remove
the
section
and
the
other
option
is,
if
we
do
say
something.
Probably
the
least
contentious
path
is
to
just
describe
the
situation,
but
make
no
judgments
about
it.
K
Next
slide.
Please
and
lastly,
in
in
o2,
we've
made
one
additional
clarification,
so
the
earlier
draft
said
that
glue
must
be
included
or
truncate,
but
didn't
elaborate
on
whether
that
meant
all
glue
or
some
of
the
glue
or
just
you
know,
one
glue
and
we
now
state
the
requirement
is
all
glue
records
so
if
all
of
them
don't
fit,
we
set
the
tc
flag
and
we'd
have
be
happy
to
have
a
discussion
about
that
specific
point.
K
If
folks
don't
disagree
with
it,
but
that's
what
we
have
currently
and
I
think
that's
the
end
of
my
presentation-
maybe
there's
one
more
slide:
yeah,
okay,
so
we
have
a
get
a
repo
for
edits
to
the
draft
source
and
for
opening
issues
etc.
And
with
that
I
will
stop
now
and
open
it
up
for
a
discussion.
L
F
M
L
L
L
O
Through
this
draft-
and
I
must
admit,
I'm
echoing
some
of
the
commentary
in
the
chat
window-
about
the
appearance
of
what
you
call
sibling
glue-
you
create
it
as
a
mandatory
a
must,
but
without
any
justification
mike.
The
draft
doesn't
really
explain
why
this
becomes
a
mandatory
and
and
yet
all
other
kinds
or
other.
P
O
So
I
suppose
my
observation
is
either
excise
section
4
that
refers
to
sibling
glue
in
this
draft
and
just
don't
discuss
it
or
you've
got
to
do
a
much
better
job
at
justifying
its
inclusion
and
understanding
exactly
what
the
trade-offs
are
in,
recognizing
that
it's
sibling
glue
and
then
making
sure
that
it's
mandatory
and
justifying
why
that
mandatory
inclusion
is
appropriate
in
all
cases.
Thank
you.
F
Basically,
you
can
also
get
delegation
loops
in
sibling
glue,
which
is
the
reason
for
it.
You
can't
away.
You
don't
want
to
spend
the
time
to
determine
whether,
when
returning
a
referral,
whether
a
delegation,
whether
you've,
actually
got
a
delegation
loop
or
not,
which
is
why
it's
mandatory,
does
that
help
you
jeff.
Q
K
Yeah
so
jeff,
I
agree.
We
should
put
that
in
the
in
the
draft.
I
think
it
was
implied
in
one
of
my
earlier
slides
because
there
are
some
situations
where
sibling
glue
is
mandatory.
So
this,
actually,
if
we
have
one
blanket
statement,
then
it's
much
easier
for
resolver
implementers
because
they
don't
have
to
figure
out.
You
know
whether
it's
mandatory
or
not,
they
can
just
you
know,
use
the
same
uniform
behavior
to
treat
all
group
look.
O
K
I
I
I
mean
this
also
was
one
of
the
kind
of
in
well
one
of
the
kaminsky
style
attacks
that
if
you
during
a
referral,
can
can
use
that.
If
you
have
more
referrals
in
the
additional
sections,
then
you
have
more
chat
more
chances
and
that's
why
probably
some
resolve
is
treated
a
bit
more,
more,
stricter
and
relaxing.
K
I
R
L
K
J
Yep
hi,
so
I
wanted
to
come
back
to
the
orphan
glue
and
I
think
that
at
least
you
should
mention
that
that
it's
a
security
risk,
because
the
moment
the
the
domain,
the
actual
domain
reappears,
gets
registered
again.
This
becomes
kind
of
a
zombie
glue
that
gets
into
use
again,
and
I
think
it's
a
at
least.
Should
we
say
that
it's
a
security
risk
to
do
this?
K
Sure
yeah,
I
guess
that's
a
reasonable
point,
so
I
guess
part
of
our
answer.
That
question
is:
do
we
have
agreement
on
discussing
orphan
glue
in
in
this
draft
or
not
right?
So
I
guess
that's
a
little
bit
of
an
open
question,
so
I'm
hoping
some
other
folks
will
chime
in
on
that
topic,
either
here
or
on
list
somewhere.
T
T
That's
such
a
political
thing
like
if
you
are
a
registry-
and
you
know
that
you've
suspended
the
name
and
it
hasn't
been
redelegated
and
and
the
same
person
might
might
renew
it
and
it
might
come
back
in
that
case,
orphan
glue
is
probably
okay,
but
otherwise
it
isn't-
and
I
I
I
don't.
I
don't
see
how
we
can
say
anything
sensible
about
that
in
a
technical
draft
other
than
like.
Well,
don't
put
an
orphan
glue
unless
you're
absolutely
sure.
It's
still
true
for
reasons
that
we
can't
explain.
B
P
P
P
We
couldn't
define
single
value
at
id.
110
then
also
generate
your
table.
1
default
maximum
energy
failure,
size
and
1400
is
set
author's
recommendation
and
also
the
moved
details
to
appendix
the
details
of
maximum
dns
udp
parasite
discussions
and
added
new
techniques.
Fragmentation
avoidance
is
achieved
with
the
which
ip
don't
rock
ipv6
dot,
drag
options.
P
P
P
P
P
P
P
P
The
proposed
method
is
that
number
one
send
iv
version
for
fragmentation
needed
and
dfc
to
intermediate
routers
between
the
attack
target
resolution
and
authoritative
servers,
number
two
trend:
credit
to
the
target;
resolver
number
three
estimate
ipid
and
send
the
second
fragment
to
the
target.
Deserver.
P
Please
listen
their
presentation
and
evaluate
the
effect
of
fragmentation.
Attack
on
dns
over
tgp
possible
solutions
may
be
rc,
6864,
updated
specification
of
the
ib
buttonhole
id
field
and
saving
ip,
don't
log
on
ip
version
4
for
tcp
or
enable
proximity
discovery
on
ipv4
tcp
next
slide.
Please
authors
believe
that
the
draft
is
ready
for
working
robust
call.
Please
review
carefully.
I
N
N
C
H
I
have
a
question
about
the
the
tcp
workaround:
is
it
sufficient
to
set
don't
fragment
on
the
resolving
client,
because
it
seems
to
me
that
if
the
large
fragment
is
coming
towards
the
client
from
the
server,
even
if
the
server
doesn't
fragment,
maybe
the
attacker
fragments,
so
I'm
not
sure
how
it
mitigates
the
attack.
If
more
detail
would
be
great.
C
N
C
H
N
N
And
then
just
as
a
quick
status,
this
was
adopted
as
working
group
item
two
ietf's
ago.
It's
super
short.
It's
about
a
page
and
a
half
of
text.
There's
been
very
little
discussion
on
the
list,
which
I
think
is
fine.
Hopefully
that
means
there's.
There
is
enough
agreement.
If
there
is
discussion
during
working
group
last
call
which
the
chairs
just
indicated,
we
might
be
ready
for
then
that
certainly
can
be
incorporated.
N
N
Oh,
I
wish
the
bottom
of
this
is
actually
the
most
important
part,
but
so
the
motivations
for
the
there
there
are
two
I'm
sorry.
There
are
very
three
three
very
different
motivations
for
this
one.
Is
we
have
a
draft
in
front
of
us
in
the
working
group,
rfc
5933
bis?
It
would
need
to
be
on
standards
track
if
we
do
not
move
this
draft
forwards,
because
it
has.
You
know
that
that
ds
records
have
to
be
standard
require,
but
there
are
some
people.
N
Many
people
who
disagree
with
making
every
single
national
crypto
algorithm
need
an
ietf
standard
for
one
thing
they
do
not
have
as
much
review.
We
certainly
are
not
good
at
reviewing
the
crypto
and
such
like
that
and
there's
a
lot
of
nations
who,
if
they
see
somebody,
gets
a
standard,
they
might
want
their
own
and
that
just
puts
a
lot
more
work
on
us
than
if
it
was
rfc
required.
N
That's
an
rfc
required,
you
know,
can
go
through
the
independent
series.
Editor
rfc
required
an
rfc
could
actually
come
through
the
cfrg.
So
having
having
to
put
on
standards
track
is
a
lot
of
overhead,
but
the
the
second
very
important
thing
is
that
we're
not
just
talking
about
doing
this.
For
this
one
document
for
rfc,
5933
bis,
quantum
resistant
signing
algorithms
are
a
new
shiny
thing
in
the
crypto
world.
N
F
N
Might
say
are
acceptable
for
quantum
resistance
signing
the
theory
in
that
is
that
there
is
not
necessarily
as
much
of
a
one-to-one
correlation
in
for
quantum
resistant
algorithms
between
signing
and
encrypting.
It's
not
like
you've
got
your
rsa,
which
you
can
use
for
encrypting
and
therefore
you
can
use
it
for
signing.
You
got
your
ecd.
N
So
the
reason
why
we're
doing
this
draft
is
rfc
6014,
which
was
standardized
in
2010,
made
all
of
the
new
dns
registries
rfc
required,
but
it
forgot
to
back
port
ds
and
then
sec
records.
So
all
the
new
ones
were
rfc
required,
but
we
left
two
of
them
out
and
there
was
no
justification
for
the
difference
and
in
case
anyone's
thinking
that
I'm
being
mean
about
the
author
of
rfc
6014.
N
That
was
me
I
mean,
maybe
I'm
being
mean
on
myself,
but
we
just
missed
it.
It's
okay.
We
can
fix
this
now
and
then
also
in
rfc
8624,
which
this
working
group
just
recently
did.
We
talked
about
goss
being
may,
but
we
don't
talk
about
any
other
national
algorithms
either.
You
know
that
might
come
down
the
line.
So
that's
what
we've
got
before
next
slide,
which
is
the
last
slide.
N
So
what
this
draft
does
is
simply
updates
rfc
6014
to
make
all
of
the
algorithms
rfc
required.
You
know
so
so
that
all
of
the
rr
types
are
the
same
and
it
that
will
cut
will
update
rfc
8624
to
automatically
make
any
of
these
non-standard
track.
Algorithms
may
implement
yeah.
That's
it
that's
just
essentially,
let's
regularize
things,
so
that's
it
for
my
presentation
if
there's
questions
great,
but
if
not,
I
agree
with
the
chairs,
this
is
ready
for
working
group.
B
N
H
H
C
C
V
Excellent,
okay,
great
so
hi
all
I'm
siobhan
and
schumann,
and
I
wrote
a
draft
relatively
new
dot
on
domain
verification
techniques.
We
did
a
survey
and
we
had
some
recommendations
and
yeah.
It's
a
pretty
early
draft,
so
just
curious
what
folks
think
and
yeah
we
have
some
questions
at
the
end
of
the
presentation
for
the
working
group.
V
So
first
question
was
domain
verification
and,
as
you
might
expect
so
many
providers
on
the
internet
use
domain
verification
to
in
order
for
like
to
let
users
kind
of
prove
that
they
control
a
particular
domain
before
granting
them
some
kind
of
access
or
some
kind
of
privilege
associated
with
that
domain.
A
good
example
is:
let's
encrypt,
you
know
you
might
have
a
if
you're
requesting
a
certificate.
V
They
will
ask
you
to
prove
that
you
control
that
domain
by
asking
you
to
you
know,
put
a
dns
text
record
or
something
and
and
if
you
can
do
that,
you
prove
that
you
are
able
you
have
control
over
the
domain
and
then
you
can.
Then
you
issue
a
certificate
for
it.
They
also
have
an
http
based
challenge,
but
for
the
purposes
of
this
draft-
and
you
know
this
presentation-
we
solely
focus
on
dns
challenges
and
deals-
domain,
verification
techniques,
so
yeah.
V
So
one
pattern
is
rdata,
and
this
is
pretty
common,
so
you
mean
you'll
have
like
a
key
value
pair,
so
in
the
left
side
on
the
key
you'll
have
the
service
provider
and
the
value
would
be
the
random
value
being
put
up
so
rfc
1464
kind
of
specifies
how
you
can
use
key
value
pairs
in
in
the
text
our
data.
This
is,
this
is
a
really
common
pattern
that
that
shows
providers
use
another
another
way
of
doing
this
is
putting
a
label
to
the
left
of
the
domain
you're
verifying.
V
So
you
know,
let's
encrypt
does
this
so
does
github,
so
you
kind
of
say
you
know,
underscore
service
provider
dash
challenge,
dot
the
domain,
you're
verifying
and
then
under
that
label
you
put
you
put
like
a
random
value,
and
so
the
acne,
so
rfc
855,
actually
has
really
clear
requirements
about
what
the
you
know
about
the
random
value
and
also
extremely
clear
about.
When
can
when
can
it
be
deleted?
Github
is
also
extremely
clear.
V
Like
it's
a
seven
day
expiry
on
the
on
the
random
value,
you
have
to
wait
for
72
hours
and
then
you
can
delete
it.
I
think
these
are
good
examples
and
we
kind
of
go
into
this
in
the
recommendations
part
as
well
so
another
another
example
is
just
when
folks,
don't
add
any
kind
of
information
to
to
the
to
the
dns
like
verifying
domain
verifying
record.
So
it's
just
you
know
a
random
value,
random
text,
value
and
cnn.
V
So
apart
from
text
based,
there's
also
cname
based
ways
of
doing
domain
verification-
and
this
is
kind
of
this-
is
often
a
fallback
option,
so
it
might
be
used
if
the
domain
name,
for
example,
already
has
a
cname
and
since
c
names
can't
coexist
with
other
records.
So
you
you
know
this
is
like
a
callback
option
and
in
this
you
point
to
a
service
provider
property.
V
So
if
you
take
a
look
at
an
example,
you
put
a
random
value
to
the
left
of
your
domain,
and
then
you
point
that
via
cname
to
to
like
again
the
random
value
dot,
the
you
know
of
the
service
provider
that
you're
you're
trying
to
verify
that's
trying
to
get
right
right
on.
So
this
is
yeah.
This
is
like
kind
of
like
I
mentioned,
like
it's
a
fallback
option
of
the
tx
of
the
text
record
option,
but
but
it's
not
as
common.
Not
everyone
supports
it.
V
V
This
is
basically
what
let's
encrypt
and
github
already
do,
where
you
put
a
label
to
the
left
of
it
and
you
can
and
with
it
will
be
like
an
underscore
label
and
it
basically
allows
the
service
provider
to
get
only
the
records
that
they
need
and
because
the
issue
is
that
I
think
I'll
put
an
example.
If
you
do
like
cnn.com
for
text
records,
I
mean
you
know
it's
pretty
huge
response
that
you
get
back
and
that's
not
uncommon.
V
So
the
second
thing
that
is
also
important
is
time
bound,
checking
like
or
basically
guidance
on
what
the
expiry
is
or
when
the
text
records
can
be
or
senior
records
can
be
deleted.
They're
often
like
anecdotally,
we've
seen
at
least
one
case
where
you
know
because,
like
a
like
a
corporation,
an
enterprise
actually
lost
access
to
the
service
they
were
paying
for
because
they
were
going
through
a
clean,
cleanup
process
and
deleting
old
text
records.
And
you
know
they
thought
that
oh
it's
already
verified.
V
So
we
can
delete
it,
but
it
turns
out
that
that
domain
was
being
continuously
checked.
For
so
that
caused
a
little
bit
of
an
outage,
and
this
is
seems
to
be
quite
common.
So
our
recommendation
is
that
it
should.
The
service
provider
should
be
extremely
clear
about
when
the
dns
record,
that
is
doing,
the
verification,
can
be
deleted,
and
we
also
talk
about
whether
it's
advisable
for
the
records
to
exist
in
perpetuity,
because
some
service
providers
do
recommend
that.
V
But
we
couldn't
really
find
any
reasoning
or
rationale
or
security
guarantee
that
comes
from
that,
so
so
yeah.
So
we
actually
kind
of
say
that
there's
no
need
for
it
to
be
just
to
exist
forever,
and
you
should.
You
should
probably
say
that
say
that
you
can
delete
it
in
like
a
after.
The
verification
is
done
essentially,
and
we
also
talk
about
the
nsx,
and
we
say
that
the
dns
should
be
used
to
prevent
scooping
attacks.
V
So
this
is
kind
of
what
we
have
in
the
draft
right
now
and
some
feedback
we've
gotten
has
been
that
you
know.
If
there's
no
dns,
then
maybe
another
way
of
doing
validation
could
be
in
like
using
multiple
vantage
points,
which
is
actually
done
right
now
by
let's
encrypt,
and
they
have
a
paper
on
this.
It
sounds
like
a
good
idea.
One
thing
to
think
about
is:
should
there
be
an
inl
registry
for
underscore
prefixes?
So
in
the
let's
encrypt
example,
this
you
know
an
underscore
academy
challenge.
V
Should
you
have
like
a
reserved
keyboard
keyword
over
there
to
us
to
prevent
collisions?
Yeah.
That's
that's
an
idea.
Thirdly,
like
we
also
do
verify,
should
kind
of
make
sure
that
we
should
not
accept
a
request
to
verify
a
domain
at
or
above
a
public
suffix
boundary
for
security
reasons,
so
they
should
be
mindful
of
that,
and
we
couldn't
really
find
an
example
of
a
service
provider
that
doesn't
conform
with
this,
but
it
just
seems
like
that,
should
be
there
and
is
yeah.
V
Another
important
thing
to
keep
in
mind
is
the
domain
verification
just
for
the
domain
or
for
everything
underneath.
So
I
think
so.
For
example,
google
webmaster
tools
is
for
everything
underneath
but
like
all
sub
domains,
underneath
the
way
that
you're
verified,
but
something
like,
let's
encrypt,
would
be
just
for
that
domain.
V
And
lastly,
like
do
we
need
a
new
arrow
type
for
this.
It's
probably
controversial
and
probably
would
not
be
in
this
track,
which
kind
of
leads
us
into
the
next
slide,
which
is?
Does
the
working
group
want
to
adopt
this
track,
and
would
it
be
informational
which
is
kind
of
how
we're
pitching
it
right
now,
as
a
survey
and
some
recommendations
and
yeah
other
other
topics
of
this?
That
folks
would
like
this
job
to
discuss
and
yeah
that's
about
it
I'll
leave
this
slide.
H
Sure,
there's
somewhat
man
in
the
middle
attack.
There
is
that
if
there,
if,
when
challenging
you
up
for
something,
is
malicious,
then
they
could
in
fact
be
man
in
the
middling,
a
challenge
from
yet
another
provider
that
is
important
to
you
and
getting
you
to
publish
something
that
somebody
challenged
them
with
and
then
taking
over
your
domain,
essentially
for
something
you
didn't
anticipate.
H
Github
wants
to
take
over
my
domain
for
for
in
person
for
convincing
google
that
they
control
my
domain.
I
go
sign
up
for
some
github
service
and
they
give
me
a
challenge
and
I
publish
the
challenge.
They
asked
me
to
publish,
but
it's
in
fact
a
google
challenge
to
github
that
they
replayed
to
me,
and
then
I
publish
it
and
now
they
own
my
domain.
As
far
as
google
is
concerned,
this
perhaps
somewhat
unlikely
in
most
cases,
but
I
think
it's
a
real
issue.
Potentially
I.
V
H
W
L
Hi
benjamin,
I
support
this.
I
think
it's
worth
adopting.
I
do
think
that
it
merits
a
lot
more
security
attention.
I
think
it'd
be
interesting
to
really
have
have
some
some
security
review
from
from
security
experts.
Here,
there's
a
few
different
things
I
can
think
of
that
that
stick
out
one
of
them
is
that
some
of
these
challenges-
most
of
them
currently.
F
F
L
F
L
L
V
B
B
B
V
J
Okay,
great
hello,
I'm
orange
from
the
swedish
internet
foundation,
and
this
is
a
joint
work
with
schumann
and
steve
crocker,
eric
osterweil
and
a
few
other
people,
and
we
have
presented
the
multi-signer
document
in
the
last
itf,
and
this
is
a
short
update.
Next
slide,
please
so
we
have
been
busy
testing,
and
so
what
we
have
done
is
to
to
list
the
capabilities
that
we
need
for
multisigner
to
work
and
which
is
basically
add.
J
Dns
keys,
remove
dns
keys
where
you
don't,
where
the
server
actually
doesn't
have
access
to
the
private
part
and
then
add
and
remove
cds
or
cdns
key
records
and,
lastly,
the
csync
records,
and
so
we
tested
this
with
different
softwares
and
we
tested
this
on
the
command
line,
with
the
dynamic
dns
and
with
the
rest
api.
And
you
know,
some
of
this
is
okay
when
there's
a
bind
and
not
don't
have
a
rest
api.
J
J
So
we
moved
on
to
some
dns
service
providers
and
so
the
eseg
dot
io
is
actually
supporting
this,
and
I
got
the
confirmation
this
week
that
they
actually
now
support
the
csync
records
too.
So,
and
I
come
back
to
this
a
little
bit
later,
so
we
and
we
are
in
talks
to
ns1
and
nustar
to
implement
this,
and
if
you
are
responsible
for
any
other
dns
provider,
we
would
be
happy
to
talk
to
you
and
run
some
tests.
J
J
For
in
some
steps,
there's
some
workarounds
needed.
Sometimes
you,
you
know
you
you
have
to
import
the
ksk.
Also
it's
not
really
necessary,
but
you
know
you
do
what
you
have
to
do
to
make
it
work
and
what
we
have
not
tested
yet
is
the
key
rollover
or
the
algorithm
all
over.
That
is
something
that
we
still
need
to
do
and
next
slide.
Please.
J
Yes,
so
and
what
and
then,
additionally,
we
have
done
an
implementation.
We
have
implemented
a
controller
that
actually
runs
the
whole
algorithm
and
it
supports
dynamic
updates
with
powerdns
and
with
the
desegrest
api,
and
it
is
under
active
development
and
yeah.
We
we
would
be
happy
to
implement
other
interfaces
to
other
service
providers,
so
authoritative
service
software
and
then
the
next
slide.
Please,
yes,
so,
and
then
we
have
the
draft,
there's
the
link
to
github
where
we
work
on
it.
J
You
know
to
be
more
specific:
we
added
the
algorithm
for
the
rollover,
key
rollovers
and
actually
also
for
the
algorithm
rollover
and
and
then
we
added,
I
added
the
section
about
explaining
why
all
signers
need
to
have
a
common
set
of
algorithms
they
and
yes,
and
we
would
like
to
ask
the
working
group
if
this
is
something
that
working
group
could
you
know,
work
on
adopt
and
in
that
case,
what
statues?
The
document
should
have.
U
So
godaddy
is
definitely
interested
in
supporting
the
multi-signer
were
also
advocates
of
supporting
cds,
tdns
key
via
the
registrar,
where
the
registrar
pulls
the
registrants
and
then
submits
through
ep
to
the
registry
and
there's
another
proposal,
which
is
the
bootstrap
proposal
that
we're
going
to
also
be
advocating
for
advancement
of,
and
I
think
that
ties
in
on
the
multi-signer
as
a
way
of
bringing
the
second
provider
or
second
and
third
or
whatever,
for
the
pro
purposes
of
getting
the.
You
know
the
diaz
record
at
the
parent.
J
Yes,
yes,
I
think
there
is
actually
we
discussed
this
in
the
last
week
I
was
on
vacation.
I
didn't
discuss
it,
but
I
seen
that,
but
there
was
a
discussion
about
currently
in
the
in
the
draft.
It
says
the
the
signers
need
to
establish
trust
and
that's
of
course,
easily
written
but
harder
done,
and
so
we
think
that
the
boost,
rep
might
be
a
way
to
you
know,
establish
the
initial
trust
between
signers,
yes,
yeah.
Thank
you.
Yeah.
B
K
Schumann,
okay,
how
do
I
enter
the
queue
all
right
I
mean
so
I
I
I
just
wanted
to
just
provide
some
information.
The
bootstrap
document
that
brian
and
you
were
talking
about
this
is
peter
thomas
document
right.
I
I
don't
think
I've
seen
any
discussion
about
that
on
the
mailing
list
yet,
but
I
think
it's
an
interesting
idea
and
we
should
discuss
it
in
more
detail.
Just
a
general
comment
to
the
community.
F
B
J
K
K
B
B
C
E
C
Q
B
N
Q
All
right,
my
mistake,
sorry
go
ahead,
no
worries,
I
just
wanted
to
clarify
for
the
audio
and
and
whatever
next
slide,
please.
So
we
just
have
some
changes
from
feedback
that
we
got
from
the
working
group.
At
the
last
presentation,
the
big
the
big
question
was
how
to
mitigate
forgery
of
the
e
dns
zero.
That's
sent
back
so
next
slide.
Q
So
a
little
background
on
what
we're
sending
here
is
a
uri
template
that
comes
back
in
edns
zero
and
it's
how
to
prevent
that.
Uri
template
from
being
some
bogus
thing,
pointing
off
to
never
never
land
or
pointing
off
to
some
victim
or
something
scary
in
in
those
sorts
of
categories.
Next
slide,
please!
Q
Q
For
example,
if
they're
both
you
know,
if
it's
doh
there's
a
higher
likelihood,
but
instead
of
worrying
about
certificates
and
all
that
stuff
was
just
an
fqdn
comparison
and
of
course
you
know
a
successful
tls
handshake
with
that
host,
and
that
was
it.
The
other
second
bullet
is
kind
of
a
nice
side.
L
So
and
that's
not,
you
know
because
it's
been
overlooked,
that's
because
the
the
browser
experts
who
have
participated
have
raised
a
series
of
serious
technical
and
security
concerns
with
this
approach.
So
I
I
don't
support
adoption.
I
think
that
if
we
wanted
to
move
forward
with
this,
we
would
need
to
see
some
some
actual
client-side
interest
and
and
some
some
changes
to
the
draft
that
that
make
it
appealing
to
to
implement.
In
that
context,.
Q
Q
Right
now,
it's
currently
structured
as
a
companion
to
the
the
previous
document.
Obviously
we
can
move
text
around
as
necessary,
but
what
this
is
is
parsable
json
and
the
the
client
logs
it
or
displays
it
or
does
whatever
it
wants.
You
know
complains
to
a
greater
authority
with
once
it
receives
that
json
to
figure
out
what
to
do
instead
of
you
know,
showing
it
to
the
user,
probably
a
better
solution
for
headless
next
slide.
Please.
Q
And
the
the
mechanism
that
that
is
in
the
this
draft
with
json
also
allows
multiple
filters
for
different
reasons
or,
for
the
same
reason,
filtering
different
things.
But
the
example
here
that
I
I
built
for
the
slide
deck
was,
if
there's
some
commercial,
dns
filter,
doing
court,
ordered
filtering
or
government,
ordered
filtering
for
pornography
or
or
whatever,
and
then
there's
an
it
operated.
Filter,
that's
filtering
for
malware,
because
they
have
a
different
interest
than
what
the.
Q
Q
The
idea
is
to
to
hopefully
reduce
the
calls
coming
back
into
I.t
or
coming
back
into
that
commercial
dns
filter
operator
for
for
being
overly
zealous
in
their
filtering
next
slide.
Please
and
some
of
the
deployment
considerations
that
are
in
here
and
actually
also
in
the
other
draft
that
I
presented
previously,
is
that
filtering
changes-
and
this
is
one
of
the
subtleties
is
that
just
saying
it
was
broke.
Q
The
user
might
figure
that
out
a
couple
of
minutes
later
and
might
complain
to
I.t
a
half
an
hour
later,
because
it
takes
that
long
to
open
a
ticket,
and
then
it
looks
at
it.
You
know
12
hours
later
by
then
the
filtering
is
cleared
and
it's
gone
and
the
user
just
gets
frustrated
with
why
that
happened,
and
and
and
then
it
gets
filtered
again.
Q
Seven
days
later
and
and
all
sorts
of
you
know
fun
stuff
like
that,
so
there's
some
encouragement
text
in
there
that
there's
enough
information
to
allow
it
and
to
allow
that
upstream
filter
operator
to
trace
back
to.
Why
were
we
filtering
it
back
when
we
filtered
it,
even
though
we
no
longer
are
or
we've
changed,
the
category
of
the
filter
of
the
filter
or
we've
changed?
You
know
how
severe
that
this
customer
is
getting
filtered
versus
another
customer.
Q
All
the
reasons
that
these
filters
change
is
to
provide
that
in
the
uri
or
in
a
sequence
number
or
in
a
database
or
something
how
that's
done
is
out
of
scope,
because
the
protocol
doesn't
care,
but
it's
it's
necessary
for
user
satisfaction.
Next
slide,
please
and
that's
about
it,
there's
one
comment
from
ecker
on
the
list
that
was
positive
on
this
draft:
I'm
not
aware
of
anyone
else
reading
it,
which
is
why
I
was
interested
in
presenting
it
so
certainly
like
to
hear
feedback
on
the
list
or
hear
feedback
here
in
the
meeting.
L
F
L
Okay,
gotcha,
I
I
see
what
you're
saying
okay
like
I
would
like
to
see
this.
I
would
like
to
see
some
amount
of
harmonizing
this
with
http
451,
okay,
which
has
which
already
addresses
some
of
these
issues
and
has
its
own
tiny
taxonomy
for
describing
some
of
this
kind
of
stuff,
so
I'd
suggest
taking
a
look
there.
L
L
B
H
Q
X
X
X
S
Okay,
well,
first
of
all,
I
think
this
is
a
better
approach
than
the
original
one.
I
think
that
a
structured
set
of
data
can
can
bring
in
more
clients.
So
it's
this
isn't
just
appealing
for
browsers.
I
mean
this
could
be
easily
used
by
iot
network
stacks
or
by
security,
apps
run
by
security
and
corporate
security
vendors.
S
I
mean,
I
think
it
would
just
be
easy
to
stuff
the
json,
or
at
least
the
key
parts
of
the
json
into
the
edns
response,
and
in
this
way
you
couldn't
well
avoid
having
to
implement
an
http
stack
in
the
client
and
and
also
the
entire
mechanism
would
be
easy
and
you
would
offer
less
surprise
for
attacks.
So
I
I
second
also
the
comment
that
ben
schwartz
was
supposed
to
make.
S
S
So
I
mean
I
think
that
these
are
problems
that
we
can
address,
so
at
least
that
are
worth
discussing
more
in
a
working
group
discussion.
If
we
adopt
these
these
documents
and
in
terms
of
analyzing
dns
filters,
I
think
that
we
will
possibly
never
get
to
agreement.
Whether
I
mean
that
there's
people
that
think
that
dns
filter
is
the
best
thing
ever
invented
and
other
people
thinks
it's
really
horrible.
M
Hey
john
reed
akamai,
I
I
agree
with
that.
I
would
like
to
see
us
adopt
this
and
work
on
any
concerns.
In
particular,
I
think
you
could
minimize
the
response
by
possibly
even
avoiding
the
reason
for
the
categorization,
because
the
end
of
the
day
doesn't
really
matter
what
matters
is
to
get
a
clear
signal
that,
yes,
this
was
intentionally
blocked
and
here's
who
to
go
call
to
fix
it
and
I
think,
providing
that
clear
data
in
a
structured
manner
is
incredibly
valuable,
particularly
to
operators.
M
You
know
again,
we
can
continue
to
have
a
debate
about
whether
or
not
dns
should
be
a
control
plane.
The
reality
is,
it
is,
and
it's
a
service
that
many
people
have
explicitly
opted
into
in
the
isp
market.
You
know
setting
aside
enterprises
and
schools,
there
are
people
who
have
paid
money
to
their
isps
to
say.
Yes,
I
want
this
feature
and
I
don't
think
it's
right
for
us
to
say.
Well,
you
know
we
don't
agree
with
it,
so
we're
not
going
to
legitimize
it
or
normalize
it.
Y
I
pretty
much
agree
with
what
mr
reed
was
saying.
I
also
think
that
adopting
this
draft
will
help
in
to
get
a
lot
of
people
like
working
together
towards
these
concerns.
Specifically,
the
security
concerns
that
ben
mentioned
getting
a
move
on
how
to
prevent
this
from
potentially
being
misused
and,
at
the
same
time,
also
agreeing
with
what
reid
said.
I
also
failed
to
see
how
providing
legitimate
information
on
cases
where
content
has
been
censored
or
blocked.
I
also
fee.
Y
I
also
fail
to
see
how
that
normalizes
censorship
itself.
I
actually
think
it's
it's
actually
quite
the
opposite.
I
think
that
promoting
or
giving
access
to
information
that
allows
users
to
have
an
informed
choice
of
the
services
that
they
are
subscribing
to
or
that
they
are
paying
or
whatever
and
empowering
that
informed
consent
actually
works
against
against
those
concerns,
I
mean
I
actually
see
that
as
a
positive
point
of
view,
instead
of
the
negative
one,
if
that
makes
sense,.
Z
Very
continue:
the
trend
of
agreement.
I
completely
agree
with
jonathan
vittorio
and
joey.
This
is
a
positive
development
from
a
sort
of
user
experience
perspective.
We
should
absolutely
be
encouraged
and
it'll
be
fantastic
to
see
it
adopted
by
the
working
group
and
further
progress
made
so
yeah.
I
don't
see
the
downsides
more
transparency,
better
user
experience,
all
of
which
seems
like
the
right
thing
to
do.
Q
N
I
can't
disagree
more
than
with
andrew
saying
this
should
be
pretty
easy.
This
is
not
easy.
It
absolutely
involves
a
lot
of
trade-offs.
It
certainly
involves
a
lot
of
trying
to
balance
the
understanding
of
the
people
who
are
doing
the
blocking
or
filtering
or
whatever,
against
the
users.
Users.
Inherently
don't
understand
this.
That's
why
we're
discussing
this
at
all.
N
X
X
X
It
also,
I
think,
potentially
creates
a
attractive
nuisance
once
there's
a
set
of
documents
explaining
how
you
signal
this,
I
think
it
becomes
very
easy
for
governments
etc
to
say
you
know
there
is
a
well-known
way
to
do
this.
It's
blessed
by
the
ietf.
Just
go,
do
this
and
send
this
code,
so
I
think
just
sort
of
more
warning
warning
be
careful
why
the
discussion
needed
and
again
that
was
you
know
no
hats.
B
Yeah,
I
think
we've
had
that
tension
before
between
whether
documenting
something
implies
endorsement
necessarily,
or
that
is
something
we
can
reasonably
do
in
order
to
promote
caution
and
allow
non-consenting
adults
a
way
out
of
doing
things
they
don't
want
to
do.
You
know
we've
been
through
that
with
previous
drafts,
some
of
which
became
rfcs,
some
of
which
did
not
but
yeah.
That's
an
important,
important
aspect
of
things.
Z
Things
like
content
filtering
to
block
malware
are
well
established
mechanisms.
There
are
plenty
of
geographic
markets
where
the
majority
of
users
voluntarily
opt
in
to
dns
filtering
for
services
like
malware
filtering
for
parental
controls
and
so
on,
yeah.
I
think
we
just
need
to
face
facts
and
that
this
exists
and
surely
it's
useful
for
the
user
experience
to
actually
provide
meaningful
information
when,
as
joey
has
observed,
more
transparency
actually
makes
it
harder
for
for
the
more
sort
of
badly
intended
sort
of
censorship
type
activities.
B
Thank
you.
I
think
warren
and
and
paul
also
were
right
as
far
as
applying
a
lot
of
thought
to
whether
we
want
to
consider
this
and
whether
dnsop
is
the
right
place
and
how
to
make
sure
that
we
get
the
cross-area
review
we
need.
So
the
chairs
will
we'll
be
discussing
that
and
we'll
take
it
to
the
mailing
list.
B
So
we
are,
I
think,
done
for
the
session
for
dns
obsession,
one
for
itf
11..
We
can
give
everybody
10
minutes
back
of
your
day.
We
have
another
session
in
the
last
the
last
session
on
thursday
16
30
to
17
30
utc,
and
we
will
be
discussing
some
of
the
prioritization
things
in
the
polling
that
we've
done
as
far
as
managing
the
working
group
work
workload
so
see
you
then,
and
thanks
very
much
for
your
time
today,.
N
X
N
Very
good
just
wanted
to
make
sure
that
that
was
the
case
that
we
weren't
trying
to
do
some
waiting
on,
given
that
the
tls
working
group
doesn't
even
have
it
in
working
group
last
call.
I
would
like
to
see
it
since
the
esi
stuff
is
not
a
major
part
of
it.
I
would
like
to
see
implementation
be
able
to
move
forwards
without
it.
Thanks.