►
From YouTube: IETF109-ADD-20201120-0500
Description
ADD meeting session at IETF109
2020/11/20 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
B
C
I'll
do
some
minutes
as
long
as
someone
assists
as
well
tomozinski
just
to
make
sure
I
don't
miss
anything
but
I'll
I'll
be
in
the
I'll,
be
in
the
markdown
world.
B
D
C
B
E
B
Thank
you,
bro
well,
barbara's
also
been
doing
all
the
the
so
much
of
the
minute
taking
for
the
nom-com.
Her
fingers
must
be
tired.
E
Oh
well,
it's
a
couple
minutes
after
so,
while
we're
getting
booted
up,
I
will
say
that
I
will
just
keep
an
eye
on
jabber
for
mike
line.
If
you
have
comments
that
you
want
to
bring
to
the
bike,
but
for
some
reason
can't
audio
yourself,
I
will
be
happy
to
present
them.
B
E
B
All
right
well,
shall
we
get
started.
Then
we
have
scribes.
We
have
everything
working.
It's
all
awesome,
so
welcome
to
session
two,
the
adv
working
group
at
itf,
109,
I'd
like
to
let
you
scroll
here
like
all
its
sessions.
This
session,
of
course,
is
covered
by
the
ietf
notewell.
B
Please
familiarize
yourself
with
it.
If
you
have
not
by
now,
if
you
haven't
by
this
week,
if
you
haven't
been
paying
attention
so
for
tonight's
session,
we
don't
have
any
presentations,
but
we
have
a
continuation
discussion
of
discussion.
We
had
a
very
lively
discussion
going
on
on
the
monday
session
or
session
one
of
this
week
around
the
concept
of
equivalent
resolvers
for
those
who
missed
it.
B
If
you
want
to
just
jump
over
into
the
the
note
ether
pad
section,
you'll
see
at
the
very
top
of
that
the
transcription
of
the
session
from
monday
a
lot
of
very
good
conversation.
Unfortunately,
we
had
to
cut
it
off
because
we
ran
out
of
time
so
tonight
we're
gonna,
keep
that
up
time
permitting
when
that
discussion,
sort
of
gets
to
a
good
place.
B
We're
gonna,
then
have
a
second
topic
which
is
ip
address
is
in
certificates.
This
is
something
that's
come
up
a
few
times
on
the
list
and
other
discussions,
and
it
seemed
like
a
good
opportunity
to
have
a
chat
about
it.
So
that's
the
proposed
agenda.
Any
any
agenda.
Bashing
people
like
to
put
up.
A
A
What
what
do
you
think
the
discussion
on
ip
addresses
and
certificates
is
likely
to
do?
Is
there
any
confusion
over
what's
going
on
here.
B
Well,
I've
seen
a
few
postings
on
the
list
and
I've
seen
a
few
items
raised
in
the
in
the
github
issues
on
some
of
the
drafts,
so
it
seemed
like
some
people
wanted
to
have
a
discussion
about
it
and
whether
it
would
work
whether
it's
something
practical.
B
I've
also
seen
postings
that
the
certificates
issued
from
let's
encrypt
supposedly
I
have
not
verified
this,
but
I've
seen
comments
saying
that
let's
encrypt
certificates
curl
do
not
support
this,
and
so
I
thought
this
would
be
a
reasonable
discussion
for
us
to
have
and
try
to
sort.
Some
of
that
out
does.
A
B
B
We
have
well
as
time
wise,
we
do
have
two
hours,
but
we
don't
have
to
use
it
all
folks.
So
if
we
get
to
a
good
place,
we
can
wrap
it
up
and
people
go
to
bed.
So
with
that
said,
let
us
pick
up
the
conversation
before
we
left
it
off
the
last
person.
B
Back
on
monday,
we
had
a
very
healthy
conversation
going
on
between
ben
and
martin.
Actually
mike
bishop
was
in
there,
so
there's
a
lot
of
people
have
a
lot
of
things
to
say
about
equivalent
resolvers.
B
So
do
you
need
me
to
put
the
the
definition
back
up
that
we
had
up
there
last
time
to
trigger
people's
memories,
or
can
we
or
do
people
remember
the
conversation.
B
Okay,
can
everyone
see
that
this
is
the
definition
as
taken
from
from
what
was
included
in
draft
box,
add
requirements
and
which
the
tommy
poly
deer
draft
built
upon,
and
this
is
what
we
were
discussing
last
time.
The
notion
that
how
do
we
make
the
assertion
that
the
upgraded
resolver
is
equivalent
to
the
previous
resolver,
that
was
unencrypted
dns
over
port
53.,
and
once
you
do
the
upgrade?
How
do
you
tell
if
they're
the
same
or
the
equivalent.
D
Eric
what
that
is
standard
question?
Can
everyone
hear
me?
Yes,
okay,
so
here
I
just
start
off
immediately
with
the
comment
I
was
going
to
make
at
the
end
of
last
time
that
I
ended
up
making
in
the
on
the
list.
But
not
everyone
reads
the
list,
of
course,
but
I
think,
from
the
perspective
of
a
client
trying
to
protect
our
users,
we
have
sort
of
two
big
categories
of
what
we're
looking
for
and
what
we
want
to
get
out
of
as
these
sort
of
equivalence
concepts.
D
D
That
is
that,
if
there's
any
names
that
they
were
able
to
get
that
field
get
those
names
before,
if
there's
any
filtering,
that
was
going
on
that
to
keep
doing
that
as
well
after
any
upgrade.
So
it's
not
quite
necessary
needs
to
be
perfect
equivalence
things
that
could
be
caching
differences,
that
no
users
gonna
care
about
that,
but
everything
that
was
working
just
has
to
keep
working
from
the
good
enough
for
the
user's
perspective,
and
this
also
includes
things
like
the
latency
speak
enough.
So
that's
the
first
category,
that's
important!
D
The
second
category,
that's
important
that
I
think
this
definition
is
completely
missing,
which
was
also
kind
of
brought
up
a
bit
last
time
is
the
privacy
perspective
users?
They
may
have
chosen
the
config
that
existed
before,
so
they
might
have
explicitly
put
their
trust
in
these
results.
Resolver
they
had
before
so
changing
away
from
that
could
be
a
violation
of
the
user's
expectations
of
trust,
there's
room
for
things
in
here
like
either
making
sure
it's
the
same
exact
party
running
it.
D
So
it's
the
same
entity
with
the
users
trusted,
or
maybe
something
like
the
firefox
model
of
they're,
only
doing
upgrades
to
embedded
servers
that
are
known
to
have
good
privacy.
So
it's
believed
to
be
equivalent
trust
for
the
users
need,
but
there
has
to
be
something
in
here
for
the
trust
and
privacy,
because
just
as
was
pointed
out
last
time,
just
being
the
same
result
is
not
necessarily
good
enough.
D
If
it's
we've
switched
over
to
resume
to
a
resolver,
the
user
is
not
pressed
at
all
and
in
general,
the
only
way
I
know
to
get
that
is
same
provider,
same
running
entity,
type
guarantees
and
the
first
category.
This
thing
keep
working
out
good
enough.
You
kind
of
assume
that
they're
going
to
want
to
make
that
happen
if
we've
at
least
vetted
that
we're
doing
an
upgrade
to
the
same
provider.
G
Yeah
I
mean
so,
I
think
I
agree.
Unsurprisingly,
I
agree
with
much
of
what
eric
growth
just
said.
I
think
that,
from
my
perspective,
there
are
there.
There
are
two
that
equivalence
has
to
have
two
properties.
G
One
property
is
the
one
that
is
hand
waved
around
here,
which
is
the
the
the
the
results
which
I'll
talk
about
in
a
second
and
the
other
is
the
property
that
that
you're
actually
connecting
to
them
and
not
to
some
other
third
party.
So
you
know
in
particular,
if
I
stand
up
a
proxy
that
sits
in
front
of
the
true
the
true
job,
resolver
and
and
then
forwards
all
the
queries
through
those
all
over,
but
also
publishes
them
on
twitter.
G
That's
not
equivalent
resolver,
even
though
it
gives
the
same
answers.
So
you
know,
I
suggested
some
text
in
an
email
about
this,
and
martin
also
had
some
about
how
you
know
this
is
as
if
you
securely
delivered
the
data,
the
true
resolver.
So
I
think
that
part
is
actually
pretty
easy,
straightforward
and
easy
to
easy
to
talk
about,
and
you
know
matches
conventional
definitions
of
security
and
privacy.
G
I
think
that
the
thing
that
is
described
here
is
more
problematic
frankly,
namely
that
the
civil
response
is
so
you
know
to
give
an
example
on
supposing
that,
as
eric
says,
the
cache
behavior
is
different,
or
perhaps
you
know,
because
it's
a
different
location,
you
get
somewhat
different.
You
have
subtlety
different
responses
in
terms
of
low
in
terms
of
like
the
address
of
the
of
the
far
server,
because
someone
else
is
using
geographic
load,
balancing
something
like
that.
G
So
the
question
question
of
how
of
how
to
describe
those
responses
being
somewhere,
I
think,
is
very
difficult
and
I
think
it
may
be
simple.
I
think
I
think
that
it
may
actually
be
easier
to
talk
about
authorization
and
delegation
from
the
original
resolver
that
is
to
talk
about
the
sort
of
mechanical
equivalence
of
the
data.
Finally,
this,
as
I
mentioned
email
on
this
last
second,
half
of
the
slide
is
like
totally
inadequate
because
it's
describing
how
to
actually
do
this
and
there
are
other
ways
to
do
it.
E
F
So
I
think
I'm
also
repeating
something
I
said
on
the
mailing
list,
but
my
my
conclusion
after
thinking
about
this
for
a
little
bit,
is
that
we
are.
We
are
trying
to
say
two
different
things
we
are.
We
are
here
trying
to
say
both
what
we
are
asking
a
resolver
to
do
in
order
to
be
considered
equivalent
and
we
are
discussing
what
the
client
can,
what
the
client
can
do
in
order
to
identify
and
verify
a
that
are
an
equivalent
resolver
and
those
are
not
the
same
thing.
F
There
are
a
bunch
of
properties
like
privacy
policies
that
we
are
asking
equivalent
resolvers
to
provide.
That
are
not
observable,
but
there
are
some
observable
properties
that
we
do
have,
and
we
we
do
want
clients
to
be
able
to
verify,
and
I
think
that
the
observable
properties
that
we
want
clients
to
verify
are
something
like.
G
I
was
in
the
queue
earlier,
so
I
think
you
know
often
it's
useful
to
test
one's
definitions
against
hypotheticals.
So
let
me
give
you
a
hypothetical,
which
is,
supposing
that
I
am
a
isp
and
I
operate
a
doe
resolver
and
I'm
sorry.
I've
already
done
53
resolver
and
I'm
just
like
really
too
lazy
to
operate
manual
resolver,
and
so
I
would
like
to
forward
all
the
dual
requests
as
a
server
I'd
like
to
continue
to
show
the
dual
53,
but
let
the
forward
old
door
request
to
1.1.1.1
is
that
an
equivalent.
B
Mr
dean,
so
not
wearing
any
hat
you're
going
to
turn
my
video
on
so
not
wearing
any
hat
here.
You
know
as
we
work
through
this.
The
the
reason
we've
had
this
discussion
is,
I
think,
twofold
one.
There
is
a
requirement
or
in
a
requirements
document
there
was
this
basis
of
trying
to
identify
what
is
the
end
goal
here
right
and
the,
and
the
first
proposal
is
well,
let's
get
the
upgrade
to
be
equivalent
to
the
current
behavior
of
of
what
you're
connected
to
right.
B
Now,
that's
one
goal,
but
there's
this
other
piece
of
things
that
I
think
we
should
consider
that
is
that
you
know
part
of
the
mission
of
add
is
is
twofold
right
one
is
to
do
the
discovery
of
what's
available
or
what's
possible,
and
the
second
part
is
to
convey
back
into
the
client
through
some
means
information
that
the
client
will
use
to
make
a
decision
of.
B
Is
this
a
server
a
resolver
they
want
to
choose
and
I
think,
maybe
that
splits,
what
this
equivalence
discussion
is
about
in
two
different
ways:
one
sort
of
a
behavioral
thing
conceptually
and
what's
the
goal
of
the
upgrade,
but
the
second
one
is,
you
know
capturing
in
requirements
what
information
we're
going
to
transfer
to
the
client
for
the
client
ultimately
to
make
a
decision
now
how
that
client
makes
that
decision.
Is
that
a
scope
for
our
current
charter?
But
the
conveyance
of
the
information
is
in
scope.
H
Okay,
so
I
I
feel,
like
we've
gone
full
circle,
because
I
recall
that
initial
discussions
we
said
that
pretty
much
okay,
an
equivalent
resolver,
is
done
by
the
same
entity.
Then
people
say
well,
that's
not
specific
enough
which-
and
then
we
come
up
with
this
claim,
which
might
be
more
specific,
but
of
course
requires
you
to
to
run
on
the
same
entity.
So
wouldn't
the
same
entity
thing
just
be
a
simple
thing
that
granted
doesn't
cover
the
use
case
where
the
isp
is
too
too
dumb.
F
E
And
just
for
the
gnosis
joey
salazar,
pointing
that
out,
because
you
know
not
a
a
common
leader
so.
I
Yeah,
sorry
about
that
so
joey
salazar
from
article
19..
So
then,
basically,
we
have
like
equivalency
through
same
entity
and
then
equivalency
through
same
resolution
answers
so
then
there's
also
the
verification
for
that
equivalency.
I
think
that
for
the
current
goal
of
narrowing
down
the
requirements,
scope
for
the
for
the
growth
group,
I
think
that
focusing
on
the
equivalency
and
verification
of
the
same
entity
resolution
makes
sense.
It
does
seem
a
little
bit
straightforward.
I
I
mean
definitely
simpler
than
considering
the
other,
the
other
use
cases
or
or
the
other
scenarios
right
now.
So
then,
like
I
think,
maybe
after
after
we
get
a
head
start
on
that,
then
we
can
start
focusing
on
the
other
equivalencies
and
the
designated
resolvers.
That
definitely
have
a
lot
more
considerations
on
on
on
keeping
up
with
expectations,
and
you
said
user
consent
and
all
those
things
yeah.
A
A
I
don't
know
that
they
can
be
turned
into
something
more
concrete,
but
in
a
lot
of
cases
what's
what's
happening
here
is
that
people
are
connecting
to
networks
and
and
adopting
the
posture
that
whatever
the
network
tells
me
to
do
with
my
dns
queries
I
will
do
and
under
those
constraints,
then
you
can
imagine
that
the
deardraft,
what
the
mechanisms
in
the
deardraft
would
work
perfectly
well,
and
if
you
then
look
at
some
of
the
things
that
we've
talked
about
in,
I
think
now,
four
or
five
different
drafts
about
using
dhcp
and
ra.
A
The
those
mechanisms
would
would
work
equally
well
also,
and
so
the
idea
that
that
is
equivalent
or
maybe
even
no
worse
than
or
better
than
in
some
ways.
A
All
of
those
questions
don't
become
relevant
unless
we
have
some
questions
about
the
differing
privacy
policies,
for
instance
that
might
be
applicable
here,
and
I
think
that's
there's
a
really
simple
way
to
deal
with
that,
which
is
to
say
that
the
expectations
that
you
have
with
respect
to
the
privacy
treatment
of
your
queries
over
the
current
resolver
should
be
roughly
the
same
for
whichever
random
one
you're
getting
assigned
to
obviously
you're
in
a
the
resurrecting
duckling
state.
In
this
case
and
you're,
going
to
trust.
J
I
am
just
reflecting
on
this
and
disagreeing
with
the
idea
of
not
having
the
word
equivalent,
at
least
for
one
particular
context,
because,
as
I
see
it,
equivalent
is
really
important
for
same
provider
auto
upgrade,
because
in
that
context
I
think
the
justification
for
doing
that
or
the
rationale
is
you
you
can
you
can
do
that
because
there
are
no
surprises
to
the
user,
because
nothing
fundamentally
has
changed.
So
that's
quite
a
reasonable
thing
to
do
as
soon
as
you
you
do
that
without
being
equivalent.
J
So
to
the
point
that
I
think
ekka
made
about
it
being
designated
for
example,
then,
potentially
from
a
user's
point
of
view,
their
data
is
now
accessible
to
a
a
different
third
party
to
the
one
that
that
they
were
previously
dealing
with
and
and
dare
I
say
it
for
those
of
us
thinking
about
things
like
gdpr.
That's
that's
potentially
problematic.
If
that
happens,
without
their
permission,
so
I
think
equivalence
matters
for
some
context.
I'm
not
saying
it
is
necessary
in
every
case,
but
I
think
there
is.
J
It
is
important
to
have
a
clear
definition
of
equivalence,
and
that
has
to
include
both
it
being
the
same
party
and
the
same
results
as
far
as
you're
able
to
ascertain
them.
There
are
clearly
other
things
you
might
choose
to
do,
but
they're
they're
not
equivalent,
and
they
may
need
some
sort
of
user
permission
first.
So
I
think
we
need
this
and
I
think
we
need
to
to
bash
out
what
the
definition
is.
That's
my
point.
Thanks.
K
Okay,
so
so
to
me,
what
I
I'm
hearing
about
with
authorized,
resolvers
or
equivalent
resolvers
is
basically
a
resolver
that
is
being
run
by
the
same
entities
that
is
running
the
initial
one
we
got
we
received,
but
from
yes
I
mean
yesterday
or
the
previous
meeting.
K
I
had
the
impression
that
some
bunch
of
people
were
believing
that
it
should
not
be.
It
was
pretty
much
too
much
restrictive,
and
so
I
was.
I
would
like
to
clarify
what
scenario
these
people
have,
which
means
which
I
understand,
and
maybe
I'm
wrong-
that
we
can
have
an
authorized
resolver
that
is
being
actually
run
by
another
entity
than
the
the
primary
one.
K
So
so
that's
one
point,
the
other
one
is,
we
usually
think
think
in
terms
of
a
single
authorized
resolver,
and
to
me
I
envision
that
they
can
be
multiple
resolvers
that
are
being
authorized.
For
example,
I
I'm
I
envisioned
that
you
can't
brand
dns
of
a
tls
or
doe.
I
mean
that
could
be
two
things
that
are
being
authorized
by
by
the
initial
resolver.
K
I
mean
the
one
one
doing
do
53,
for
example
and
yeah.
So
it
seems
to
me
that
the
what
we
we
should
look
at
is
how
we
can
discover
this
list
of
authorized
resolver
and
the
the
most
likely
the
input.
The
more
common
input
we're
gonna
receive
is
an
ip
address
and
I
think
it's
a
little
bit
different
from
being
able
to
say:
okay,
I'm
connecting
to
one
resolver.
Oh
yes,
he
is
authorized,
but
I
am
not
having
the
complete
picture
of
all
the
resolvers
that
are
being
authorized
by
the
initial.
L
I
think
people
are
rapidly
coming
to
the
conclusion
that
equivalence
isn't
a
rich
enough
concept
for
what
people
are
talking
about
here,
and
I
think
one
thing
we
probably
need
to
tease
out
pretty
quickly
is
the
difference
between
access
to
the
same
pool
of
names
and
the
same
behavior
with
the
query
stream
data,
because
I
think
some
of
what
this
starts
out
with
when
it's
talking
about
the
same
upper
layer,
dns
functionality,
it's
actually
saying
hey,
I
am
a
resolver,
let's
say
inside
your
corporate
firewall,
and
I
can
tell
you
about
another
resolver
that
has
access
to
the
same
pool
of
names.
L
That
is
its
view
of
split
dns
is
the
same
as
mine.
It
might
be,
might
be
that
the
only
time
you
can
do,
that
is
when
they
are
run
by
the
same
service
provider
on
two
different
ip
address
and
port.
But
it's
it's
a
useful
thing
to
tell
people
that's
about
not
the
equivalence
of
the
query
stream
data
handling,
but
about
the
the
data
to
which
these
two
things
have
access
and
the
the
question
ecker
asked
also
long
ago
about.
L
If,
if
your
isp
wants
to
point
you
to
to
quad
9
for
for
do
is
actually
kind
of
a
case
of
this.
If
what
your
isp
was
doing
before
was
just
talking
to
authoritatives
and
giving
you
stuff
out
of
its
cache,
it's
basically
saying
I
don't
have
access
to
any
names
that
aren't
in
the
public
dns
those
people
have
access
to
the
public
dns.
You
can
consider
them
kind
of
from
the
pool
of
data
that
they're.
Drawing
from
to
give
you
the
information
to
be
the
same,
that's
completely
different
from
the
privacy
aspects.
L
It
doesn't
tell
you
anything
about
one
of
them
posts
to
twitter
and
the
other
one
posts
to
your
internal
I.t
logs,
and
I
think
we
we
still
need
this
information
about
the
pools
of
names.
You
have
access
to
aspect
of
this
equivalence,
and
so
I
think
when,
when
we're
looking
at
this
and
talking
about
recommended,
we
may
want
to
distinguish
between
a
statement
that
the
other
people
have
access
to
the
same
names.
L
I
do
and
a
statement
that
I,
for
whatever
reason
believe
that
their
privacy
practices
or
as
good
or
better
than
mine,
and
I
I
frankly
think
the
second
one-
is
much
much
harder
to
to
manage
unless
it's
it's
functionally
a
delegation
or
an
authorization
relationship
where
you,
you
have
a
business
relationship
with
the
client,
and
you
have
delegated
this
to
somebody
else
who
is
obeying
your
rules,
but
I
I
do
kind
of
increasingly
come
to
the
conclusion
that
we
need
two
statements
here.
L
E
G
Yeah,
so
I
I'll
start
to
take
a
step
back
and
ask
what
we're
trying
to
accomplish
here.
So
I
mean
this
is
a
requirements
document.
It's
not
it's
not
a
protocol
document,
and
so
the
point
of
this,
the
point
of
this
text
is
to
scope
what
the
properties
the
protocol
you're
designing,
has
to
have
and
so
like.
How
do
we
actually
get
here?
G
Well,
the
point
of
this
isn't
is
that
policy
set
mechanism,
and
so
the
and
so
the
net,
and
so
it's
defining
the
parameters
again,
the
mechanism
for
designing
so
like
if
the
local
configuration
were
actually
secure
like
if
you
magically
got,
could
imagine
you
get
every
dhcp
like
or
whatever
information
about
the
you
know
the
the
the
the
dot
resolver
that
the
sp1
the
network
wanted
you
to
use.
G
Then
we
could
actually
just
like
ignore
like
then
we
could
ignore
the
theory
equivalent,
because
all
we
care
about
is
like
recommended
or
designated
or
whatever,
and
this
is
like
effectively
how
spau
and
and
some
of
that
firefox
steering
work,
which
is
to
say
that
we
have
externalized
information
that
we
use
and
when
we
use
the
local
networks,
information
to
look
up
table
so
and
so,
but
so
the
data
which
we
have
to
talk
about.
G
So
so
so
I
mean
like
the
the
functional
property
is
designated
the
functional
property
is,
I
would
like
the
network
to
tell
me
which
encrypted
resolver
it
wants
me
to
use
and
then
the
the
security
properties
are
actually
about
limiting
the
attacks
under
under
the
actual
model
we're
in
which
is
where
the
network
is
like,
not
actually
super
secure,
and
so,
if
you
look
at
and
so
if
you
look
at
the
material
there
about,
like
you
know
and
dear
about
like
about
the
ip
addresses
the
same
and
that
kind
of
stuff
right,
so
I
think
that
the
the
question
for
equivalent
or
operated
or
whatever
the
restriction
here
is
what
properties
that
you
think
the
designated
resolver
has
to
have
and
or
participate
in
this
system
right
and
so
like
one
design
would
be,
you
say:
look
there
is
anything
the
local
network
tells
me
like.
G
You
know
I
don't
like
they
can
like.
They
can
like
not
cooperate
with
the
disney
resolver
at
all.
Right
and
and
as
I
say,
that's
like
actually
kind
of
what
happens
with
like
sbau
and
and
firefox
steering
and
the
other
is
the
one
that's
in
deer,
which
is
they
have
to
cooperate
at
least
to
the
extent
to
which
you
know
that
the
the
disney
resorts
are
play
ball,
because
it
has
to
point
back
to
the
original
resolver.
But
that's
for
security
reasons.
G
G
Talk
about
the
points
to
already
in
this
document
about
not
being
able
to
steer
you
to
somewhere
else
that
that
you
otherwise
wouldn't
be
sending
data
to,
and
that's
how
we
get
into
the
concept
that
the
designated
reservoir
has
to
play
ball
or
if
it's
all
in
the
work.
But
if
we
invented
some
way
that
didn't
need
that,
then
we
could.
Then
we
wouldn't
have
to
do
that.
G
So
I
think
that
the
idea
of
it
being
self-operated
or
or
affiliated
with
it
anyway
like
is
like
not
necessary
part
of
this,
and
and
as
I
say,
you
know,
really
nothing
can
stop
people
doing
that,
like
you
know,
if
I
want,
if
I
wanted
to
do
a
deal
like
on
my
local
network
with
888,
to
be
like
a
deer,
resolver
and
they're
willing
to
serve
like
this
this
year,
equivalent
ips
certificate
like
no
one,
can
stop
me
from
doing
that,
whatever
mechanically
designed.
G
So
I
guess
I
don't
think
trying
to
like
prevent
that
in
this
in
this
is
helpful.
The
purpose
is
again,
it's
the
scope.
We're
trying
to
accomplish
and
we're
trying
to
accomplish,
is
here's
a
pointer
over
here.
F
Hey
so
I
think
that
the
concept
of
equivalent
is
useful.
I
just
don't
think
it's
the
thing
that
we
should
be
trying
to
prove
in
the
protocol.
I
think
we
want
both
of
these
concepts.
I
think
that
the
the
our
purpose
here
is
to
enable
the
discovery
of
resolvers,
and
we
would
like
those
resolvers
to
be
equivalent.
So
it's
fine
to
have
this
as
sort
of
motivational
text.
F
D
Did
I
oh
there
we
go
so
I
think
the
fact
that
we
have
so
much
discussion
over
what's
good
enough
and
what
things
we
need
to
prove
is
pretty
solid
proof
that
this
different
parties
want
different
things
here,
and
this
is
squarely
in
the
policy
area
of
things,
but
I
think
it's
still
good
to
have
definition,
so
we
can
get
things
on
the
same
page.
So
I
think
what
we
need
is
just
stop
trying
to
focus
on
getting
one
thing
we
can
prove
or
talk
about
or
care
about.
D
We
just
need
multiple
different
definitions
of
different
concepts.
We
need
things
like
a
network
designated
resolver
is
one
that
meets
these
things
of
the
network
is
designated
and
doesn't
necessarily
say
anything
else.
Resolver
designated
resolver
as
a
resolver
said.
I
want
you
to
use
this.
It
doesn't
necessarily
anything
else.
An
equivalent
resolver
is
one
that
has
similar
results,
blah
blah
blah
doesn't
necessarily
anything
else.
A
same
party
resolver
is
one
that's
run
by
the
same
entity
and
such
so.
M
I
think
that
just
what
I
want
to
say
was
just
said:
the
decision
about
equivalence
sits
with
the
client,
not
with
the
on
the
server
side,
which
means
that
the
server
cannot
declare
equivalence,
so
the
I
think
we're
using
the
wrong
term
here
we
should
talk
about
alternate,
alternate
resolver
service
and
it's
then
up
to
the
client
to
decide
whether
that's
acceptable
or
not.
So
what
what
we
should
look
at
is
a
given
certain
circumstances
in
which
the
client
is
operating.
M
It
will
or
will
not
accept
the
suggestion
of
a
resolver
and
if
things
change
or
if
the,
if
there
are
alternatives,
it
can
make
a
decision
and
we
should
focus
on
providing
information
to
the
clients
so
that
it
can
make
a
decision
about
an
alternative
resolver.
M
Nor
is
it
is
it
up
to
the
acp
or
ra,
so
we
should
focus
on
the
concept
of
alternative
resolvers
and
if
you
look
at
it
that
way,
the
the
the
the
picture
shifts
somewhat
and
you
can
start
to
to
look
at
the
various
bits
and
pieces
that
you
can
provide
bits
and
pieces
of
information
that
you
can
provide
to
the
client
so
that
it
has
a
decent
chance
to
make
a
decision
about
whether
it
was
to
trust
and
use
a
resolver
or
not.
Thank
you.
N
Hi
yeah
thanks
I'd
just
like
to
say
this.
This
discussion
is
really
good
and
to
hear
you
talking
about
this,
I
want
to
go
back
to
ted's
point
about
split
dns,
which
I
think
is
quite
useful
to
help
framing
in
framing
what
I
would
think
of
equivalence,
and
so
I'm
just
wondering
if
it
might
be
helpful
rather
than
trying
to
create
definition
to
think
about
the
use
cases
we'd
like
to
account
for
like
if
I,
if
I
do,
have
split
dns
operating
in
my
enterprise.
N
I
obviously
don't
want
my
internal
private
network
like
leaked
to
some
result.
I
don't
expect-
and
I
think
that's
like
quite
a
helpful
use
case
for
me
in
terms
of
what
equivalence
means
in
that
you
in
that
situation,
like
other
people,
have
spoken
about
wanting
the
same
results
and
not
getting
their
worldview
kind
of
changed
on
some
change
of
resolver.
There's
been
a
lot
of
jabber
chat
about.
N
I
think
that,
for
me,
that's
a
helpful
way
of
thinking
about
it,
at
least,
and
I
just
like
to
say
there
is
a
lot
of
jabber
chat
that
I
think
could
be
quite
helpful
if
it
was
like
actually
said
and
for
people
watching
the
recording-
and
I
totally
agree
with
some
of
the
comments
about
separating
the
technical
mechanism
for
recommendation
and
then
separating
that
from
the
best
practice
under
which
conditions
you'd
like
recommend
a
certain
resolver.
N
E
Thank
you,
west
hartaker,
please.
O
It's
a
great
match
to
lehman
who
teed
me
up
perfectly,
so
I
don't
have
to
speak
as
long
as
I
was
planning
on
because
he
said
half
of
what
I
was
planning
and
which
really
amounts
to
how
do
clients
pick
between
the
choices.
So,
as
as
liman
said
you
know,
network
identified
and
resolver
identified
are
not
helpful
to
the
client
if
they
can't
verify
the
results.
So
it's
great
that
it
sounds
like
you
know.
O
We
may
be
coming
up
with
a
list
of
check
boxes
that
you
know
can
define
equivalence,
that's
fantastic,
but
we
really
need
that
list
to
include
markings
that
indicate
which
ones
clients
can
actually
verify,
and
unfortunately
that
may
be
you
know
low,
but
we
already
have
the
applications
out
in
the
wild.
That
actually
do
things
like
check
to
see
how
resolvers
behave,
so
they
can
make
decisions
based
on
the
chromium.
O
Send
three
random
strings
feature
is
one
of
them,
as
is
the
dns
roadblock,
rfc
and
dns
trigger,
are
ways
that
they're
actually
trying
to
go
out
and
find.
We
need
to
find
you
know
resolvers
that
support
their
environment
and
we
need
the
equivalent
on
this
side
too.
So
you
know
how
do
resolvers
actually
do
that?
B
You,
okay,
I
want
to
put
this
all
back
in
context
for
everybody,
so
if
you,
you
know,
I
think
the
this
proposal
may
have
gains
and
legs
beyond
people
understand
the
original
context.
So
the
original
context
is,
if
you
go,
look
at
the
the
draft
box.
Add
requirements
that
zero
one
version,
which
is
the
version
that
chris
is
currently
publishing
his
co-authors,
have
published,
is
a
narrowed
use
case
not
covering
everything.
B
It's
covering
a
narrow
set
of
use
cases,
which
is
what
was
decided
was
people
wanted
to
work
on
initially
going
back
to
the
interim,
and
so
I
don't
think
in
the
context
of
that
draft.
This
is
being
proposed,
as
this
is
a
necessary
requirement
for
all
upgrades,
but
that,
for
the
use
case
described
in
that
draft,
this
is
a
concept
that
that
is
fundamentally
based
upon
and
built
upon,
for
that
particular
use
case,
and
so
that
would
then
put
this
to
me
and
I
I
encourage
people
to
think
of
it.
B
This
way,
as
this
is
a
piece
of
information
that
would
be
somehow
discovered,
conveyed
to
the
client
as
part
of
solving
the
requirements
in
that
one
particular
use
case,
there
are
likely
other
use
cases
split
dns
being
brought
up
is
a
very
good
example
where
there
will
be
other
requirements,
and
this
one
might
not
even
in
fact
be
on
the
tables
or
requirement
as
written
and
would
need
to
be
updated
and
changed
to
fit
into
that
other
set
of
use
cases
that
the
group
can
consider
along
the
way.
E
Thank
you,
glenn
martin
thompson.
A
A
That
delegation
has
properties
that
are
not
significantly
worse
or
no,
no
worse
than
the
authentication
properties
that
you
get
from
talking
to
it.
The
do-53
server
that
you
are
talking
talking
to
anyway,
and
in
addition
to
providing
that
delegation,
we
would
further
recommend,
with
the
usual
caveats,
around
recommendations
and
protocol
police
that,
in
addition
to
providing
the
encrypted
transport,
the
resolver
that
is
delegated
has
similar
or
better
characteristics
when
it
comes
to
a
range
of
criteria,
and
I
listed
performance,
privacy
and
access
to
names.
P
P
What
we
are
trying
to
do
is
an
assertion
that,
if
you,
if
you're
currently
using
resolver
a
you,
should
consider
using
the
solo
b
and
we
can
do
a
bcp
like
recommendation-
that
you
should
only
make
that
assertion
under
under
certain
circumstances
like
here,
the
names
are
right
and
the
and
the
privacy
is
okay,
but
the
word
equivalence
is
misleading
and
should
be
entirely
removed.
These
are
recommendations.
E
Q
Hi,
can
you
hear
me?
Yes,
we
can
okay,
so
I
was
just
I
think,
based
on
the
discussion
there's,
I
was
going
to
propose
some
terms
which
maybe
help
distinguish
the
different
kinds
of
equivalence.
Q
One
is
obviously
the
resolution
equivalence
which
we
are
talking
about,
then
the
other
one
is
possibly
operator
equivalence
and
then
the
policy
equivalence
policy.
Equivalence
is
probably
the
most
vague
out
of
these
three.
It
could
cover
a
lot
of
things,
but
I
think
if
we
use
these
terms,
it
may
make
the
discussion
easier
to
follow.
E
D
I
just
want
to
push
back
a
little
bit
on
any
sentiment
that
maybe
we
should
just
focus
on
designation
alone
and
leave
everything
else
up
to
just
saying:
hey.
You
should
be
good
about
this,
while
you're
doing
designation.
That's
all
you
should
rely
on.
D
If,
if
that's
all
we
have,
I
think
there's
going
to
be
a
lot
of
clients
that
will
just
not
support
this
and
we're
not
going
to
get
a
lot
of
traction
out
of
these
protocols,
because
a
lot
of
clients
feel
that
they
have
security
or
operational
needs
to
have
more
than
just
untrusted
designations.
So
maybe,
if
not,
everyone
might
not.
All
clients
might
require
these
things,
but
we
don't
have
any
mechanisms
at
all
to
prove
any
level
of
same
party
or
some
equivalence
of
some
sort.
D
J
Yeah
I
just
wanted
to
jump
in.
There
was
some
discussion
in
the
chat
one
also.
Some
of
the
people
have
asserted
that
the
entity
operating
the
resolver
doesn't
matter,
so
I
just
wanted
to
say
verbally
what
vittorio
has
put
in
the
chat,
which
is
actually,
in
my
view,
the
entity
operating
the
resolver.
Absolutely
matters
as
well.
J
If
you
change
the
entity,
then
certainly
in
some
cases
you're
going
to
have
to
ask
the
user-
that's
not
something
the
client
can
do
invisibly
in
the
background
without
causing
difficulties
for
the
for
for
the
entity.
That's
running
the
client,
so
I
think
for
this
particular
use
case.
There
are
other
use
cases
where
it
wouldn't
matter,
but
for
this
use
case
I
think
it's
important
to
include
the
entity
operating
the
resolver
as
part
of
the
equivalence
definition.
Thanks.
A
Thank
you,
martin,
so
I
wanted
to
disagree
with
both
eric
and
andrew
separately.
Eric
suggested
that
we
might
care
about
who
operates
the
resolver.
Of
course.
We
do
and
andrew
said
the
same
thing,
but
we're
specifically
talking
here
about
the
a
scenario
where
there
is
no
express
preference
about
where
your
dns
queries
go,
because
no
effort
has
been
made
to
do
anything
other
than
except
what
the
network
has
been
been
telling
you.
A
But
I
think
we
have
a
possibility
here
of
addressing
some
sizable
portion
of
the
use
cases
that
we've
identified
by
accepting
this
definition
and
then
for
those
people
who
have
those
additional
requirements.
We
can
talk
about
having
things
in
addition
to
this,
that
provide
assertion
of
identities
and
various
other
things
so
mozilla
might
use
their
trusted.
Recursive
resolve
on
this
to
decide
whether
or
not
to
follow
this
designation.
E
M
Here
you
are,
I
never
mind,
so
I
think
martin
might
be
slightly
off
track
here,
because
if
you
have
the
two
scenarios
that
either
the
client
doesn't
really
have
an
opinion
on
where
it
sends
its
queries,
we
don't
have
to
declare
equivalence,
because
the
client
doesn't
care,
so
it
doesn't
matter
where
the
queries
go.
M
The
only
thing
you
might
be
interested
in
there
is
to
avoid
someone
to
inject
rogue
information
about
about
resolvers
so
that
you
actually
do
care
to
the
level
that
I
want
to
use
whatever
is
handed
to
me
by
dhcp
or
ra
or
some
equivalence
mechanism,
but
I
don't
want
anyone
else
on
the
network
to
be
able
to
to.
M
You
know
redirect
my
queries
to
a
server
that
that's
not
operated
in
the
network
or
by
the
network
environment
that
I'm
working
in
that
that
could
that
could
be
useful,
but
I
keep
thinking
that
what
what
we're
talking
about
here
is
not
equivalence.
It's,
whether
it's
acceptable
to
the
client
or
not,
they
don't
have
to
be
equivalent.
They
need
to
still
remain
within
the
the
decision
bubble.
The
the
decision
this
set
of
set
of
properties
of
the
resolver
that
is
acceptable
to
the
client,
so
please
focus
on.
That
is
my
suggestion.
G
I
I
largely
agree
with
mt
here
I
mean
I
think
it's
important
to
remember
that
the
you
know
the
you
know,
dough
aside
or
dot
aside,
like
the
network,
can
like
stir
you
to
any
resolver.
It
places
any
other
ones
just
by
then
you
use
stuff
in
dhcp
right.
G
So
you
know
the
only
product
like
you
can
say
that
they
throw
forty
three
years
over
where
it
was
they
just
can't
serve
you
in
any
dough
dot
or
dober's
over,
whilst
getting
no
way
of
saying
that
so,
like
you
know
so,
having
like
having
like
generic
restrictive
requirements
for
like
what
kind
of
entity
the
network
can
steer
you
to
for
doe
and
dot
versus
you
know,
w3
doesn't
make
any
sense
really
now.
G
I
think
that
there's
the
I
do
want
to
say
there's
plenty
of
good
material
in
like
in
this
document
that
your
document
about
like
not
having
available
situation
worse
in
terms
of
like
persistently
stringing
their
own
plays
so
those
kinds
of
things.
I
think
that
that's
that's
good
material,
but
I
think
the
essential
which
one
does
care
about
the
entity
was
operating
it
as
with
the
trr.
G
Then
I
think,
as
martin
says,
you
need
to
answer
information,
so
I
mean,
if
you
think,
about
the
way
that
that
the
that
firefox
is,
though
string
works.
Right
is
firefox,
has
a
resolver
that
it
likes,
and
what
it's
willing
to
be
told
by
the
network
is
here
are
some
other
resolver
which
you
also
like,
which
you
should
use
instead
of
the
resolver
you
use
by
the
fault
that
you
like
and
and
that's
an
info.
G
We
do
create
the
entity,
but
we
don't
care.
We
don't
search
equivalence
because,
like
actually
it
isn't
necessarily
equivalent
we
care
about
is
is
an
opinion,
so
we
might
want.
You
know
some
sort
of
like,
and
so
in
this
circumstance
you
could
imagine.
As
martin
says,
we
could
just
look
up
the
terrorists
which
we
do
now,
but
you
might
want
the
protocol
to
be
in
terms
of
once
again
we're
trying
to
find
requirements.
G
We
want
the
requirements
to
say
well,
here's
some
way
like
bolt
on
some
sort
of
like
meta
information
that
gets
gets
attached
to
this
as
well
that
you
might
use
in
a
separate
way,
but
in
terms
of
like
the
there's
in
terms
of
like
the
tenth
requirements.
Besides
that,
it's
like
just
tell
me
where
the
thing
is
and
then
allow
me
to
verify.
G
That
is
where
it's
supposed
to
be,
which
is
what
you're
doing
by
the
way,
I
think,
like
you
know,
I
think
if
you
just
reverse
engineer
and
say
what
is
dear
doing
like
jira
is
doing
effectively
the
right
thing.
You
know
modulo
perhaps,
as
I
say,
perhaps
some
questions
about
whether
or
not
it
it's
gonna
actually
work
with
them
through
the
right
set
network
elements.
But
if
you
ask
what.
E
F
Hey
ben
schwartz,
I've
heard
a
couple
of
comments
related
to
what
I
would
call
a
non-delegation
rule.
This
idea
that
there
might
be
at
least
some
circumstances
where
you
want
to
require
that
the
dns
traffic
not
be
steered
to
a
different
entity,
and
I
just
want
to
say
non-delegation
is-
is
not
an
option.
We
do
not
have
the
option
to
enforce
a
non-delegation
rule
because
to
a
dns
client,
a
dns
forwarder
is
indistinguishable
from
an
iterative
resolver.
S
Q
Q
S
That
they
want
to
recommend
is
equivalent
so
that
that's
one
concept
of
equivalence,
then
there's
a
technical
mechanism,
a
protocol
through
which
the
operator
of
resolver
a
tells
the
client
that
they
think
that
b
is
equivalent.
And
finally,
there
is
a
policy
decision
in
the
client
on
whether
to
accept
the
recommendation
or
what
to
check
and
under
which
conditions.
S
And
then
I
mean
the
policy
parts
of
the
story.
I
think
we
can
at
most
make
recommendations
on
best
practices
if
we
want
to
venture
into
that,
but
I
mean
there
will
always
be
decisions
that
are
taken
by
each
individual
operator
and
client
and
we
cannot
control
them.
So
this
is
not
something
we
can
solve
at
most.
S
So
I
mean
I,
I
don't
think
it's
something
we
have
to
solve
directly,
so
I
mean
I
also
agree
with
the
fact
that
in
theory
that
there
should
be
no
more
new
parties
into
the
loop,
so
I
mean
this
is
something
we
can
recommend,
but
I
I
really
think
we
have
to
focus
on
on
the
technical
mechanism
to
combine
the
recommendation
and,
and
then
the
rest
is.
I
think
not
really
something
that
I
mean
or
something
we
can
address
separately,
but
not
at
the
same
time.
R
Awesome
so
part
of
the,
I
think,
part
of
the
hang-ups
I
was
having
listening
to
this
can
be
identified
simply
by
resolver
identified
for
me
needing
to
be
split
as
some
have
identified.
Some
clients
simply
are
connecting
to
a
server
to
get
dns
and
they
have
no
opinions.
In
that
scenario,
as
ecker
said,
there's
reasons
a
network
operator
may
want
to
offload
encrypted
traffic.
R
Fine,
the
client
doesn't
care
just
give
me
the
address
it's
encrypted,
it's
better,
I'm
happy,
but
there
are
cases
where
I
am
using
dhcp
or
I
only
have
an
ip
address
for
other
reasons,
but
I
have
a
strong
desire
to
make
sure
that
I'm
communicating
with
basically
that
same
server
and
as
much
as
I
can
and
to
that
end
I
would
want
to
be
able
to
confirm
that
it's
the
same
entity
and
the
the
canonical
case
for
me
is
the
is
the
employer.
R
I
do
not
want
my
traffic
being
offloaded
outside
my
employer's
network
without
some
more
manual
configuration
occurring,
and
so
I
think
it
might
make
sense
to
have
resolver
identified,
be
split
into
two
resolver
identified
same
entity
and
resolver.
I
identified
generic
so
that
a
client
that
does
not
care
can
take
either,
but
a
client
that
does
care
can
verify.
R
J
Hi
yeah,
I
just
wanted
to
just
capture
the
point
again,
which
has
been
discussed
on
on
jabba
by
some
of
us.
I
fundamentally
disagree
with
with
the
position
that,
if,
if,
if
the
client,
if
the
user
is,
is
using
dhcp
and
and
and
to
determine
the
dns
that
that,
for
some
reason
should
be
maybe
set
aside
because
they're
wrong,
we
shouldn't
try
and
second-guess
the
user
in
that
instance.
J
J
So
consequently,
I
think
it's
entirely
valid
to
go
with
that
and
to
try
and
second
guess
that
and
go
down
an
alternate
path
with
it
without
their
agreement.
It
just
seems
to
me
fundamentally
wrong
and
flawed
and
also
yeah.
I
think
we
need
to
bear
in
mind
that
this
this
isn't
specifically
or
or
purely
just
for
going
from
dns
over
53
to
to
dough.
This
is
going
from
any
flavor
of
dns
to
any
flavor
of
dns
as
a
discovery
mechanism
is,
is
my
understanding.
J
So
we
need
to
bear
that.
Put
that
in
mind
as
well,
but
I
think
the
key
thing
is
we
can't
second
guess
the
the
the
user.
We
should
go
for
equivalent
with
with
what
their
current
settings
are
and
if
they've
you
or
or
what
their
current
choices
are
and
if
they've
used
dhcp
to
get
to
those
choices,
then
that's
fine
and
don't
see
an
issue
with
that.
I
don't
understand
why
other
people
would
thanks.
M
Oh
no,
it
worked
fascinating,
so
I
I
I
think
I
would
just
like
to
continue
that
thread,
because
that
brings
me
to
the
conclusion
that
that
what
we
should
look
at
here
is
not
trying
to
tell
the
client
that
that
this
other
resolver
is
equivalent
because
resolver
a
cannot
tell
the
resolver.
That
b
is
equivalent
because
the
the
the
decision
to
accept
and
the
decision
to
make
the
the
the
the
claim
or
make
the
statement
that
two
things
are
equivalent
sits
with
the
client.
M
So
we
really
only
need
to
care
about
suggesting
alternative
resolvers
and
whether
they
are
equivalent
or
not.
Is
a
second
transaction
that
the
client
undertakes
after
having
been
informed
about
the
existence
of
an
alternative
resolver
and
by
talking
to
the
alternative
resolver.
Because
that's
the
only
way
you
can
build
a
bilateral
understanding
of
whether
you
want
to
trust
someone
or
not.
I
don't
trust
people,
because
one
person
says
you
can
trust
this
other
guy.
M
M
Why
don't
you
talk
to
him
so
make
this
first
step
very
simple,
provide
alternatives
to
to
resolvers
and
then
build
into
the
concept
that
there
is
a
handshake
in
some
way
could
be
very
lightweight
and
where
the
client
discovers
or
the
properties
of
the
the
alternative,
resolver
and
builds
it
comes
comes
to
conclusion
whether
it
wants
to
trust
it
or
not.
Thank
you.
H
So
to
to
answer
andrew,
there
might
be
a
misunderstanding.
My
understanding
of
the
earlier
argument
of
the
martian
was
that
there
there
are
cases
already
where
you
don't
trust
the
htp
like
when
you
have
a
policy
on
you,
a
policy
from
your
enterprise,
on
your
laptop,
that
you
only
can
trust
certain
dns
servers
and
things
like
that,
and
I
think
that
is
what
what
was
described,
and
I
think
this
is
what
has
to
I
mean
there's.
I
don't
think
anybody
disagrees
that
the
enterprise
can
set
policies
on
devices
for
the
for
their
users.
H
However,
in
the
absence-
and
I
think
that's
where
what
we
were
talking
about
in
the
absence
of
those
policies,
there
should
be
what
I
think
lehman
said,
a
designation
suggestion
from
the
from
sort
of
the
resolver
that
the
client
should
follow.
L
So
I
just
wanted
to
follow
up
on
layman's
point,
because
I
don't
think
it's
practical
for
us
to
follow
it
quite
as
exactly
as
he
laid
it
out,
because
what
I
heard
him
saying
was
it.
It
actually
just
provides
a
c
also
and
makes
no
assertion
about
the
characteristics
of
the
of
the
the
entity
or
the
resolver
at
the
at
the
place.
You're
you're
going
to
see
but
suggest
you
go
and
probe
it
to
see
whether
it's
to
your
liking,
and
I
think
that
that
probing
is
going
to
be
very
error
prone.
L
And
the
split
dns
thing
again
is
an
example
of
this.
If
I
I'm
talking
to
somebody
inside
my
my
enterprise
and
I
get
a
c
also
from
them-
and
I
I
don't
know
just
because
of
the
of
the
fact
that
it's
within
my
enterprise
and
therefore
than
my
split
dns-
that
they
wouldn't
designate
somebody
that
didn't
have
access
to
the
same
pool
of
names,
but
I
have
to
work
out
for
myself
whether
they
have
access
to
the
same
pool
of
names.
It's
it's
quite
problematic.
L
To
do
that,
I
mean
I
can
design
new
mechanisms
by
by
probing
and
checking
long-lived
caches,
and
I
can
I
can.
I
can
figure
out
a
way
around
the
problem,
but
it
seems
to
me
much
harder
to
to
develop
as
a
as
a
as
a
piece
of
information
than
simply
saying.
Okay,
I
went
there
for
for
reasons
like
dhcp
assignment
or
ra
assignment,
and
they
have
given
me
this
other
one
that
they
are
willing
to
say
is,
from
their
perspective,
has
access
to
the
same
pool
of
names.
L
That
level
I
think,
is
important
for
us
to
to
try
not
to
just
throw
out
and
say
it's
just
a
random
collection
of
other
resolvers
they
know
about
it,
has
to.
There
have
to
be
some
properties
of
those
other
resolvers
that
they're
willing
to
to
to
make
a
claim
about.
L
K
Please
going
back
to
accuracy
example
with
firefox
that
is
proposing
a
list
of
resolvers
and
let
the
client
choose
which
which
resolvers
you
want
to
configure
is
broader.
I
I
think
it's
a
it's
an
important
use
case
because
firefox
is
not
managing
is
managing
none
of
those
resolvers.
K
It's
just
providing
a
list
and
let
the
client
choose,
and
so,
if
he's
proposing
a
and
b
as
a
two
different
resolvers,
it's
basically
firefox,
as
a
third
party
saying,
I
assume
a
and
b
are
equivalent,
but
none
of
I
mean
a
will
not
be
able
is
not
likely
to
say
I
am
equivalent
to
b
and
b
is
not
likely
to
say
that
is
equivalent
to
a
so.
K
This
somehow
shows
that
the
word
equivalent
in
that
sense
might
be
a
little
bit
misleading
and
because
we
don't
have
this
reflections
between
the
the
the
the
the
proposed
resolvers.
K
But
the
other
thing
is
also
that
firefox
is
not
operating
one
of
those
resolvers.
So
it's
a
little
bit
different
than
the
use
case.
We
started
with
where
the
resolver
was
run
by
the
isp,
and
so
I
I
think
what
should
be
considered
is
a
way
to
express
the
list
of
resolver
that
we
are
that
one
entity
is
recommending
and
and
then
we
need
to
be
able
to
discover
which
entity
we
want
to
be
to
to
ask
for
a
list
of
recommended
resolvers
in
the
case
of
when
we're
using
a
web
browser.
K
K
E
List
thank
you
daniel
lehman.
Please.
E
M
Too
many
mute
buttons
there.
You
are
I'd
like
to
respond
to
ted,
so
I
I
what
I
took
away
from
you.
What
you
said
is
that
that
you
wandered
into
policy
space
twice
in
different
directions.
One
is
that
it
it.
M
How
should
I
first
we
can?
We
cannot.
We
cannot
forbid
the
resolver
to
lie,
and
since
we
don't
really
know
whether
it's
lying
or
not,
what
the
information
it
gives
to
the
client
is,
I
wouldn't
say,
irrelevant,
but
cannot
be
taken
more
seriously
than
a
hint
now.
It
could
be
that
the
the
second
thing
is
that
who
my
trust
as
a
client
is
up
to
me
as
a
client,
and
I
can
have
a
wide
selection
of
policies
one.
M
I
can
select
a
policy
from
a
wide
set
and
one
of
them
is
to
believe
whatever
I'm
told,
which
is
fine
in
in
many
conditions.
So
we
we
can.
I
I'm
perfectly
willing
to
accept
a
situation
where
the
the
resolver
a
says
resolver
b,
is,
is
an
alternative
server.
Please
use
that
instead
and
the
client
says:
okay,
I'm
happy
with
that
and
that's
okay,
it's
a
policy
set
by
the
client
that
says
accept
whatever
you
hear,
but
I
also
want
to
be
for
the
client
to
be
able
to
make
its
own
decision.
M
We
cannot
enforce
that
the
server
this
or
the
resolver.
We
cannot
mandate
the
resolver
to
tell
the
truth
and
because
of
that
fact,
the
decision,
what
to
trust,
must
sit
with
the
client
and
it
can
do
whatever
it
likes
to
verify
or
not
do
whatever
it
likes
to
verify
the
situation.
So
having
the
the
the
resolver
say,
yeah,
please
go
here
and
have
have
the
client
follow
suit,
say:
yeah,
that's
fine!
L
Thank
you
ted
hardy,
please
speaking.
Thanks
largely
that
that
was
a
nice
explanation
of
of
your
your
position
and
I
think,
there's
a
good
bit
to
agree
with
here.
I
think
where
I
don't
necessarily
agree
is
on
on
what
that
mechanism's
limits.
L
Are
you
talked
about
the
hint
portion
of
it
and
whether
we
call
it
a
designation
or
a
hint
or
a
kind
of
become
a
bond,
we'll
call
it
a
pro
tip
right
if
the
edns
zero
pro
tip
contains
a
a
different
resolver
name
and
dot
or
doh
designator,
then
the
message
you're
getting
back
is
you
can
go
over
there
and
this
resolver
believes
that
resolver
has
access
to
the
same
names.
If
that's
what
that
means,
then
it's
just
a
hint
right.
You
may
have
to
go
and
confirm
it
for
yourself.
L
You
may
choose
to
accept
it.
You
may
say
I'm
not
willing
to
accept
it.
As
you
say,
that's
entirely
up
to
your
client
policy,
but
the
semantics
of
what
that
pro
tip
means
has
to
be
pretty
clear
and
whether
it
means
those
people
are
going
to
give
you
d.o.t
or
doh
transport,
and
I
know
nothing
else
or
whether
it
means
those
people
are
going
to
give
you
a
dot
or
dh
doh
transport,
and
I
believe
that
they
are
gonna,
have
access
to
the
same
names.
L
Maybe
because
I'm
the
same
service
right
and
I
I
operate
both
or
whether
it
means
I
believe
that
they
have
a
recommendable
set
of
practices,
because
I'm
actually
going
to
give
you
one
that
I'm
pulling
from
the
the
firefox
tierra.
L
Those
are
different
potential
hints
and
I
think
we
have
to
be
clear
either
that
we're
going
to
pick
one
and
say
that's
what
it
is,
or
we
have
to
have
some
way
in
the
protocol
mechanism
of
telling
you
what
the
hint
means,
because
if
it's
just
there,
there's
also
this
other
entity
out
there,
and
I
have
no
information
about
it
other
than
I'm
going
to
tell
you
what
his
ip
address
is.
Then
it's
this
we
can
stop.
This
is
not
useful.
G
So
this
discussion
is
making
you
reminding
me
why
I
don't
like
requirements
documents
because
it
seems
to
me
we
are
spending
a
lot
of
time,
arguing
about
something
I'm
not
sure
actually
affects
the
protocol,
particularly
so
I'd
like
to
suggest
something
different,
which
is
the
personal
requiring
documents
to
inform
the
protocol.
We
have
a
protocol
proposal
in
the
form
of
gear
now
I
am
not
like
a
fan
of
every
single
bit
of
the
protocol,
but
I
think
it's
generally
the
right
to
the
right
direction.
G
So
I
would
suggest
that
we
put
this
document
on
the
shelf
and
we
discuss
whether
we
should
adopt
deer
and
what
people
think
would
deer
would
be
need
in
order
to
be
acceptable
and
then
and
and
go
from
there
and
not
so
much
worry
about
this
requirements
document.
That's
what
whistle.
M
Thank
you
again
to
ted
in
a
positive
tone.
I
I
think
you
you
hit
something
there.
I
I
think
the
the
the
mechanisms
should
include
the
intended
meaning
of
the
the
information
I
think
your
spot
on
there.
The
semantics
part
that
you
talked
about
this
is
quite
right
and
and
with
that,
I'm
I'm
I
I'm
willing
to
actually
face
it,
adjust
my
stance
a
bit.
So
it's
it's
sounds
like
a
good
idea
to
have
the
resolver
or
the
the
party
that
conveys
the
information
signal.
M
Somehow
that
I
I
I
am
trying
to
convey
this
type
of
information
to
you,
I'm
trying
to
to
to
convey
a
message
with
the
following
content
to
you
and-
and
that
is
an
important
thing.
So
it's
how
it's
received
is
still
a
policy
matter
with
the
client,
but
having
additional
information
that
that,
where
the
the
sending
party
can
convey
the
the
the
notion
that
I'm
I'm
trying
to
tell
you
that,
I
believe
that
these
other
resolver
is
equivalent
to
me.
M
That
is
meaningful
information,
and
I
thank
you
ted
for
reminding
me
of
that.
Thank
you.
Q
So
one
suggestion
is
maybe
in
the
requirement
stock
we
actually
explicitly
listed
list
the
things
which
we
will
be
unable
to
do
right
like
how
much
can
you
trust
the
network?
That's
basically
the
I
think
the
fundamental
issue
here.
How
much
can
you
trust
the
information
you're
learning
from
the
network
right.
E
Thank
you,
penny
tyro
is
actually
in
in
the
queue
without
being
visibly
in
the
queue.
So
terry,
please.
T
Hey
thanks
for
that
mike.
I
agree
with
you
that
it
seems
like
the
working
group
has
mostly
agreed
to
using
network
identifier
and
resolver
identifiers,
two
protocols
for
identifying
encrypted
resources,
and
we
should
go
with
that
and
then
figure
out
a
way
to
prove
equivalence
or
identifying
cryptographically.
Whether
the
alternate
resolver
is
the
best
resolver
that
an
attacker
may
not
be
possible
to
host
and
then
whether
the
client
can
pick
that
up
at
that
seems
to
be
an
alternate,
a
whole
lot
of
different
mechanism.
T
Irrespective
of
whether
network
identified
or
resolved
or
anti-ferropic,
because
both
can
be
susceptible
to
on
path.
Attackers,
and
there
needs
to
be
some
proof
for
the
client
either
with
regard
to
trusted
resolvers
or
some
assertion
from
the
alternate
resolver,
proving
that
it's
being
hosted
by
a
legitimate
entity
and
that
I
think,
should
be
taken
as
a
separate
requirements
or
discussion
at
the
working
group.
But
I
think,
from
a
protocol
perspective.
T
Picking
those
two
alternates
of
network
identifier,
resolver
interface,
would
probably
be
a
way
forward
where
we
figure
out
this
larger
topic
of
identify.
How
identifying
how
the
client
can
make
sure
it's
talking
to
an
resolver,
indeed
provided
by
the
network
and
not
by
an
attacker.
U
Very
good
yeah,
so
just
as
an
author
of
the
deer
work
just
so,
we
can
comment
on
what
ecker
was
saying.
I
I
think,
based
on
this
discussion,
I
I
agree
that
you
know
really.
U
We
are
doing
a
lot
of
bike
sharing
and
wordsmithing
on
how
we
need
to
view
these
things
and
communicate
about
these
mechanisms,
but
it
doesn't
seem
like
we
have
a
lot
of
disagreement
on
what
the
discovery
mechanism
needs
to
do.
So
if
the
group
finds
it
acceptable,
I
think
it
would
make
sense
to
kind
of
progress
on
unblocking
adoption
of
some
mechanisms
and
actually
working
on
those
as
a
group
and
continue
to
keep
those
mechanisms
up
to
date
with
whatever
language
and
bike
shedding.
U
We
have
on
these
definitions
of
whatever
we're
going
to
call
it
equivalence,
dedication,
anything
else,
and
I
would
also
posit
that
he
would
be
probably
more
productive
at
this
point
to
have
us
some
people
go
away
and
make
concrete
textual
proposals
for
terminology
and
descriptions
in
the
forms
of
pull
requests
or
in
the
forms
of
email,
so
that
people
have
time
to
really.
U
J
Please
all
right
yeah
again,
just
just
looking
at
the
chat.
I
think
some
people
have
asserted
that
as
long
as
it's
the
same
entity,
that's
sufficient.
So
I
just
wanted
to
to
capture
the
point
that
actually
for
the
use
case
that
originally
prompted
this
discussion.
J
If
we
can
remember
that
far
back
to
this
morning,
actually
it
does
matter
that
it's
both
the
same
entity
and
the
same
answers
as
far
as
you're
at
you're
able
to
ascertain
because,
for
example,
some
resolver
operators
provide
a
range
of
different
resolvers
with
with
the
that
provide
different
answers,
I'll
pick
on
cloudflare
as
it's
the
first
one
that
springs
to
mind
where
it
has
some
with
no
filtering
so
with
different
types
of
filtering.
J
So
I
think
for
equivalence.
It
matters
it's
both
the
same
entity
and
and
ought
to
be
the
same
answers
and
clearly
for
things
like
designation.
You
wouldn't
have
the
same
requirements
and
that's
completely
fine,
but
for
the
use
case
that
we
started
with
the
that
chris
had
equivalence
as
a
consideration.
J
I
think
both
elements
are
important.
I
just
wanted
to
capture
that,
but,
whilst
I'm
speaking,
I
don't
have
a
problem
with
what
tommy
said
either
in
terms
of
the
need
to
progress
on
other
stuff
as
well.
That
matters
too
thanks.
E
Thank
you
andrew.
I
will
note
that
at
the
moment
the
queue
is
empty
and
I
kind
of
feel
like
well
like
it's
1
30
in
the
morning
and
that
people
I
now
have
a
lot
to
digest.
On
this
conversation,
we
really
haven't
come
to
any
conclusions,
but
hopefully
we
all
understand
each
other
a
little
bit
better
now
and
I'm
going
to
toss
it
back
to
glenn
to
continue
with
the
agenda.
B
Well,
we're
into
the
the
last
sort
of
big
push
here.
We
have
37
minutes
left
in
session,
so
that's
awesome.
So
do
people
have
the
energy
left
in
them
to
go
on
to
the
next
discussion,
which
was
going
back
to
the
slide
here
on
preview.
B
In
particular,
it
seems
based
upon
what
I've
seen
on
list
and
from
some
of
the
get
discussions
for
some
of
the
drafts
that
some
people
have
a
concern
over
whether
this
is
a
a
possible
thing
to
do
in
that
some
certificate
issuing
services
may
not
be
provided
certificates
with
ip
addresses
in
them,
or
support
that
as
a
feature,
and
there
was
some
really
chat
going
back
to
the
very
beginning
on
here
on
this
particular
topic
from
ecker
and
a
few
other
people.
B
So
if
you
guys
would
like
to
sort
of
jump
in
the
queue
here
and
share,
is
this?
Is
this
a
practical
thing
that's
going
to
work?
Is
it
something
we
should
not
do?
Is
this
something
we
should
do?
Is
this
not
something
that
you
can
be
worried
about
and
I'll
turn
it
over
to
my
co-chair
at
this
point
as
I've
seen
that
straight
up
enough
people
get
them
in
the
queue.
G
B
So
sorry,
I
heard
you
said
that
I
didn't
quite
get
what
you
just
said
there.
Could
you
say
it
again.
G
A
Yep,
thank
you
ecker
martin
yeah,
so
the
other
piece
of
this
is
that
they're
very
widely
supported
in
clients
and
you'll
be
able
to
connect
to
a
server
that
has
an
ip
address
certificate
fairly
reliably
in
most
stacks.
So
all
the
browsers
and
things
like
curl
and
whatnot
all
generally
support
ip
address
sense.
T
Yeah
we've
been
talking
to,
let's
encrypt,
for
providing
us
certificates
for
hosting
that
on
the
router
and
as
as
for
my
information,
goes,
they
don't
provide
any
ipad
resource-based
certificates
so
far,.
V
Yeah,
I
was
just
going
to
say
a
concern
I
have
here
is
that,
while
it's
probably
easy
to
get
an
ipad
certificate
for
a
server
that
where
you
control
the
server
and
the
ip
space,
that
is
not
necessarily
true
for
people
providing
either
recursive
or
authority,
recursive
dns
as
a
service
or
any
sort
of
application.
V
You
know
service
provider.
Something
like
that.
I
I
have
some
concerns
around
that
it's
possible
there
this
place,
but
I
think
I
think
that's
going
to
be
challenging
for
for
some
folks.
U
U
However,
just
like
what
martin
was
mentioning
earlier
about,
the
clients
will
evaluate
for
themselves
whether
or
not
they
want
to
trust
the
resolvers
that
they
have
discovered.
U
U
A
A
You
can
authenticate
via
the
certificate
and
that's
even
true
for
cases
where
you're
using
1918
addresses,
for
instance,
but
it
does
require
that
you
have
additional
steps,
because,
obviously
you
can't
get
an
ip
certificate
for
an
ipa
address
that
other
people
can
also
use.
F
Just
responding
to
martin
my
reading
of
deer
specifically,
is
that
it
essentially,
rather
than
trying
to
distinguish
between
the
the
provenance
that
distinguish
the
provenance
of
the
53
ip
in
order
to
determine
whether
it
was
received
over
some
sort
of
secured
or
unsecured
channel.
It
simply
assumes
that
it
might
have
been
delivered
over
a
secure
channel,
and
so
it
applies
these.
These
checks
unconditionally.
A
E
Thank
you,
yeah.
Okay,
we
have
reached
the
end
of
the
queue
and
I
think
that
we're
kind
of
winding
down
on
energy
here
glenn.
Would
you
like
to
bring
it
into
our
planning
for
an
interim
discussion.
B
Did
I
unmute
myself
successfully,
you
did
wow,
I
I
I
and
it's
been
a
long
week,
so
my
ability
to
mute
it
on
mute
is
disappearing.
That's
pretty
bad!
So,
okay,
the
next
topic
and
then
we'll
let
everybody
go,
is
jump
to
it.
Looking
ahead,
itf
110
is
scheduled
for
march.
B
We
seem
to
be
making
progress
both
on
list.
There's
been
a
lot
of
good
activity
and
it's
a
fantastic
discussion
this
last
week
here
it
takes
our
momentum
up.
We
have
the
holidays,
of
course,
coming
up
for
a
great
many
people,
so
it
would
seem
that
late
january
early
february
would
be
a
an
appropriate
time
to
have
an
interim.
So
just
as
sort
of
a
a
quick
poll,
and
shall
we
do
that?
Should
we
try
to
use
the
hands
tool
this
one?
How
do
you
do
that
one?
B
Maybe
I'm
pretty
tired
to
actually
figure
out
how
to
use
a
new
tool
right
now?
Sorry,
just
generally,
oh,
I'm
gonna
put
it
up.
Should
we
have
an
interim
I'll
put
up
the
the
hands
tool
here
february.
B
B
And
then
for
those
of
us
who
are
in
the
the
dark
time
zone
at
the
moment,
we
can
all
go
to
sleep.
B
Or
go
our
next
session,
okay
recession!
When
so,
and
it's
unduly
I'm
going
to
sleep
because
I
have
a
session-
I
have
a
session
here.
That
starts
up
at
three
o'clock
so
in
the
morning.
So
I'm
going
to
try
to
grab
a
couple
hours
between
now
and
then
all
right.
So
we're
look
we're
getting
a
pretty
good
turnout,
29
people
so
far
have
said
yes,
that
we
should
have
a
thing.
So
that
seems
like
I'm
gonna
call
and
say
we
probably
will
have
an
interim
well.
E
Okay,
it
looked
like
a
hundred.
People
were
in
the
queue
so
andrew.
You
actually
intend
to
be
in
the
queue
right
now.
Let
me
go
ahead
and
speak.
J
Yes,
I
that
was
indeed
intentional.
I
just
wanted
to
say
well
two
things,
firstly,
on
the
presumption
that
there's
something
worthwhile
discussing
when
we
get
there
clearly
having
an
interim
seems
like
a
good
idea.
I'd
go
so
far
as
to
suggest,
maybe
even
considering
provisionally
looking
at
two
dates,
because
that
seemed
to
work
quite
well
for
the
last
sort
of
virtual
interims,
with
maybe
a
gap
of
a
week
in
between
them
again
on
the
assumption
that
progress
has
been
made
and
there's
substantive
content
to
discuss.
B
Any
other
comments:
well,
if
you
have
cookies,
where
you
are
feel
free
to
go,
eat
them
and
with
that.
Thank
you
so
much
for
joining
us
here
at
the
on
friday
or
thursday,
wherever
you're
at
and
that's
the
end
of
it.
E
For
one
on
one
also
thank
you
to
our
notetakers
for
the
heroic
job.
You
do
lots
of
fantastic
notes
in
there
and
we
really
do
appreciate
the
effort.
So
thank
you
so
much
bye.
All.