►
From YouTube: IETF113-ADD-20220324-1330
Description
ADD meeting session at IETF113
2022/03/24 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
Hey
good
morning
to
the
deprived
chairs,
I
don't
see
your
slides
in
the
slide
set
for
the
the
session.
Are
you
guys
all
set
with
your
slides,
hey,
glenn,
yeah
yeah,
we're
all
flat.
Okay
just
wanted
to
make
sure
everything
was
okay
and
I
didn't
need
to
approve
anything
for
you.
A
Well,
I
got
a
travel
voucher.
You
can
approve,
oh
it's
so
approved
and
put
a
little
something
on
for
yourself.
On
that
awesome
I
didn't
know
all
the
power
is
to
actually
pay
it,
but
I
approve
it
you're
in
the
same
boat.
I
am.
C
Okay:
okay:
this
is
a
pre-announcement
before
the
the
chairs
will
open
the
working
group.
So
this
is
combined
deprived
atd
working
group,
meaning
the
chairs
are
all
remote.
So
alexander
and
myself
are
delegates
just
to
make
sure
that
if
there's
something
unfortunately
happens,
we
can
jump
in
and
help
them
out,
but
it's
it's
run
by
the
chairs
remote
and
please
scan
the
quad
code
because
we
use
it
also
as
the
blue
sheets.
So
please
register
yourself
and
again
if
you
want
to
go
to
the
mic,
create
your
hand
on
your
mobile
app.
C
B
All
right,
why
don't
we
go
ahead
and
get
started
as
as
benno
said,
this
is
this?
Is
the
joint
meeting
of
d5
and
add
and
I'm
brian
haberman,
along
with
with
tim,
we're
the
co-chairs
of
deprived
and
first,
I
want
to
thank
vanilla
and
alex
for
for
taking
our
spots
at
the
front
of
the
room.
They're,
probably
doing
you
know
all
the
hard
work
and
we
get
to
sit
in
our
offices
and,
just
you
know,
rattle
rattle
off
on
different
topics.
B
Just
as
a
note,
you
know
we
do
have
the
jabber
room
going
through
roomie
deco,
so
feel
free
to
have
whatever
back
channel
conversations
you
want
to
have
eric
is
probably
floating
around
somewhere.
He
is
our
a.d
who
keeps
us
in
line.
I
don't
know
how
and
the
minutes
are
at
that
link.
B
Tim
will
be
keeping
the
minutes,
but
he
will
always
appreciate
any
additions
to
those
minutes
as
we
move
along
next
slide.
Please
no
well,
given
that
this
is
third
day
the
iehf
meeting.
I
hope
everybody
has
seen
this
and
read
these
documents.
It's
basically
giving
you
all
the
the
process
guidelines
for
for
how
we
operate
and
the
things
that
you
have
to
understand
about
ietf
policy.
So,
if
you
haven't
read
these,
please
go
read
them,
especially
the
code
of
conduct
next
slide.
Please.
B
I'm
not
going
to
read
these.
These
are
just
called
out
for
everybody
understands.
You
know
what
we're
asking
as
we
as
we
move
through
the
meeting.
One
key
thing
here
that
I'm
going
to
highlight,
though,
is
is
the
make
sure
that
you
identify
yourself
when
you're
speaking
with
the
with
this
hybrid
mode,
making
sure
people
both
you
know
on
meet
echo
and
in
the
meeting
room
know,
who's
speaking
will
make
much
easier
for
people
understand
next
slide.
Please.
B
A
couple
of
tips
benno
actually
touched
on
one
of
those
for
those
for
the
insight
people
about
you
know
being
able
to
sign
into
the
session
the
other.
The
other
key
thing
here
will
help
move
this
meeting
along
very
quickly
and
efficiently
is,
is
using
meet
echo
to
join
the
mic
queue,
so
we
know
who
to
call
on,
as,
as
we
have
topic
discussions.
B
Other
things
I
think
are
are
pretty
self-explanatory.
If
you
have
any
problems,
you
know
feel
free
to,
let
us
know
or
one
of
the
meat
echo
or
the
secretariat
folks
and
they'll
help
you
out
next
slide.
Please.
B
All
right
so
a
relatively
light
agenda
for
for
deprived
today
we're
going
to
do
a
quick
update,
we'll
have
a
an
on
the
fly
discussion
of
the
unilateral
probing
draft.
We
had
a
little
bit
of
a
mix
up
with
getting
slides
submitted,
but
we
do
have
the
authors
here
to
talk
for
a
few
minutes
about
that
and
then
tim
and
I
are
going
to
raise.
You
know
some
discussion
points
for
what
we
want
to
do
next
within
deprive
itself
any
comments.
Questions
proposed
changes
to
this
agenda
before
we
move
on.
B
Okay,
next
slide,
please.
So
what
are
we
working
on?
If
you
want
the
details?
Welcome
to
the
data
tracker,
it
shows
you
all
the
fun
things
that
deep
private
has
been
doing
current
state
of
affairs
and
all
that
fun
stuff.
B
B
I
want
to
thank
not
only
sarah
christian
and
allison
for
for
their
efforts
in
in
you
know,
moving
this
document
through
the
working
group.
I
also
appreciate
all
the
comments
and
feedback
that
the
working
group
has
given
and
the
hard
work
that
eric
and
the
isg
members
provided
in
order
to
to
get
this
done.
So
thanks
to
everyone
that
is
now
for
the
most
part
off
our
plate
and
should
be
in
rfc
relatively
soon,
and
then
we
also
adopted
the
the
unilateral
probing
document,
I'm
going
to.
B
Let
dkg
talk
about
that
for
for
a
few
minutes.
The
big
thing
that
I
want
to
make
sure
everybody
understands
is
that
this
document
has
actually
been
marked
as
taking
the
place
of
the
unauthenticated
draft
that
paul
and
peter
were
working
on.
So
this
will
be
the
main
focus
of
the
working
group
moving
forward.
I
do
want
to
thank
you,
know,
paul
and
peter
for
the
effort
they
put
into
that
other
draft
and
and
they
were
actually
the
ones
who
suggested
that
that
this
one
replaced
their
work.
B
D
Yeah
so
joey
salazar.
Can
you
all
see
the
slide
that
I'm
presenting
there
sorry
for
the
not
having
uploaded
it
earlier?
Yeah.
E
D
And
I
put
this
draft
together,
trying
to
document
reasonable
policies
that
can
be
adopted
without
much
coordination
for
the
second
encrypting,
the
second
hop
of
the
dns
traffic.
D
We
don't
mean
this
to
necessarily
replace
their
work,
but
we
see
it
as
a
sort
of
more
of
a
formalization
of
the
kind
of
work
that
we've
been
talking
about,
and
we
encourage
the
folks
who
have
worked
on
the
other
drafts
that
this
is
marked
officially
as
superseding
to
join
us
in
contributing
to
it.
So
in
particular,
we
want
to
think
about
both
sides,
what
the
recursive
resolver
and
what
the
authoritative
servers
can
do
without
worrying
about
any
kind
of
signaling.
D
We
think
the
best
that
you
can
do
here
is
protection
against
passive
attackers
and
the
basic
rules
are,
you
know,
authoritative
servers
can
listen
using
dot
or
doq,
and
recursive
resolvers
can
probe
by
authoritative
ip
address
for
dot
and
doq,
and
not
worry
about
authentication
failures.
D
So,
but
doing
this,
of
course
it
adds
a
few
concerns
specifically
about
the
additional
latency
about
resource
consumption,
on
both
the
recursive,
recursive,
resolvers
and
authoritative,
servers
and
potentially,
of
course,
if
this
doesn't
work
that
there
will
be
some
data
leakage.
So
we
try
to
provide
specific
guidance
for
what
to
do.
D
We
do
not
cover
probing
for
doh
because
of
the
path
requirement
which
makes
it
non-obvious
as
to
how
to
see
whether
the
authoritative
server
offers
doh,
and
we
don't
cover
how
to
do
signaling,
because
again,
this
is
unilateral.
This
is
something
that
doesn't
need
a
signal
to
do.
You
can
just
try
to
do
it.
D
We
do
try
to
outline
what
kinds
of
signaling
you
would
need
in
order
to
get
better
protection,
but
that's
that's
relatively
small
part
of
the
draft
and
we're
not
attempting
to
define
any
signaling
mechanisms
here
or
even
say
how
you
would
use
them
specifically.
D
The
main
changes
that
we've
seen
thanks
to
feedback
from
several
people
on
the
mailing
list
and
privately
we've
adjusted
some
of
the
parameters.
Obviously,
the
adoption
is
is
a
big
change,
but
we've
adjusted
some
of
the
parameters
in
the
proposed
algorithms
to
be
better
tuned
to
be
to
specifically
avoid
excess
resource
consumption
and
excess
latency
we've
tried
to
clarify
the
rationales
for
some
of
these
choices
and,
in
particular
dealing
with
how
they
might
interact
with
pools.
D
We
hope
that
those
clarifications
are
useful,
but
maybe
there
are
some
still
I'm
sure.
People
who
read
this
and
attempt
the
deployment
will
give
feedback.
I
hope
they'll
get
feedback,
I'm
sure
that
they'll
discover
things
that
they
understand
better
after
deployment
than
they
understood
just
from
reading
this,
and
so
I
want
to
encourage
folks
to
try
implementing
this,
both
if
you're,
an
authoritative
if
you're
deploying
an
authoritative
server
or
if
you
are
working
on
a
recursive.
D
You
know
we
encourage
people
to
try
this
out
and
give
feedback
to
the
draft
about
what
gator
didn't
make
sense.
There's
two
sort
of
open,
fixed
musing.
The
document
one
of
them
is
about.
D
I
think
that
is
the
main
thing.
This
is
about
sort
of
the
history
of
other
work.
That's
gone
into
this
and
again,
you
know
our
goal
here
is
not
to
to
claim
that
any
of
these
other
insights
and
these
other
drafts
is
wrong,
but
rather
to
provide
concrete
guidance
to
implementers,
and
we
hope
that
other
people
who've
done
this
kind
of
work
will
will
join
us
on
this
draft
so
yeah.
So
we
would
love
to
see
more
comments
and
review
on
the
mailing
list.
We're
doing
this.
D
It's
on
git
lab,
actually
not
github,
so
happy
to
have
issues
and
pull
requests
or
merge
requests
there
and,
of
course,
substantive
discussion
does
belong
on
the
mailing
list
as
usual.
So
I
think
that's
all
the
slides.
We
will
upload
a
copy
of
these
slides
to
the
data
tracker.
F
Hi
this
is
paul
hoffman,
so
I'm
one
of
the
two
co-authors
on
one
of
the
previous
drafts,
and
I
want
to
be
super
clear
that
peter
and
I
I
don't
normally
speak
for
people
but
peter's
in
my
other
window
here-
are
fully
supportive
of
this
draft
and
for
people
who
haven't
been
following
or
got
confused
because
it
took
so
long
to
get
to
this
point.
F
The
main
reason
that
we
are
very
happy
with
this
draft
and
more
than
ours
is
we
could
not
get
traction
on
ours
from
the
wide
audience
of
the
working
group.
That
is
the
people
who
insisted
on
strong
signaling
would
not
contribute
on
weaker
signaling.
F
The
people
who
wanted
sort
of
mid-level
signaling
were
not
able
to
contribute
on
the
higher
or
lower
so
by
going
to,
and
so
when,
when
dkg
and
joey
came
up
with
this
draft,
we
were
like
oh
okay,
completely
different
than
where
the
working
group
was
bringing
us,
but
maybe
this
will
get
interest
and
it
obviously
did
so
we're
really
happy
with
it.
I
will
contribute
my
biggest
thing
that
I
would
say
right
now
is.
F
I
would
say
that
that
the
working
group
would
is
likely
to
only
finish
if
we
get
rid
of
any
signaling
at
all
in
this
current
document,
if
we
don't
even
have
whiffs
of
signaling.
That
is
that
I
I
believe
that
signaling
could
come
later,
but
only
after
the
folks
who
want
the
signaling
and
have
figured
out
exactly
what
their
requirements
are,
not
how
to
do
the
signaling.
F
But
what
is
the
requirement
of
it,
which
is
what
ecker
had
gotten
at
initially,
although
he
didn't
run
down
that
the
road
too
far
on
it,
but
with
the
the
adot
document
was
saying,
we
need
to
figure
out
what
you
know
what
level
of
security
is
needed.
I
would
say
for
for
the
current
work
rip
it
all
out,
don't
even
point
towards
a
possible
future,
because
the
future
could
come.
People
could
come
with
new
document
and
peter,
and
I
are
not
intending
to
do
that.
F
We
mostly
went
with
the
signaling,
because
that's
what
the
working
group
seemed
to
be
asking
for.
I
was
personally
now
because
I'm
not
sure
that
peter
agrees,
but
I'm
totally
happy
with
signal
free.
I
think
that
this
will
get
us
going
and
will
lay
down
a
good
framework
for
anybody
who
feels
that
they
want
to
add
signaling
to
this
so
yeah.
Now,
I'm
we're
really
happy
that
this
is
happening.
F
F
But
if
you
know,
since
some
people
really
don't
like
doing
issues
list
themselves,
that
the
authors
take
any
issues
that
appear
de
novo
on
the
mailing
list,
stick
them
in
git
lab
and
that
way
we
do
the
tracking,
because
what
we
really
you
know
a
thing
that
peter
and
I
that
came
to
us
was
we
didn't.
F
We
didn't
have
any
signal,
sorry
for
the
pun
there
of
when
issues
were
closed,
so
having
them
open
and
close
on,
get
get
lab
will
really
help
on
getting
at
for
the
chairs
to
know
when
we're
ready
for
a
working
group
last
call
so
anyway.
Sorry,
I'm
blathered
on
about
a
document
that
I'm
no
longer
author
on,
but
we
are
really
happy
with
the
current
document.
So
thank
thanks
to
dkg
and
joey
for
doing
that.
D
Thanks
paul,
I
just
want
to
say,
like
the
draft
is
very
clear
that
it's
trying
is
deliberately
not
specifying
signaling,
I
mean
the
name.
Unilateral
implies
that
there
really
isn't
any
signaling
to
do
the,
and
I
wanted
to
briefly
respond.
Martin,
sorry,
just
before
before
you
you
step
up,
I
see
you
in
the
queue
there
ted
raises
a
concern
in
the
chat
about
musts
that
have
that
that
are
like.
You
must
not
serve
different
records.
Based
on
the
s.
D
I
that's
difficult
for
the
client
to
understand
or
or
detect
right
and-
and
I
wanted
to
explain
why
those
kinds
of
musts
are
in
this
draft.
This
kind
of
draft
is
saying
look.
This
is
the
most
straightforward
way
that
recursive
resolvers
are
going
to
do
this
kind
of
unilateral
probing
and
for
this
to
work,
servers
need
to
also
do
this
other
thing
right.
So
in
some
sense
the
the
only
non-unilateral
part
of
this
proposal
is
assuming
that
both
sides,
the
recursive
resolvers
and
the
authoritative
servers-
do
adopt.
D
You
know
roughly
reasonable
implementations
there
right
that
that
they
adopt
implementations
that
stick
to
these
standards.
Then
it
will
work
if
one
side
doesn't
cue
to
the
standard,
then
the
defenses
against
resource
exhaustion,
the
defenses
against
you
know
the
assuring
that
records
come
back
correctly.
Those
start
to
fall
away.
So
that's
the
that's
the
reason
why
those
kinds
of
musts
are
there.
G
G
I
would
like
to
see
that,
because
of
the
this
gain,
it's
possible
to
do
it
automatically
on
dns.
Without
so
it
might
be
more
useful
to
use
today
over
the
x
5.9.
I
would
see
a
lot.
I
would
like
to
see
there
a
bigger
recommendation
on
that.
D
D
G
Yeah,
I
understand
that,
but
there's
also
some
for
the
smaller.
I
don't
know
how
it's
actually
written
there
that
some
smaller
dns
servers
might
use
a
self-sign
it
so
maybe
also
recommend
there
that
they
could
be
a
better
alternative
to
it.
D
I
think
that
would
belong
in
a
draft
that
that
is
not
opportunistic
right
in
a
draft
that
says
you
know
that
tries
to
to
lock
in
the
security
guarantees,
including
against
active
attackers.
That
would
be
appropriate
and
I
would
support
it,
but
given
that
this
draft
doesn't
lock
in
I'm
reluctant
to
have
it
weighed
into
you
know,
here's
a
recommendation.
You
should
do
this
kind
of
thing,
because
this
draft
doesn't
even
say
like
what
name.
Should
the
client
expect
right
we're
leaving
that
deliberately?
D
This
draft
is
deliberately
agnostic
about
that,
because
we
want
to
say
look
here
is
the
way
to
get
defense
against
passive
monitors
right.
You
could
you
can
do
this
thing
and
you
don't
have
to
worry
about
any
of
the
rest
of
it
and
a
recommendation.
Throwing
a
recommendation
in
here
about
how
to
authenticate
means
that
we're
sort
of
opening
the
door
to
discussions
that
this
draft
isn't
willing
to
contemplate.
D
I
should
be
clear-
I
I
am
with
you
in
the
bigger
picture,
but
I
want
to
keep
this
draft
simple
so
that
people
can
implement
it.
We
can
get
some
experience
and
we
can
see
what
percentage
we
can
get
protect
against
passive
attackers.
Just
doing
the
simple
thing,
and
I
think
that
will
motivate
the
kinds
of
recommendations
that
you're
asking
for
in
other
drafts.
H
You
up
in
the
queue
hey
just
to
emphasize
dkg's
point.
I
don't
think,
there's
any
conflict
here.
If
anything
these
these
fit
together
nicely
self-signed
certificates
are
entirely
compatible
with
dane
yeah
in
in
dany
e-mode.
You
can
just
drop
the
hash
of
that
self-signed
certificate
into
your
dane
record,
and
now
you
have
dane
authentication.
H
So
I
think
the
draft
is
saying
here's
here's,
a
simple
thing
that
you
can
start
with
and
that
will
set
us
up
for
for
future
authenticated
modes
that
are
trickier
to
standardize.
I
Yeah
I
mean-
maybe
I
feel
like
there
are
two.
Perhaps
you
know
three
different
framings
of
this
document,
one
document
one
framing
of
the
previous
emails
ago-
pkg,
namely
that
it's
the
you
know
it's
about,
seeing
how
much
deployment
you
can
get
you
know
with
for
passive
attack
right.
Another
framing
is
that
it's
about
getting
experienced
with.
I
You
know
the
operational
pressures
of
having
increased
the
dns
to
authoritative,
and
the
third
is
that
it's
a
bridge
to
to
to
a
mode
that
is
stronger
right
and
the
ascent
to
which
it's,
I
guess,
one
and
two
then
yeah.
It
doesn't
matter
all
what
what
what
the
server
is
serving
but
but
to
send
to
which
it
says
it
was
a
bridge.
I
Then
then,
certainly
something
which
you
know
be
bogus
is
is
it
for
is
unfortunate
because
it's
a
new
hurdle
for
for
for
any
any
future
scenario
mechanism.
So
I
mean
to
be
like
it's
like
as
a
sort
of
like
not
done.
Fishing
is
the
right
way
to
do
it,
but,
as
you
know,
for,
for
example,
if
you
serve
a
valid
certificate
via
whatever
mechanism,
then
it's
possible
to
have
some
sort
of
hsts
type.
I
That
kind
of
you
know
signal
in
the
in
the
dns,
but
if
you're
serving
your
presumptively
invalid
certificate
and
yeah
and
they're,
then
then
it
would
be
unfortunate
and
perhaps
I
think,
extraordinarily
undesirable-
to
have
an
hts
mechanism
served
over
like
an
unvalidated
self-certificate,
because
then
you
have
to
worry
about.
You
know
about
temporary
attacks
being
boosted
up
into
long-term
attacks.
So
I
I
guess
I
I
think
I'm
less
sanguine
with
the
idea
of
encouraging
people
to
serve
like
not
even
in
principle,
validatable
credentials.
D
So
eric
I
let
me
first
say
that
the
three
different
ways
that
you
describe
of
reading
the
draft,
I
think,
are
all
valid.
Those
are
all
things
that
I
envision
this
draft
as
doing,
and
I
hear
your
concern
about
encouraging
things
that
would
that
would
make
things
worse
for
future
signaling,
but
here's
the
way
that
I'm
thinking
about
it.
D
This
draft,
I
think,
doesn't
need
to
specify
any
particular
recommendation
because,
to
the
extent
that
we
do
want
to
have
signaling
hsts
style
or
whatever
other
kind
of
style,
the
point
for
that
signaling
is
to
upgrade
from
whatever
this
mechanism
is,
and
if
that
signaling
description
says
by
the
way.
Now
you
need
to
make
sure
you
know,
when
you're
doing
the
signaling,
you
need
to
ensure
that
you
are
offering
the
following
kind
of
certificate
or
following
kind
of
authentication
mechanisms.
D
That's
part
of
how
you
turn
signaling
on
right
and,
yes,
I
agree
with
you.
Any
hscs
style
mechanism
should
not
work
over
a
presumptively
invalid
certificate.
Therefore,
if
that
signaling
mechanism
that
we
choose,
you
simply
haven't
achieved
that,
if
you
haven't
given
a
validate
certificate,
we
I
think
we
can
defer
that
authentication
question
to
whatever
signaling
draft
we
put
in
place
after
this,
I'm
hoping
that
we
will
get
to
that
point.
D
Okay,
I'm
happy
to
talk
with
you
more
later.
If
you
want
to
strategize
about
this
kind
of
problems,
I
I
care
about
that
too.
Yeah.
I
I
think
all
I'm
trying
to
say
is
like
I
don't
want
to
get
into
a
bad
equilibrium
where,
like
where,
like
everybody,
has
self
sign,
search
with
it,
we
have
no
way
to
boost,
strap
up
and
then
that
and
and
then
and
then,
the
and
and
then
and
the
two
open
questions
really
are
about
any
kind
of
mechanism
like
this
one,
whether
or
not
like
the
sort
of
operational
aspects
of
running
the
you
know
of
like
like
having
all
your
formerly
53
traffic,
turned
on
to
like
dot
or
doke,
like
our
pro
probabilities,
and
I've
heard
a
bunch
of
complaints
about
that,
and
the
second
is
like
where
the
operational
aspects
like
of
having
like
actually
serving
a
valid
credential
right,
and
so
my
fear
is
that
we
get
this
equilibrium
where
people,
if
I
feel
comfortable
surfing
like
tls
in
general,
but
then
they're
like
well.
I
D
The
main
gotcha
that
I
hear
in
the
scenario
that
you
describe
is
where
it
is
not
possible
to
change
the
authentication
credential
right
where
somehow
people
feel
like
they've
they've,
gotten
used
to
serving
it
in
this
unilateral
way,
with
whatever
weak
authentication
is,
and
then
they
decide,
they
want
to
go
more
secure
and
they
find
that
they
are
trapped
because
they,
if
they
try
to
change
the
credential,
that
they
offer,
they
run
the
risk
of
dosing
themselves
right.
I
No,
I
don't
think
that's
not
quite
what
I
mean
I
mean
maybe,
but
I
think
I
guess
I
guess
what
I'm
saying
is
like.
I
think,
the
history
of
like
deployment
on
the
web.
There
was
like
a
lot
of
talk
for
a
whole
long
time
about
how
we,
how
he
or
she
saw
certificates,
right
and
and
there's
a
feeling
that
it
was
too
hard
to
get.
You
know
web
pretty
high
valid
credentials
and
that
it
turned
out
to
be
the
case.
I
Obviously,
after
after
like
some
work,
but
I
guess
I'm
I'm
just
just
frantically
concerned
about
having
people
feel
like
they've,
done
all
the
work
and
then
having
a
new
barrier
to
have
to
climb
and
I'm
going
to
climb
that
barrier.
But
again
again,
I
think,
like
you're,
you're,
raising
a
valid
diploma
theory.
I'm
not
sure
I
share
it,
but,
like
I'm
happy,
if
people
are
enthusiastic
about
this
one,
I
think
like
let's
go
with
it.
D
F
So
thank
you
to
eric
for
the
the
three
purposes.
I
would
very
much
like
to
say
that
I
don't.
I
think
that
the
third
purpose
this
is
you
know
that
this
draft
is
going
to
act
as
a
bridge
to
the
future.
One
should
be
completely
out
of
scope
and
not
done
there
should
be,
and-
and
you
know
because
eric
brought
this
up
a
few
months
ago-
and
I
thought
it
was
a
really
good
discussion
on
the
list.
There
should
be
nothing
in
this
draft
or
or
in
the
draft
that
we
adopt.
F
You
know
that
that
gets
out
of
the
working
group.
There
should
be
nothing
in
that
document
that
prevents
any
sane,
fully
authenticated
system
from
being
deployed,
so
absolutely
no
prevention,
but
there
should
not
be
any
feeling
that
this
is
a
bridge
towards
one
or
many
of
them,
because
it
will
turn
into
a
bridge
towards
one
but
not
the
others
and
such,
and
so
that
goes
exactly
to
what
eric
was
saying
with
the
oh,
you
know.
F
Well,
if
people
already
have
self-signed
certs,
then
you
know
this
this
they
may
feel
like
they
don't
want
to
go
up
to
the
next
level.
That
desire
to
go
up
to
the
next
level
is
what
needs
to
be
motivating
for
the
you
know.
Whatever
the
document
is,
so
I
would
really
like
to
see
us
not
try
to
bridge
but
very
actively.
Try
not
to
to
block,
and
the
exact
point
here
is
you
know,
ecker
was
saying:
well,
you
know
if
people
just
have
self-signed
certs,
you
know
that's
not
good.
F
F
F
Over
there,
so
I'm
happy
with
it,
but
I
would
love
to
see
eckers
trilogy,
or
at
least
the
first
two
parts
of
vector's
trilogy
clearly
reflected
up
front
in
in
the
document
of
these
are
the
design
goals
and
it
might
be
okay
to
say
as
a
design
goal.
We
don't
want
to
get
in
the
way
of
future
things,
that's
sort
of
a
topology,
because
you
never
want
to
get
in
the
way
of
future
things,
but
it
might
be
worth
you
know,
at
least
bowing
in
that
direction.
D
Thank
you
paul.
It
looks
like
the
queue
is
drained
to
me.
I
don't
want
to
steal
more
time
from
the
working
group
than
we
need,
so
I
think
I'm
going
to
step
away
from
the
mic
and
stop
sharing.
Thank
you
for
the
discussion
and
I
look
forward
to
more
comments.
B
Yep,
that's
the
right
one
alex
thanks,
so
the
last
topic
on
the
on
the
agenda
and-
and
this
is
kind
of
more
to
spoiler
discussion
on
the
mailing
list,
but
you
know
with
with
with
the
adoption
of
unilateral
probing
you
know
what
we're
really
looking
at
here
is.
Is
the
last
milestone
that
the
working
group
has
identified
alex.
I
think
there's
one
more
slide
if
you
could
jump
to
that
yeah.
B
So
so,
we've
completed
the
work
on
on
the
confidentiality
between
stubbs
and
revolvers,
and
you
know,
we've
been
talking
about
doing
both
on
unauthenticated
and
authenticated
work
or
connections
between
the
recursive
and
the
authoritative
servers.
B
It
seems
that
at
this
point,
where
we're
really
kind
of
focused
on
on
more
of
the
the
unauthenticated
as
the
time
being
and
and
waiting
on
on
what
to
do
for
the
authenticated
side,
so
the
the
key
thing
here
is
is
is
to
really
kind
of
focus
the
working
group
on
on
getting
this
this
document-
you
know,
you
know
you
know,
get
it
quality
reviews
get
iterations,
encourage
some
implementation
so
that
we
can.
B
We
can
understand,
what's
going
on
with
the
with
the
functions
defined
in
the
document
so
and
that
one
more
slide
alex.
So
with
the
existing
milestones,
we
originally
had
a
a
milestone
for
developing
the
requirements.
We
we
tried
that
the
working
group
didn't
seem
to
be
all
that
interested
in
it.
So
it's
been
marked
as
abandoned
the
the
work,
the
milestone
focusing
on
the
the
solution
for
adding
confidentiality
to
exchanges
with
the
authoritative
servers.
B
Tim-
and
I
had
the
discussion
about
this
and
we
were
struggling
to
figure
out.
You
know
who
in
the
working
group
would
be.
B
You
know,
really
interested
in
doing
those
kinds
of
measurements
and
being
able
to
structure
it
in
a
way
that
gave
us
useful
data,
and
we
really
didn't
come
up
with
a
great
answer.
So
we're
actually
suggesting
that
that
perhaps
tim
and
I
go
and
talk
to
the
to
the
map
rg
chairs,
because
this
seems
to
be
far
more
in
their
their
bailiwick
of
expertise
in
in
doing
these.
These
types
of
measurements.
B
The
one
thing
I
will
say
here
is
is
that
you
know,
because
we
were
talking
about
the
performance
against
pervasive
monitoring.
We
would
just
probably
want
to
you
know,
get
that
point
across
that.
It's
not
just
measuring
you
know,
traffic
to
and
from
servers.
It's
really
measuring
more
of
the
the
capabilities
to
you
know
prevent
that
kind
of
pervasive
monitoring.
B
So
what
this
really
means
is,
is
you
know
right
now,
tim
and
I
see
the
working
group
as
being
tightly
focused
on
on
getting
unilateral
probing.
You
know,
move
through
the
process
and
and
out
the
door
so
that
we
can.
We
can
start
seeing
some
deployments
and
some
some
experimentation.
So
if
anybody
has
comments
on
that-
and
we
have
a
couple
minutes
left
otherwise-
we'll
we'll
probably
focus
on
moving
the
discussion
to
the
mailing
list,
paul.
F
Paul
hoffman,
so
one
minor
comment
is
on
number
two.
I
know
that
our
charter
says
experimental.
I
didn't
agree
with
it
at
the
time.
I
don't
agree
with
it
now.
The
current
draft
is
definitely
protocol,
like
I
don't
think
of
it
as
an
experiment.
F
We've
heard
that
there
is
interest
both
on
resolver
side
and
on
authoritative
server
side
of
doing
it
once
we
it's
moving
forward.
I
don't
think
we
need
to
change
the
charter
at
this
point,
but
as
as
unilateral
probing
goes
into
towards
working
group
last
call
it
it's
currently
marked
as
informational,
which
is,
is
particularly
inappropriate.
F
I
would
like
to
see
this
just
beyond
standards
track.
I
there
will
be,
as
there
will
be
more
implementation
of
this
than
many
other
working
groups
have
for
some
of
their
standards
track
documents.
I
don't
see
any
any
reason
to
call
this
experimental
as
long
as
still
at
that
time
there
are
a
couple
resolvers
and
a
couple
of
authoritative
servers
and
a
couple
of
operators
who
are
doing
it.
B
Yeah,
so
experimental
actually
came
from
the
original
form
and
a
formulation
of
the
of
the
charter,
and-
and
so
I
kind
of
see
that
as
the
the
minimal
bar,
if
if
the
working
group
thinks
that
it
is
standard
track,
that's
not
going
to
force
us
into
a
recharter
or
forcing
it
to
be
experimental
it
will.
It
will
be
what
the
working
group
thinks
it
should
be,
alex.
J
Thank
you
alex
mayor.
I
want
to
make
a
comment
on
the
third
point
on
collecting
performance
data
and
effectiveness
of
the
technologies.
J
J
You
remember
that
dkg
back
then
did
like
a
single
measurement
study
about
what
the
appropriate
betting
size
would
be,
and
I
converted
it
in
a
document
and
that
outcome
of
number
three
could
actually
be
good
inputs
to
like
a
revision
of
that
document,
with
updated
security
properties
of
the
padding
sizes.
And
my
question
is
then:
where
would
you
do
that
then,
as
soon
as
we
have
the
results
from
aprg
and
the
other
thing
is,
if
we
ever
do
authenticated.
B
So
if
that
that
would
actually
be
in
deprived,
it's
like
right
now
we
don't
have
a
proposal
in
the
working
group,
so
you
know
what
what
tim
and
I
would
like
to
do-
is
really
focus
on
on
getting
a
unilateral
probing
draft
done.
If
you
could,
could
you
actually
post
a
link
to
that
draft?
You
mentioned
for
the
measurements
to
the
mailing
list.
B
That
may
spur
some
conversations
and
maybe
encourage
thanks
and
and
if
there
are
people
interested
in
doing
those
measurements
from
participating,
then
you
know
we
can
revisit
that,
but
I
think
the
the
big
thing
is
that
we
haven't
seen
anybody
really
standing
up
and
saying
they're
interested
in
doing
that
kind
of
measurements,
but
that
those
are
both
good
points
alex
thanks.
I
Yeah
thanks.
We
we
can
debate
this
later,
but
I
just
want
to
register
that
I
would
not
be
in
favor
of
taking
a
lot
of
appropriate
to
put
it.
I
think
it's
a
good
idea,
because
I
mean
you
approach
that.
B
All
right
hearing
nothing,
I
want
to
thank
everyone
for
attending
both
in
person
and
virtual.
I
hope
everyone
was
able
to
get
youthful
information
out
of
it.
I
also
want
to
thank
benno
and
alex
for
for
being
our
our
hands
on
on
site,
and
hopefully
we
will
maybe
actually
have
like
a
real
in-person
meeting
the
next
time
around
and
with
that
I'm
going
to
wrap
up
and
and
say
thanks
for
attending
deprived
and
stand
by
for
the
add
meeting
thanks
all.
J
K
A
Confusing
chair,
slides
are
maybe
very
similar.
A
For
seeing
that,
how
do
I
get
the
the
slides
that
are
being
shown
to
refresh.
A
Okay,
for
those
who
are
waiting
for
add,
we
will
start
at
15
minutes
past
the
hour,
so
you
have
a
couple
minutes
to
grab
a
coffee
or
whatever
you
need
to
get
you
through
the
next
session.
A
A
Okay,
at
least
tommy
we
were
originally
scheduled
at
at.
I
think
2
a.m,
california
time.
So
this
is
the
better
slot.
We
we
we.
We
did
good.
A
And
if
anybody
from
deepwood
is
still
on
here,
I
see
that
we
got
a
set
of
slides
proposed
by
dan
gilmore
for
unilateral
probing
that
need
approval
from.
I
guess
you
guys
but
they're.
In
the
add
cue.
A
Okay,
I
show
716.
Shall
we
get
started
with
add?
Is
my
my
awesome
coach
here
around
right
here,
hello,
hey,
mr
laura,
hey.
O
A
Well,
welcome
to
add
at
itf
113.,
I'm
glad
dean,
one
of
your
co-chairs.
Of
course,
this
meeting
is
conducted
under
the
notewell
from
the
itf.
Please
be
aware
of
it
and
follow
it,
and
we
really
really
mean
it.
You
know
we
we
carry
this
over
the
slide
over
from
the
last
session,
because
last
week
I
thought
it
was
really
great.
You
know
we
are
kind
to
each
other
here
and
we
respect
each
other
in
our
words
and
our
actions.
A
As
I
said,
I'm
blending
I'm
from
comcast
embassy
universal,
I'm
one
of
the
co-chairs,
mr
lawrence.
You
want
to
introduce
yourself.
O
Dave
lawrence-
probably
anybody
here,
already
knows
both
me
and
glenn,
so
I
don't
think
any
further
introductions
are
needed.
Well,
there's
one
eric
link.
A
Who's
awesome
so,
first
order
of
business,
we
have
three
giraffes
currently
that
have
been
out
there
in
working
group
last
call
these
are
the
three
of
them
listed.
Let
me
start
at
the
bottom.
The
dns
binding
mapping
for
dns
server
service
funny
mapping
for
dns
service
online
cut
number
three
of
coffee
today,
so
I'm
still
waking
up
that
one
has
not
really
received
any
negative
comments
or
any
any
changes
requested
on
the
list.
A
So
I
think
we
can
go
ahead
and
call
that
one
as
a
passing
working
group
last
call
that
brings
us
to
the
other
two
drafts.
There
have
been
a
lot
of
comments
flying
around
around
dnr
from
both
ben
and
chris,
especially,
and
I
see
today
some
discussion
on
lists
about
some
sort
of
changes
or
small
editorial
commentable
priority
flowing
over
into
ddr.
P
Yes,
thank
you.
So
we
we
do
have
two
open
issues
on
ddr.
They
are
both
what
I
would
consider
to
be.
You
know
pretty
editorial,
but
you
know
they
don't
change
the
protocol.
Fundamentally
one
is
about
explaining
kind
of
nx
domain
behavior
around
resolver.arpa
and
the
other
one
is
what
was
discussed
on
list
today
about
hey.
We
should
give
a
call
out
to
dnr,
so
I
I
think
that's
all
the
feedback
we
have
based
on
that.
P
You
know
I
I
I
would
say
that
the
next
state,
for
this
should
be
kind
of
like
last
call
closed,
but
we
need
another
revision
right.
So
we'll
come
up
with
another
revision
and
then
it
could
go
on
to
kind
of
the
shepherd
write-up
from
there,
but
any
problems
getting
that
next
copy
out
in
the
next
week
or
so.
A
Okay,
thank
you
bobby
that
that's
sort
of
my
feeling
too.
Mr
lawrence,
do
you
have
any
different
opinion
on
this
one
we're
all
on
the
same
page?
Okay.
So
then
that
brings
us
to
dnr
our
our
chris
box
around
with
the
queue
want
to
make
any
comment.
A
E
Yeah
we
just
posted
the
changes
today
and
I.
C
E
E
And
if
we
don't
get
a
response,
maybe
the
js
can
intervene
and
help
us
get
some
experts
in
a
six-man
working
group
to
respond.
What
is
the
right
way
of
whether
we
need
an
implicit
service
priority
or
an
ex
service
priority?
So
I
think
that's
the
one
that
needs
some
more
discussion
and
we
need
some
clarity
from
the
other
working
group.
E
The
other
one
I
see
just
now,
ben
had
posted
saying
it's
not
alias
mode,
but
rather
a
mode
in
which
only
the
adn
is
published,
restaurant
feeds
or
will
be
ignored.
So
I
think
we'll
have
to
think
about
it
and
get
back
to
him.
So
I
think
this
is
only
two
pending
comments
that
I
really
need
to
be
addressed.
Q
Hello,
so
yeah
the
week
there
has
been
a
flurry
of
activity
on
the
list,
so
most
of
those
have
been
accepted.
I
think
so.
There
are
a
couple
of
areas
where
I'd
like
to
hear
from
other
people
in
the
working
group.
If
they've
got
opinions
on
it,
I'm
not
sure.
So
if
we
don't
hear
any,
then
you
know
maybe
the
next
step
is
issue
a
revision,
and
then
people
can
talk
about
that.
A
A
A
So
number
three
is:
is
past
working
group
on
number
one
we're
pretty
much
ready,
there's
just
the
two
edits
that
are
going
to
go
in
and
then
it's
ready
for
passing
on
to
a
the
the
the
shepherd
and
then
on
number
two.
We've
got
a
few
outstanding
issues
with
six
man
and
stuff
like
that
and
and
and
what
not
to
resolve.
But
it
looks
like
we're
in
pretty
good
shape
to
have
that
closed
off
fairly
soon.
Is
that
an
accurate
reading?
Does
anybody
have
an
issue
with
us
for
a
summary.
A
Just
quickly
take
a
note
of
the
last
conversation
and
then
so
moving
on,
let's
go
to
the
agenda.
A
They're,
actually
one
the
same:
if
you
go
down
down
farther
in
the
the
ad
notes,
you'll
see
it.
Where
is
the
agenda,
see
the
chair,
slides
where's,
the
agenda?
Does
it
not
pull
up
the
agenda.
J
I
got
it,
I'm
gonna
add
it
to
the
deep
private
notes,
because
I
think
that
the
other
one
is
canceled
and
so
oh
I
got
it.
J
Okay,
glenn,
I
said
I'm
I'm
I'm
ready
for
note-taking,
so
you
can
go
ahead.
I
didn't
know.
A
A
So
yeah,
okay!
So
let's
do
this,
so
the
very
first
one
will
be
tiru
europe
for
split
horizon
dns.
Do
you
want
me
to
show
the
slides
or
do
you
want
to
drive.
E
E
Say:
game
dan,
william.
N
Yes,
okay
and
I'm
presenting
that
dan
wing,
but
go
ahead
and
show
the
slides
that'd
be
great.
C
N
N
So
there
was
a
allowance
previously
for
insect.
That's
been
removed
to
tighten
up
the
domain
camping
that
we're
trying
to
avoid,
and
also
remove
the
subdomain
of
of
ns
allowance
that
we
had,
which
was
more
complicated
than
necessary
for
the
the
solutions
that
we're
trying
to
aim
for
ben,
also
added
a
section
on
dns
based
validation
and
we've
had
a
slew
of
editorial
changes
that
make
doing
a
diff
more
hard,
more
complicated.
N
During
the
interim.
One
of
the
things
that
we
uncovered
was
some
slight
confusion
on
the
scope
for
the
document
that
it
doesn't
allow
domain
filtering
and
that's
correct.
It
doesn't
it's.
It's
only
intended
to
work
with
a
domain
that
you
already
own
and
we
can
verify
by
talking
to
a
public
name
server
or
by
doing
a
dns
sec
validation.
N
So
we
added
a
small
scope
sentence
to
the
document
and
we
might
even
start
talking
about
tweaking
the
title
to
a
verified,
split
horizon
as
well
and
then,
as
a
these
graphics,
didn't
work
out.
Well,
sorry
about
that.
As
a
reminder
of
of
how
the
protocol
works,
we're
we're
doing
pvd
and
dnr,
which
is
up
in
the
blue,
to
get
everything
started.
So
that's
not
new.
What
this
draft
is
proposing
is
the
validation
that
happens
at
the
bottom.
So,
what's
shown,
there
is
talking
to
a
public
name
server.
N
Similarly,
we
can
validate
by
checking
with
dns
sec,
which
doesn't
require
going
out
to
a
public
dna
to
a
public
dns
server
and
asking
it
the
question,
but
in
both
cases
with
what
we're
doing
in
the
green
section
for
the
split
horizon
is
verifying,
the
ownership
is
legit.
You
know
that
the
the
local
dns
claiming
to
own
this
zone
really
does
have
delegation
for
that
zone
from
the
public
name.
Servers.
N
N
Looking
for
adoption,
as
well
as
comments
on
the
content,
perhaps
most
interestingly
or
most
important,
is-
are
the
secure
validation
mechanisms
that
we
have
in
the
document
now
sufficient
for
everyone's
needs.
Do
we
need
to
add
more?
Do
we
need
fewer?
You
know
the
the
same.
You
know
the
the
the
typical
we
don't
want
too
many
standards
to
solve
one
problem
issue,
but
we
want
to
make
sure
that
we
cover
the
use
cases
that
folks
are
are
concerned
about
and
interested
in.
A
H
Hi
ben
schwartz,
you
you
mentioned
the
title.
I
think
that's
a
really
really
good
point.
I
would
go
a
little
further,
even
I
think
that
maybe
maybe
this
would
all
be
a
little
clearer
in
terms
of
its
purpose
if
we
change
the
title
to
something
like
validating
local
claims
of
authority,
because
that's
really
what
this
draft
is
about.
This
is
about
situations
where
some
some
local
entity
tells
you
claims
that
they
are
authoritative,
that
they
have
authority
over
some
zone,
and
you
want
to
check
that
claim,
and
then
we
have.
H
A
A
H
Actually,
there
are
already
other
standards
out
there
that
do
this.
In
fact,
there's
there's
even
an
ancient
dhcp
option
that
allows
the
local
dhcp
server
to
claim
authority
over
a
particular
set
of
domains.
You
know
no
matter
where
the
claim
came
from
this
draft
describes
some
mechanisms
that
a
client
could
use
to
validate
it.
G
Hi,
martin,
munich.
I
would
like
to
mention
two
things,
one,
that
in
the
process
there
is
the
requirement
that
name
servers
had
to
match
between
the
step
one
and
step
10.
I
think
what
if
they
are
in
a
real
split
horizon
when
the
addresses
don't
match,
because
there
are,
for
example,
internal
addresses
used.
There's
a
one
question:
I
don't
know
if
I
have
this
right
and
the
second
one,
it
seems
to
me
that
it's
quite
a
complex
process.
G
As
I
understand
it,
there
is
first
some
dnr,
then
detection
of
the
domain,
then
downloading
json
through
https,
I'm
not
also
don't
know.
If
I
read
it
correctly,
I
don't
think
every
dns
had
to
also
run
on
https.
G
N
So,
yes,
it
might
be
possible
to
do
that,
and
and
that's
why
we're
asking
if
there's
other
secure
mechanisms
that
we
could
use
and
propose
text,
and-
and
we
can
add
that
the
reason
that
we're
that
we
have
the
the
two
mechanisms
we
have
there
today
remember.
What's
what
was
shown
on
that
one
slide
in
green
is
not
this
not
this
document.
It's
just.
N
You
know
how
the
information
is
conveyed
to
the
client,
so
pbd
is
in
there
and
and
those
those
steps
are
not
part
of
what
we're
extending
or
creating
or
defining
with
this
document,
it's
just
those
last
steps
which
is
going
out
to
the
public
dns
and
asking
for
the
name
server
for
the
claimed
local
zone
that
the
local
name
server
is
claiming
ownership
of
and
checking
to
see.
N
And
yes,
that
does
mean
that
the
local
name
server
needs
to
somehow
get
that
authority
from
the
public
dns
that
it
owns
that
zone
and
how
it
does
that
and
where
it
does
that,
when
it
does,
that
is
its
own.
Is
its
own
problem
and
not
not
something
that
we
specify
in
the
document.
O
Thank
you
dan
eckerd.
Please.
I
Howdy
I
have,
I
have
several
questions
about
actual
practicality.
The
first
is,
as
I
understand
it,
from
the
discussion
we
had
previously.
In
many
cases,
enterprises
do
not
wish
to
disclose
the
existence
of
non-existence
of
certain
demands,
so
you
know
say
I
have
mail.example.com,
but
I
want
to
hide
this
and
support.example.com.
I
In
that
case,
it
seems
mechanism
will
not
work.
Am
I
correct
about
that?.
I
Okay,
okay,
I
think
I
mean
you
should
walk
me
through
that
because,
as
I
understand
it,
what
like
so
so,
let's
take
it.
Let's
hit
the
version
of
4.1.1
right.
If
I
guess
maybe
it
depends
on
how
you
think
the
name
servers
work.
I
So
I
mean
I'm
imagining
a
situation
where
I
have
two
names
where
I
have
like
one
name:
server
which
is
like
host,
like
my
external
names,
are
hosted
by
like
say,
dreamhost
and
my
internal
name
server
is
are
hosted
internally
by
some
micro
resolver
and
so,
and
so
when
I,
and
so
when
the
public
resolver
goes
to
resolve
corp.example.com
what
answers
it
going
to
give.
I
I
For
his
endless
record
like
and
its
record
for
example.com
the
points
stream
host,
but
then
when
I
try
to
resolve
corp
what
happens.
N
I
I
H
You're
muted,
then,
oh
thank
you
attempt
to
clarify
it.
The
in
the
architecture
you're
describing
essentially
yes,
the
existence
of
corp.example.com.
If
it's,
if
it's
delegated
separately
from
the
rest
of
example.com,
the
existence
of
corp.example.com
becomes
a
matter
of
public
record,
but
the
domains
underneath
it
do
not.
H
I
So
I
personally
agree
with
you.
However,
that
was
not
the
impression
I
got
from
the
from
the
previous
discussion
in
the
discussion
in
the
latin
and
that
last
ad
hoc
meeting,
the
the
the
second
question
I
had,
and
I'm
sorry
like
I
I
did
review
this
draft
previously,
but
I
sort
of
like
lost.
I
I
sort
of
lost
the
plot.
I
A
little
bit
is:
are
you
assuming
that
there
is
that
the
the
the
internal
resolver
is
identified
by
domain
name,
and
that
that
you
have
to
know
enough
to
make
anything,
a
secure
connection
that
internal
resolver
or
is
restored
to
resolver,
potentially,
if
I
I'll,
probably
buy
ip
address
and
you
make
it
to
v3
connection
by
name?
P
Hello,
just
following
on
on
the
conversation
here
and
ben
we're
having
I,
I
just
wanted
to
ask
to
clarify
in
that
corp.example.com.
P
You
could
also
very
reasonably
just
have
example.com
so
like
I
joined
a
network
and
it
says
I
get
all
of
example.com,
because
I
am
the
company
that
owns
example.com
and
I
have
lots
of
private
stuff
here
and
there's
also
public
things,
and
in
that
case,
if
the
delegation
is
for
all
of
example.com,
I
I
would
just
end
up
resolving
both
the
internal
and
external
things
to
that
encrypted.
Resolver
on
my
local
network
and
that's
presumably
okay-
is
that
how
it
would
work.
N
I
That
eckerd
work
correctly,
because
then,
then
what
because,
as
I
understand
it,
the
way
this
works
is
that
the
is
that
the
public
name
server
responds
with
the
publication.
Server
responds
with
the
name
of
someone
to
contact,
and
so
now
you're
replicating
they
replicating
the
names
both
internally
externally,
but
the
blue
records.
This
just
seems
like
actually
quite
a
comprehensive
version
to
have
like
the
idea
of
the
who
own
who
the
name
server
is
for
example.com,
be
different
externally
internally,.
A
All
right,
thank
you
dan!
Can
you
pass
control
back
over?
Please
should
have
it
now.
Thank
you
so
much,
sir
okay.
So
the
next
item
on
our
agenda
is
the
never
policy
to
use
network
designated
dns
resolvers
who's.
Talking
to
this
one.
E
Because
we
do
okay,
wait
yeah
yeah,
I'm
through
from
akamai.
So
this
draft
is
the
problem
that
this
draft
is
trying
to
solve.
Is
there
several
networks
which
wants
endpoints
to
use
the
network
signal
resolvers,
but
unfortunately
they
don't
have
any
mechanism
to
inform
the
end
point
about
this
network
policy.
If
this
network
policy
is
not
informed-
and
let's
say
the
end,
point
is
using,
let's
say
a
non-network
signal
resolver,
it
could
cause
various
adverse
effects
like
security
alerts
or
blocking
the
client
entirely
or
it
could
be
quarantining
the
client.
E
So
we
were
looking
at
ways
to
solve
that
problem
beyond
using
the
extended
error
codes.
If
the
client
is
directly
reaching
some
other
resolver
using
an
ip
address
or
other
mechanisms.
D
E
Have
picked
the
explicit
web
pvd
very
similar
to
what
the
split
horizontalness
does,
which
basically
gives
you
extra
additional
information
of
the
network,
and
in
that
we
have
added
two
new
case.
One
is
the
key
to
indicate
that
the
policy
allows
only
using
network
signal,
dns
resolvers
and
the
reason
why
and
code
basically
to
indicate
the
reason
why
it
wants
the
end
point
to
use
its
the
networked
signal,
resolver
and
not
some
other
resolver.
E
A
very
simplistic
example
is
this:
web
dvd
is
giving
various
information
about
prefixes
when
this
prefixes
expire
and
what
is
the
identifier?
It's
also
giving
additional
pvds
that
we
are
introducing
in
this
draft,
which
is
to
say
that
it's
requesting
the
end
points
to
use
the
network
signal,
resolver
and
and
then
internal
security
policy,
because
it
which
it
wants
the
endpoints
to
use
the
network
provided
resolver.
E
And
the
signal
is
just
just
a
feedback:
basically
it's
an
internal
security
policy
expression
by
the
operator
of
the
network,
and
it's
definitely
not
a
policy
prescription.
The
endpoints
can
definitely
ignore
and
try
to
use
public
resolvers
if
they
are
reachable
and-
and
they
can
continue
to
establish
communication
this
this.
We
are
currently
proposing
it
as
a
strictly
opt-in
for
explicitly
trusted
networks
by
the
end
user.
It
could
be
used
in
any
network.
It
would
also
be
used
in,
let's
say,
enterprise
networks
without
mdm,
for
example.
E
Nowadays
we
are
seeing
various
types
of
pod
devices
with
a
very
lightweight
host
agent,
which
only
conveys
the
poster
assessment
back
to
the
enterprise
network
and
we
don't
have
a
fully
managed,
mdm
kind
of
a
device,
so
in
those
kind
of
devices
where
we
don't
have
a
configuration
profile
or
an
mdm.
This
would
also
be
quite
useful.
E
Any
comments
and
suggestions
are
welcome.
Whether
this
is
the
right
working
group
for
this.
So
do
you
think
there
is
a
there's
interest
to
solve
this
problem.
P
All
right,
thank
you,
so
I
I
had
one
comment
on
the
use
and
interpretation
of
a
provisioning
domain
here,
which
is
that
it
seems
a
little
odd
for
this
provisioning
domain.
To
tell
you
don't
use
another
resolver,
because
using
another
resolver
implies
that
the
device
is
essentially
using
another
provisioning
domain,
because
a
provisioning
domain
is
the
set
of
all
of
the
configuration
like
ip
addresses
and
prefixes
and
dns
server.
P
E
Okay,
so
you're
using
just
had
a
flag
to
indicate
that
and
we're
good
to
go.
O
Okay,
I
was
that
it
tommy.
It
looks
like
it
ben,
please,.
H
Hey,
as
I
said
on
the
on
the
mailing
list,
that
I
don't,
I
don't
like
this
general
direction.
H
I
think
that
that
we're
we're
this
draft
is
really
trying
to
trying
to
fix
a
problem
that
that
isn't
fixable
and
it's
trying
to
work
in
a
space
that,
I
think,
is
not
where
we
should
be
focusing
our
efforts
and
not
where
the
the
future
of
secure
networking
is.
You
talked
a
little
bit
about
lightweight
host
agents
as
an
alternative
to
mdm.
H
You
know
the
the
behavior
that
I'm
seeing
more
commonly
is
is
device
is
partitioned
device
state
where
the
device
has
an
mdm
inside
a
contained
profile.
That
is
separate
from
from
other
profiles.
So
you
could
call
this.
I
guess
you
could
call
this
byod
if
you
want,
but
actually
the
network
only
ever
interacts
with
a
container
that
is
effectively
a
fully
managed
device.
So
it's
not
really
byod
in
the
way
that
we
usually
talk
about
it.
H
E
G
I
would
like
to
point
out
one
thing:
I
the
thing
is
quite
important.
I
think
that
any
other,
for
example,
doh
third-party
resolver,
should
be
opt-in
by
definition,
not
opt
out.
G
So
if
is
this,
this
is
the
case.
Then
we
would
not
need
some
signaling
that
use
on
in
this
dns,
because,
usually,
at
my
point
of
view,
you
don't
have
in
most
of
the
cases,
you
won't
have
any
benefits
running
third-party
dns.
In
the
first
place,
there
might
be
some
cases
when
there's
a
censorship
or
dns
of
some
filtering
or
something
like
this,
but
it
should
be
the
user.
G
Some
implementation,
like
I
think,
the
mozilla
which
activates
that
by
default
the
third
party,
I
think
it
would
be
even
harmful
to
user
privacy
by
giving
the
information
of
a
resolution
to
a
third
party
which
wouldn't
have
this
information
in
the
first
place.
So
I
think
it's
important
to
somehow
state
that
make
some
even
a
recommendation
rfc
about
using
those
third
parties
in
the
first
place
and
then
maybe
solve
the
issue
of
signaling-
that
okay,
don't
use
it.
E
I
mean
whether
it's
opt-in
or
opt-out,
what
we
have
seen
is
we
have
seen
endpoints
joining
enterprise
networks
with
using
third-party
resources.
We
don't
know
whether
the
user
has
explicitly
configured
its
use,
or
it
was
a
pre-loaded
software
which
came
with
and
pre-built
third
party
resolver,
that
it
was
hard
coded
and
allowed
to
use.
E
But
then,
with
all
these
metal
boxes
and
dns
filtering,
we
are
forced
to
basically
block
those
and
what
we
are
seeing
is
the
end
user,
basically,
seeing
that
it's
unable
to
connect
to
the
internet
and
that's
causing
lots
of
turmoil
and
and
concerns
with
regard
to
not
able
to
use
the
use
the
enterprise
networks
and
if
you
see
any
dns
filtering
enterprise
genius
filtering
service
that
you
see
today,
has
a
policy
which
is
basically
categorizing.
E
Some
of
these
non-network
provided
resolvers
as
anonymous
resolvers
and
blocking
them.
But
I
I
see
that
as
an
half-baked
solution,
it's
not
fully
solving
the
problem
that
it's
actually
causing
the
end
point
to
degrade
to
dns
or
53
and
and
that's
the
whole
reason.
This
graph
talks
about
that.
Hey.
If
somebody's
downgrading
you
prompt
the
user
and
let
the
user
make
a
choice
if
it
wants
to
connect
to
the
encrypted
results
provided
by
the
network,
whether
it's
a
trusted
network
or
not,
and
and
then
then
make
a
call.
E
Whether
this
this
blocking
by
the
network
is
something
that
the
user
is
willing
to
agree
and
fall
back
to
clear
text
dns
or
wants
to
just
abandon
this
network,
because
it
doesn't
trust
the
network
and
wants
to
do
some
connect
to
some
other
network.
But
but
it's
it's
basically
trying
to
improve
the
user,
because
what
what
is
happening
at
the
network
is
just
happening
and
in
one
way,
without
giving
them
a
hint
to
the
user
on.
Why?
E
G
R
R
If
they
don't
do
that,
it's
usually
because
they
have
a
reason
not
to
do
it,
and
you
know
that
reason
might
be
an
application
that
wants
to
use
its
own
dns,
resolver
and
or
the
user
configured
it
to
use
a
different
dns
resolver
in
none
of
those
cases
will
such
a
hint
help.
R
R
The
device
already
has
to
deal
with
any
network
that
blocks
these
third-party
resolvers
without
using
this
option,
and
it
doesn't
seem
like
having
this
option
would
be
any
sort
of
meaningful
improvement
in
security
or
user
experience
or
anything
really,
because
the
choices
that
are
that
are
presented
to
the
to
the
owner
of
the
device
are
the
same,
regardless
of
whether
it's
blocked
intentionally
or
not.
It
doesn't
work,
and
so
the
user
has
to
decide
whether
fallback
is
appropriate.
E
Yeah,
it
could
be
that
yeah
I
mean
if
it's
blocked
and
if
there's
an
alternative
that
the
user
wants
to
pick
because,
let's
say
some
resolver
is
not
reachable
versus
a
network
actively
blocking.
It
is
a
quite
different
scenario,
which
is
probably
fixable
after
a
few
seconds.
If
there's
a
router
flap
or
my
routes
are
not
up,
but
this
is.
This
is
saying
that
if
you
join
the
network,
it's
blocked
indefinitely.
O
A
Again,
you
have
one
more
slide
set
to
present,
so
why
don't
you
just
keep
control?
The
next
topic
is
dns
resolver
info,
the
draft
interior
of
10
minutes,
plus
some
discussion
time.
E
Sure
yeah
I'll
keep
it
short.
I
mean
this
draft
was
discussed
several
times
in
the
working
group
in
the
past.
There
was
a
lot
of
feedback
that
we
got
on
this
draft,
but
at
that
time
the
high
priority
was
to
make
progress
on
dnr
and
area,
and
this
draft
took
a
backseat
so
we're
trying
to
bring
it
back
to
the
just
remind
the
working
group
of
this
work
and
whether
we
want
to
adapt
this
work,
because
at
that
time
we
had
addressed
all
the
comments
from
the
working
group.
E
I
mean
we
already
have
two
mechanisms
for
discovering
dns
resolvers,
but
we
don't
have
a
mechanism
to
discover
what
is
the
appropriate
dns,
interesting,
dns,
resolver
information
and
that
functionality
is
missing
and
that's
what
this
craft
is
trying
to
provide.
E
E
and
we're
basically
retaining
structured
json,
and
we
have
defined
several
feeds
based
on
the
discussions
that
we
had
working
in
the
working
group
to
remove
several
ones
which
were
not
agreed
upon,
and
we
we
stuck
to
an
minimal
set
of
fields
that
there
was
strong
consensus
at
that
point
of
time
and
the
and
the
two
mechanisms
which,
basically,
that
this
draft
talks
about
either
after
you
establish
a
secure
connection.
You
can
download
this
resolver
information
from
the
encrypted
dns
server
or
it
could
be
prior
to
establishing
the
dns
connection.
E
You
could
do
if
you
have
the
local
dns
validation
enabled
you
could
use.
You
could
use
dns
as
well
to
make
sure
no
one
samples
this
data.
So
basically
the
current
list
of
discovered
information
is
basically
whether
the
resolver
supports
q
name
minimization,
whether.
C
E
To
a
generally
constructed
resolver
information,
it
could
have
various
http
status
error
codes.
It
would
trace
it
return
whom
to
contact
for
troubleshooting
and
the
do
jps
supported
and
an
url
that
points
to
a
human-friendly
description
of
the
resolver
identity
and
we
could
add
a
lot
more
information
based
on
the
discussion
in
the
working
group
and.
H
Hi
ben
schwartz-
I
I
think
we
should
probably
adopt
this
draft.
I
think
of
this
as
finally,
a
replacement
for
the
like
weird
chaos
zone
bind
dot
version
thing
or,
like
various
other
weird
implementation.
Specific
resolver
configuration
info
records
that
the
different
implementations
have
kind
of
just
kind
of
put
out
there
in
in
on
squatting
on
different
names.
I
feel
like
you
know,
there's
proof
that
that
people
want
that
kind
of
information
and
we
should
provide
a
more
standard
way
to
do
it.
I'm
not.
A
H
Sure
that
the
specific
metadata
mentioned
in
this
draft
is
what
we
want
to
present,
but
but
I
think
some
mechanism
like
this
is
worthwhile,
and
this
is
a
good
enough
starting
point.
D
I
can
I
can
see
ben's
point
about.
We
should
probably
adopt
something
like
this
just
so
there
is
a
standard
way
to
do
it.
I
want
to
flag
two
specific
concerns.
One
of
them
is
that
reporting
lots
of
details
about
a
given
machine's
configuration
in
other
contexts
has
caused
concerns
right.
I
believe,
for
example,
a
lot
of
web
servers
are
reluctant
to
report
things
like
the
version
of
the
web
server
that
they're
running,
even
though
they
used
to
do
that.
D
So
that,
typically,
I
think
is
for
security
concerns,
but
in
this
thank
you
for
going
to
this
slide
this.
This
slide,
in
particular,
I'm
concerned
about
the
bindings
between
the
urls
here
and
the
actual
service,
and,
what's
to
stop
me
from
pointing
to
a
url
that
describes
some
other
server
and
people
using
that
to
make
a
decision,
I
feel
like
this
is
a
there's,
some
really
sort
of
problematic
dynamics
here.
D
If,
if
this
discovered
information
is
actually
used
to
select
a
resolver,
I
don't
even
know
how
you
know
that
you're
getting
the
resolver
that
these
urls
describe,
and
that
seems
like
an
issue.
I
also
am
very
reluctant
to
to
include
this
required
client
authentication,
just
because
client
authentication
for
dns
resolvers
is
not
generally
currently
done,
and
you
know
the
idea
that
somebody
has
a
list
of
every
dns
lookup
that
I
made
associated
with
me
personally
is
is
pretty
troubling,
so
I
you
know
those
are
these.
S
D
Being
offered
here-
and
I
I
agree
that
if
we're
gonna
define
something
that's
worth
having
it
in
this
group,
that's
good
feedback.
Thanks.
E
Daniel,
I
I
think
I
get
your
point
with
regard
to
I
think
you're,
referring
to
an
attack
where
and
malicious
dns
server,
basically
points
to
an
url
which
which
takes
you
to
somewhere
with
regard
to
some
bad
feedback
to
the
user
in
prompting
to
do
something
which
would
damage
the
endpoints
poster.
I
get
that.
D
My
concern
is
more
that,
like
I
set
up
my
own
resolver,
I
know
that
say:
cloudflare
publishes
some
policies
where
people
are
generally
fine.
With
I
set
up
my
own
resolver
and
the
discovered
information.
I
say,
oh
by
the
way
you
can
check
out
details
about
my
resolver.
You
can
see
that
it's
it's
and
I
just
point
to
cloudflare's
data
is
that
anyone
looking
at
the
at
the
pieces
of
information
is
like.
Oh
yeah,
that's
player,
I'll
use
that,
but
it's
not
it's.
Actually,
my
server.
E
I
Yeah,
I
think
the
key
point
actually
is
the
one
that
the
just
made
a
second
ago,
which
is
it's
not
actually
that
the
terms
of
cloudflare
offers
are
great,
that
you
look
and
you're
like.
Oh,
it's
cloudflare.
This
is
totally
criminal
right
because,
like
obviously
you
could
just
copy
the
terms
right.
I
I
think
if,
if
so,
I
think
I
I
would
just
I
would
say
especially
spanish
in
two
ways
one
is:
is
anybody
gonna
use
it,
and
I
guess
I'd
like
to
ask
like
which
which
client
providers
seem
likely
to
report
this
data
in
any
void
of
the
user?
I
don't
believe
we
would
and
I'd
like.
So
I
guess
I
like
that.
You
know.
I
don't
see
time
policies
here,
maybe
tiny
jensen's
here.
I
Maybe
they
could
talk
about
whether
they'd
be
I'm
interested
in
providing
this
to
users,
because
you
know
we
can
publish
as
much
as
we
want,
but
if
no
one's
going
to
surface
it,
then
it's
not
worth
doing.
Second,
I
think
that
the
point
dkg
made,
I
think,
makes
it
really
clear
that,
like
it
has
to
be
that
there
has
to
be
some
cryptographic
binding
between
the
published
information
and
the
server
itself,
as
opposed
to
merely
a
simple
assertion.
I
T
All
right,
could
you
hear
from
google,
I
think
extending
some
of
the
comments
just
made,
I
would
say
it
makes
sense
to
separate
out
the
information
which
is
provided
into
two
parts.
One
is
purely
protocol
specific,
like
where
the
queue
name
is
supported.
Ede
is
supported,
etc
and
any
other
information
which
is
more
policy
like
like
the
urls
or
anything
else,
maybe
even
two
separate
endpoints
or
two
separate
rr
types
for
them
just
to
separate
them
out
and
in
terms
of
implementation,
I
would
say
maybe
for
the
protocol
features.
A
Well,
thank
you.
Could
you
pass
control
back
over
to
myself?
Please,
yes,
and
the
next
one
we're
gonna
have
up
is
ben
schwartz
and
ben.
Let
me
pass
control
over
to
you,
so
you
can
present.
I
don't
see
ben
in
the
queue
did
ben
drop.
H
H
This
should
be
quick,
so
this
is
about
a
an
individual
draft
that
is
from
me
and
chris
box,
although
it's
it's
based
on
observations
made
by
a
lot
of
other
people,
who've
thought
about
the
problem
of
how
ddr
acts
with
good,
old-fashioned,
local
dns
forwarders
on
your
home
router
and
that
sort
of
thing.
H
H
A
lot
of
isps
have
have
set
up
encrypted
resolver
support,
which
is
great,
but
these
clients
aren't
able
to
access
it
because
ddrs
default
upgrade
rules
say
that
the
the
the
ip
address
has
to
match
in
this
case
and
effectively
it
doesn't,
it
can't
match,
and
you
can't
prove
cryptographically
you.
You
can't
prove
ownership
of
a
private
ip
address.
H
So
so
could
we
get
dns
over
tls
here
and
what
this
draft
does
is
it
describes
it's
purely
informational
because
it
describes
a
client
policy
and
clients
have
all
kinds
of
very
strong
opinions
about
what
their
resolver
selection
policies
should
look
like.
So
this
draft
doesn't
attempt
to
tell
anybody
what
they
ought
to
do.
H
It
just
tries
to
go
through
and
describe
a
client
policy
that
would
upgrade
in
this
in
this
situation
or
really
a
family
of
client
policies
that
that
would
be
able
to
upgrade
in
this
situation
and
also
identifies
as
some
some
of
the
problems
that
come
up
when
you
try
to
do
that
and
also
offers
or
describes
some
mitigations
that
apply
to
those
problems,
although
you
know,
don't
necessarily
totally
resolve
them,
and
you
know,
ultimately,
the
judgment
of
which
of
these
problems
are
relevant,
which
of
these
mitigations
are
sufficient.
A
H
Leaves
that
in
the
hands
of
essentially
client
implementers
to
consider,
but
it
does
try
to
describe
in
detail
what
the
consequences
are
likely
to
be
so
this
has
been
presented
here
before
it
hasn't
really
changed
since
the
last
ietf
one
change
that's
been
valuable
is
that
the
ddr
draft
language
has
been
slightly
adjusted
so
that
it's
clear
that
the
the
ddr
default
client
policy
is
not
the
only
policy.
That's
allowed.
That's
now
very
clear
in
the
ddr
draft
and
we're
seeking
adoption
here
for
this
draft
thanks.
A
Thanks
ben
and
let
me
let
me
make
a
couple
comments
on
the
adoption,
so
the
main
concern
that
the
chairs
have
expressed
was
that
this
particular
draft
was
bad
you're
on
the
air.
O
Glenn
was
when
are
you
done
saying
what
you
were
saying?
No,
no.
A
Okay,
man,
I
I
was
going
to
say
that
the
chair's
main
concern
with
the
adoption
call
was
they
had
little
discussion
on
the
list.
So
that's
why
you
know
been
presented
here
today.
He's
put
some
stuff
on
the
list.
You
know,
I
think
we're
ready
to
issue
the
adoption
call,
but
it
would
be
really
great
to
hear
from
the
members
of
the
add
family
on
on
their
thoughts
on
those
drives.
A
So
I
I
guess,
then
the
short
answer
is
we
will
be
issuing
the
the
adoption
calls
soon
and
we
look
forward
to
hearing
what
people
think.
E
Hey,
hey
ben
I've,
configured
the
draft
and
it's
a
good
start,
and
I
definitely
support
adapting
it,
but
I
had
several
concerns
on
some
of
the
deployment
models
that
you
had
captured
in,
especially
if
you
go
back
to
the
slide,
we're
talking
about
the
legacy
router,
not
being
upgradeable
to
support
to
activity
servers.
I
see
one.
E
I
see
two
types
of
legacy
servers
that
are
always
there
legacy
servers
whose
firmware
could
be
updated
versus
legacy,
routers
whose
firmware
cannot
be
updated,
and
this
seems
to
be
supporting
both
the
cases
and
the
third
one
is
basically
hey.
The
isp
can
manage
the
home
router
and
it
can
change
the
configuration
in
which
case
this
draft
is
not
required
right
and
covering
the
threat
models.
E
In
all
these
cases,
and
especially
one
security
considerations
that
I
saw
this
mitigation,
this
draft
talks
about
was
the
two
mitigations
that
he
talks
about
was
basically
one
relying
on
a
trr.
I
was
wondering
how
this
would
scale
with
so
many
diverse,
trrs
being
used
by
browsers
and
operating
systems.
E
How
would
this
be
deployable
and
the
second
one
was
with
regard
to
relying
on
end
user
empowering
end
user
is
something
great,
but
my
bigger
concern
is
what,
if,
what
if,
let's
say,
there's
a
phishing
attack
and
an
attacker
shows
me
and
resolver
identity,
which
looks
and
feels
like
it's
provided
by,
let's
say,
comcast,
right
and,
and
that
would
basically
you
know
the
end
user
would
be
assuming
it's
connecting
to
a
comcast,
isp
resolver
and
but
in
fact,
connecting
to
an
phishing
or
a
malicious
dns
encrypted
dns
resolver.
H
Thanks
to
that's
a
lot
of
different
things,
I'm
not
sure
that
that
I
can
track
them
all
and
respond
to
all
those
points.
I'll
try
the
on
the
topic
of
upgradeability.
I
think
there's
a
lot
of
subtlety
there.
There's,
for
example,
it
may
be
possible
to
change
the
configuration
of
certain
routers,
but
not
really
add
major
new
features
like
tls
termination.
H
So
probably
they
can't.
We
can
just
expect
routers
to
just
add
support
for
tls.
That
would
leave
the
you
know.
The
only
thing
that
they
could
do
would
be
to
synthesize
a
a
null,
and
you
know
an
nx
domain
or
a
no
data,
ddr
response
which
doesn't
help.
H
So,
let's
see
on
the
topic
of
of
user
interactive
mitigations,
I
think
you
know.
As
I
said,
this
draft
is
informational.
It's
not
designed
to
recommend
particular
behaviors.
A
H
A
H
Otherwise
that
we're
just
trying
to
be
descriptive
here,
the
I
do
think
that
the
attack
you
describe
is
not
something
that
seriously
concerns
me,
because
any
attacker
who's
in
a
position
to
do
anything
like
that
would
equally
be
in
a
position
to
simply
prevent
ddr
altogether,
leaving
the
user
sending
their
dns
and
clear
text
and
leaving
the
attacker
in
full
control
of
the
dns
stream.
H
So
in
general
you
know,
clients
shouldn't
if,
if
the
client
is
encrypting
their
their
dns
traffic
and
sending
it
to
a
dns
server
that
they
can
identify,
but
don't
know
anything
about
that,
shouldn't
change
the
client
or
user
agent's
threat
posture
in
any
way.
They
still
don't
know
whether
they're
talking
to
the
attacker.
So
so
I
don't
see
a
big
difference.
There.
J
G
I
would
like
to
have
a
question
about
the
this
private
ip
thing
for
changing
the
policy
of
the
client,
how
this
would
actually
work
with
the
v6
when
there
is
no
typical
private
address
there
shouldn't
be.
Is
there
some
kind
of
policy
of
matching
prefixes
or
something
like
this?
Also
with
the
private
ipv4
address?
I
suppose
that
it
would
it's
referring
to
fresno
dns
resolver,
not
when
the
resolver
has
a
public
ip
address
and
the
forwarding.
H
Hi,
I'm
I'm
sorry
my
I
actually
lost
connection
for
a
couple
seconds
while
you
were
speaking,
but
let
me
I
think
I
can
answer
your
question,
but
if
I
get
it
wrong,
maybe
you
can
repeat
some
the
so
the
this
draft.
The
concept
in
this
draft.
H
H
It
is
definitely
somewhat
less
common
in
ipv6
networks,
it
is
not
ruled
out
in
ipv6
networks.
Ipv6
gateways
that
are
operating
forwarder
are
free
to
use
a
a
local
ip
address,
a
link
local
or
whether
there's
a
few
different
ipv6.
Non-Public
ranges
there's
and
I
believe,
that's
well
supported
relatively
common.
H
So
so
that's
always
an
option.
Otherwise
the
recommendations
or
sorry
they're,
not
recommendations.
It's
it's.
You
know
it
walks
it
it's
a
little
delicate,
but
the
the
the
situation
where
this
applies
is
is
logically
applicable
to
each
advertised.
H
H
G
Okay,
thank
you
very
much,
and
I
do
have
also
one
point
to
ddr
itself.
I
know
it's
probably
a
little
bit
too
late,
but
why
the
ddr
itself
uses
the
resolver.arpa
when
there
was
probably
the
pvd
that
would
allow
to
use
something
like
underscore
resolver
dot,
pvd
domain.
This
would
allow
a
dns
validation
of
this
information
and
also
ddr
seems
to
solve
the
detection
of
doh
problem
with
the
path,
wouldn't
be
better
to
update
rfc
8484,
to
reso
to
limit
the
path
to
something
like
uniform
d,
url.
G
Url.
Sorry
also,
I've
seen
in
ddr
draft
dot
with
a
different
port.
Is
it
wise
to
allow
different
port
and
ddr?
Thank
you
very
much.
H
So
the
for
the
path
and
port
comments
you
might
want
to
you
might
want
to
take
those
to
the
the
comments
on
the
the
service
bdns
draft,
which
the
chairs
just
closed
the
last
call
on,
but
that's
that's
where
those
are
specified.
I.
A
H
Can
speak
to
those
topics,
but
maybe
the
chairs
should
should
tell
me
how
much
time
we
have.
H
H
So
there
are
many
dns
many
doe
resolvers
already
out
there,
that
that
have
a
specified
path
and-
and
we
wanted
to
make
sure
that
it
was
possible
to
to
to
specify
those
dom
servers
in
the
in
in
the
ddr
context,
for
the
port
number,
the
the
port
number
specification
is
is
something
that
is.
It
is
optional
for
clients
so
and
it's
up
to
every
client
to
decide
whether
they
support
this.
H
But
it's
it's
especially
useful
when
running
many
different
servers
on
the
services
that
need
to
be
disambiguated
instead
of
you
know,
if
you're
trying
to,
for
example,
run
dns
servers
with
different
behaviors,
you
can
share
an
ip
address
and
run
them
on
different
port
numbers,
and
it's
also
helpful
in
in
other
contexts
related
to
dns,
where,
where
non-standard
port
numbers
are
an
issue,
but
maybe
we
should
talk
more
about
that.
O
Yeah,
I
think
at
this
point
we
are
getting
near
the
end
of
the
session
and
I'd
like
to
get
tommy
and
eric
in
the
queue.
So
thank
you,
martin,
and
please
continue
on
the
list
or
as
necessary,
out
of
band.
Thank
you
tommy.
Please.
P
P
I
I
appreciate
that
it's
not
normative,
but
I'm
wondering
if
in
section
three
that
defines
this
relaxed
validation
policy,
we
may
want
to
be
a
bit
more
prescriptive,
not
necessarily
normative,
but
it
essentially
just
says
it
defines
the
client
policy,
as
you
just
use
opportunistic
and
you
just
try
it
and
it
points
to
that.
P
The
fact
that
this
kind
of
validation
can
be
valuable
when
combined
with
some
of
the
mitigations,
but
I
wonder
if
we
should
have
a
bit
stronger
of
a
recommendation
to
say
that
no
really,
you
need
to
go
and
read
the
security
considerations
blow
and
you
need
to
think
about
the
mitigations,
I'm
just
a
bit
concerned.
Someone
would
read
it
and
say:
well,
look
they've
defined
a
policy
where
I
can
just
use
whatever
I
get
back
from
this
dns
record
willy-nilly
and
I
don't
think
that's.
We
should
indicate
that
that
would
not
be
a
good
idea.
H
P
O
Speaking
with
only
a
partial
hair,
a
hat
on,
I
will
say
that
I
personally
am
in
favor
of
it.
However,
when
I've
tried
to
do
it,
I've
also
been
pointed
out
by
other
people
in
the
itf
that
not
so
fast.
So
it
is
an
unresolved
point.
H
Okay,
I
I
think
that
that
we
can
take.
We
can
definitely
incorporate
tommy's
feedback
here
and
improve
the
the
you
know
warning
about
sharp
edges
eric.
O
Eric
nygren
is
back
okay,
yes,
now
unmute
yourself
there,
he
is
oh,
what's
going
on
there,
eric.
A
O
S
Whoo
I
that,
following
up
on
some
of
the
conversation
in
the
chat,
I
think
it's
worth
looking
into
the
ipv6
side
of
this,
a
little
more
in
particular,
I'm
doing
some
more
review
of
what's
actually
and
what
what's
used
in
practice
here
there
may
be
a
lot
of
it
seems
likely
that
that
a
a
common
use
case
will
be
for
to
use
the
like.
S
This
is
the
gateway
address
which
would
be
a
or
a
public
or
a
public
address
in
the
same
64
as
a
client
as
the
resolver,
and,
if
that's
a
very,
very
common
scenario,
it
may
be
worth
having
some
guidance
around
those
common
ipv6
scenarios.
So
we
don't
get
stuck
there
or
not
work
in
in
some
of
the
the
commonly
deployed
ipv6.
S
I
think
this
is
one
where,
where
it's
worth
looking
at
it,
it's
worth
looking
at
what
which
what
a
client
support
and
what
do
and
what
are
isps
tend,
tend
to
deploy
and
then
based
upon
that.
Seeing
what
to
use.
H
I
I
think
that
we
have
there.
We
have
kind
of
a
more
fundamental
problem
of
trying
to
trying
to
figure
out
what
what
it
would
mean
to
essentially
validate
the
locality
of
a
public
address.
H
M
H
What
if
I
could
prove
that
I'm
so
close
to
this
address
that
I'm
just
as
good
a
judge
of
its
authenticity
as
anybody,
you
know,
and
so
we've
had
we've
had
suggestions
on
the
list,
for
example
about
like
well,
could
use
the
hop
count.
Could
you
you
know,
set
your
set
your
ttl
to
2
and
ping
it
and
see.
If
you
can
reach
it
and
then
you
know,
that's
close
enough.
H
I
think
we've
we
haven't
seen
any
of
those
that
seem,
I
think,
plausible
enough
that
that
they
would
be
deployable.
So
my
my
question
to
flip
your
question
around
would
be
okay,
that's
you
know.
The
common
deployment
practice,
maybe
is,
is
to
use
a
public
ip
address
there,
but
how
hard
would
it
be
to
just
you
know,
also
drop
a
a
link
local
address
into
the
dhcp
or
into
the
ipv6
ra
rd.
Well.
S
The
link
localism
introduces
a
whole
bunch
of
scope
issues
that
I
think
there's
a
question
on.
How
will
clients
support
those
and
it's
unclear
what
the
the
security
property,
how
the
security
properties
between
a
a
link,
local
versus
a
on
link
in
the
same
64,
differ.
H
Yeah
so
well,
there's
a
difference
between
there's,
a
difference
between
link
local
and
onlink
right.
You
know,
depending
on
how
your
network
is
structured,
you
know
the
the
router's
ip
address
might
not
actually
be
in
the
same,
like
you
know,
neighbor
discovery
collision
segment
as
as
the
client
or
whatever,
but
anyway.
I
think
this
is
certainly
if,
if
we
can
find
reasonable
ideas
here,
this
is
definitely
something
that
we
can
incorporate.
A
Great
great
session
today
add
is
always
a
place
where
people
talk
and
exchange
ideas,
and
it's
been
pretty
awesome.
I
want
to
say
you
know
reflecting
just
for
a
second
we
started
out
as-
and
I
can't
remember
if
we've
ever
actually
met
in
person
for
add.
A
We've
got
a
couple
documents
that
are
pretty
much
ready
for
working
last
call
or
in
working
group.
Let's
call
it
and
about
to
move
forward,
so
well
done
everybody.
So
thank
you
for
all
the
time
and
effort
people
put
into
adv
over
the
last
two
years,
all
online.
That's
amazing!
So
we'll
see
you
in
philly,
that's
the
next
destination.
I
guess
for
add
and
we'll
see
you
in
july
be
well.
Everybody.