►
From YouTube: IETF114 ADD 20220726 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
Hi
all
bear
with
us
a
second
while
we're
still
getting
prepped
for
presentations.
One
quick
question
normally
in
advance.
I
try
to
get
a
scribe.
We
have
utterly
failed
to
do.
That
was
not
on
top
of
it.
If
anybody
is
able
to
describe
for
us,
please
let
me
know
tim
would
normally
do
it,
but
he's
going
to
be
co-chairing
the
deprived
half
of
the
session,
so
a
scribe
would
be
greatly
appreciated.
C
Right
I
meant
to
ask
glenn:
are
you
use?
You
are
online
good?
I
don't
know
if
you
want
to
explain
why
you're
not
sitting
up
here
or
whether
what
that
is
so
jump
on
in
and
say
something.
B
D
H
C
Right
I
asked
glenn
but
he's
still
not
responding.
C
C
Actually
glenn,
if
you
can
hear
me,
please
buzz
in.
C
D
C
Yes,
please
go
eric
welcome
to
our
area
director
eric
who
will
has
a
very
short
presentation
on
some
new
plans
in
the
itfdns
space.
H
So
I
prepared
some
slides,
they
will
be
into
the
materials,
but
it's
basically
three
slides
explaining
that
more
and
more
draft
are
relying
on
dns
team
was
kind
enough
to
make
some
statistics.
If
not
mistaken.
There
were
about
59
draft
that
were
using
the
word
dns
in
the
title
or
in
the
abstract,
so
there
are
way
more
documents
using
dns
than
one
identify.
My
team,
some
of
them
are
from
this
group
from
deep
drive,
dns,
op
or
add,
of
course
right
and
basically
those
people
in
those
working
group
understand
dns.
H
So
when
a
working
group
has
got
a
dash,
0
0
that
has
been
adopted,
they
can
request
an
early
review
of
their
draft.
Pretty
much
like
the
young
doctors
right,
but
having
something
called
dns
doctors
does
not
look
very
nice,
so
we
call
it
the
next
directorate
right
simply
so
it
will
be
created
shortly
after
this
iitf
meeting
warren
and
myself
will
be
sending
an
email
asking
for
volunteers.
You
can
go
to
the
last
slide
would
be
superb.
H
That's
basically
the
statistics
done
by
tim,
so
the
next
step
is
really
around
august.
I
am
sending
and
one
will
be
sending
for
dns
up
an
email
asking
for
volunteers
for
the
reviewers
and
the
goal
for
us
would
be
to
get
a
very
experienced
reviewers
as
well
as
less
experienced
reviewer,
but
they
are
eager
to
learn
about
what
is
the
review
task
and
basically
become
maybe
more
than
a
reviewer
later
right.
H
The
goal
of
the
isg
is
really
to
get
a
pipeline
of
talents
right
to
get
from
lurkers
to
authors,
reviewers,
shepherds
chairs
or
whatever,
and
becoming
a
doieb
member.
So
that's
really
important
to
get
this
balance.
We
are
also
looking
for
two
directorate
secretaries
that
are
basically
the
person
assigning
reviews
to
the
people.
H
C
H
I
Yeah,
so
so
this
is
anacond
gilmore
aclu.
So
I
appreciate
this
work.
The
attempt
to
try
to
provide
an
overview
from
the
dns
point
of
view,
but
I'm
also
not
sure
that
I
know
that
there
is
a
dns
point
of
view,
say
a
point.
So
I'm
wondering
do
you?
I
Do
you
have
a
like
any
sort
of
rubric
that
you
would
expect
reviewers
to
use,
I
mean,
are
we
talking
about
like
I
run
resolvers
within
my
organization,
and
I
want
to
make
sure
this
draft
doesn't
screw
them
up,
I'm
responsible
for
the
authoritative
zone,
I'm
thinking
about
things
architecturally,
I'm
worried
about
cryptographic,
processes,
I'm
worried
about
udp
limits
like
there's
a
whole
range
of
different
things
to
think
about.
H
And
that's
a
fair
point
again
so
as
usual
right,
the
perfect
is
admin
of
the
good
right,
so
any
review
early
stage
is
better
than
something
at
the
isg
level
later.
So,
even
if
not
perfect,
it
would
be
nice,
but
I
think
that
they're
asking
for
the
secretary
of
this
dns
directorate.
They
know
the
experience
of
all
the
reviewers
and
if
they
quickly
look
at
the
abstract
of
the
the
id,
they
could
select
the
right
person.
H
E
James
speaking
solely
for
myself,
eric
for
the
members
of
this
direct
eric,
so
my
name's
jim
reed.
Sorry,
if
people
didn't
pick
me
up
in
the
mic
there
speaking
for
myself
and
the
plans
for
the
members
of
this
directorate
and
the
secretariat
function
that
you
were
talking
about
here,
they
expect
to
go
through
all
of
the
submitted
drafts
to
look
for
dns,
related
content
or
those
that
are
putting
dns
related
content
in
the
draft
speak
specified
to
notify
the
director
of
the
secretariat
thing
you're
talking
about
what
is
it
going
to
be.
H
So
the
rules
and
the
procedures
will
still
need
to
be
refined
right
and
the
experience
will
tell,
but
the
expectation
is
really
to
the
other.
Working
group
shares
right,
no
team
and
the
brand
of
the
world,
but
somebody
doing
young
models
right
yeah
that
would
talk
about
it.
Oh
maybe
there
is
dns
content.
I
know
I
will
request
a
review.
Okay.
Thank
you!
Okay.
Yes,
it's
endless
story.
J
Well,
hoffman,
so
I'm
a
little
bit
concerned,
but
you
have
time
to
allay
my
concern.
I
am
concerned
that
one
of
the
reviews,
one
of
the
early
reviews,
is
going
to
come
back
to
a
working
group.
Saying
don't
do
that
in
the
dns
or
you're
doing
it
wrong.
Is
that
actually,
since
some
people
will
say,
don't
do
into
dns
a
different
reviewer
would
say:
that's
just
fine
or
whatever?
J
H
C
C
Since
we
got
a
little
bit
of
a
late
start,
thanks
to
the
clown
show
that
was
going
on
up
here,
I
will
just
really
blow
through
our
slides
really
quickly.
As
far
as
the
chair
slides
go
you're
all
familiar
with
the
no
well.
By
now,
if
you're,
not,
then
please
look
it
up
separately,
because
I'm
not
giving.
C
To
read
it
here,
it
is
the
standard
ietf
noel.
The
one
thing
that
we've
been
asked
to
emphasize,
though-
and
you
know.
K
C
Like
we
have
pretty
high
compliance
rate
in
here,
but
in
a
meeting
room
you,
it
is
a
requirement
of
the
conference
that
you
wear
your
mask
please
and
done
just
a
couple
of
other
links
for
our
agenda
and
all
hi,
I'm
dave
lawrence
glenn
is
online.
He
unfortunately
could
not
be
in
the
room
with
us
today.
You
just
met
eric
our
area
director,
and
we
want
to
put
a
special
thanks
to
andrew
kampling,
who.
C
For
the
first
time
in
the
itef
took
on
the
role
of
document
shepard
and
worked
through
three
pretty
large
documents
and
really
helped
get
them
advanced
forward,
so
thank
you
very
much
to
andrew.
We
have
really
progressed
these
now
through
ie
iesg
review.
The
status
of
the
documents
is
really
quite
solid,
so
in
that,
in
that
10
minutes
of
clown
show,
did
any
of
you
come
up
with
a
burning
desire
to
be
our
scribe.
Please,
oh
look
at
that,
mr
hoffman.
Thank
you
very
kind,
sir.
C
Welcome
from
the
chairs
welcome
bendy
bill
coleman,
a.d
comments.
That
would
be
you
eric.
He
he's
commented
he's
done
the
status
updates
on
our
documents.
Of
course,
glenn.
I'm
sorry,
his
mic
is
not
working
because
I'm
not
sure
exactly
what
he
wanted
to
say
about
these
other
than
they
have
been
progressing
nicely
again,
thanks
to
both
the
shepherding
of
andrew
and
then
very
thorough,
iesg
looks
at
it.
There
are
a
few
discussed
items
that
are
outstanding.
C
C
I'm
being
told
the
volume's
a
bit
low,
but
that
might
be
because
my
face
is
not
adequately
in
the
microphone
and
so
the
status
right
now,
though,
is
really
solid
for
these
documents
that
are
in
iesg
review
and
are
expected
to
move
forward
to
publication
imminently,
or
rather
they
go
to
off
48,
of
course,
for
per
process.
But
we
expect
approval
for
eventual
eventual
publishing
as
an
rfc,
then
here's
the
timeline,
I'm
not
sure
glenn.
Please
comment
in
chat
and
I'll
be
happy
to
relay
it
to
the
microphone.
C
What
you
wanted
to
observe
about
this
particular
document
other
than
that
it
is
a
draft
that
the
working
group
has
adopted,
and
I
will
just
wait
for
glenn.
If
you
want
to
make
any
additional
comment
here.
Oh
they
have
slides,
so
we're
going
to
be
doing
a
presentation
for
that.
The
dns
resolver
information
draft.
C
At
this
point-
and
so
here
again
our
current
drafts
ben
has
another
draft
that
is
not
gone
through.
Ietf
adoption
call
yet,
but
I
expect
we're
moving
in
that
direction.
Right.
Oh
ben
will
comment
on
that.
L
I
I
just
wanted
to
correct
that
this
this
document
is,
is
a
document
that
went
through
a
working
group.
Adoption
call
and
did
not
get
adopted
it.
It
failed
the
adoption
quality
right
here
in
add
and
and
and
this
session
we
are
presenting
it
again.
It
has
been
substantially
changed,
incorporating
a
lot
of
feedback
and.
L
I
believe
chris
chris
box
will
be
going
through
the
details
of
them.
C
Right
and
I
apologize
for
having
ill
prepared
myself
to
speak
to
that
the
glenn's
inability
to
be
here
kind
of
really
threw
a
curveball
at
us
all.
However,
I
believe
we
are
ready,
then,
to
move
on
to
our
first
presentation,
which
is
going
to
be
on.
Do
you
have
the
agenda?
I
don't
know
that
the
slides
are
in
order.
Is
the
thing?
C
And
this
is
dan
wing.
Are
you
presenting.
C
Dan
is
miked
in
if
from
remote,
do
you
want
to
drive
your
own
slides,
sir.
C
Right:
okay,.
C
Lovely,
how
do
I
pass
control
to
you?
K
M
I'm
dan
wing:
this
is
the
split
horizon
authority.
It
just
became
a
zero
zero
for
the
working
group
in
this.
So
as
we
transition
this
from
individual
to
working
group
draft
we
introduced
and
and
refined
the
term
split
horizon,
dns
and
validated
split
horizon.
They
have
kind
of
the
obvious
meaning,
but
we'll
touch
on
them.
Briefly
updated.
M
The
scope
talked
about
how
to
use
a
pre-pre-configured
external
resolver
in
dns
and
have
a
little
bit
of
detail
on
that
and
how
we
are
avoiding
leaking
the
internal
data
domains
to
external
resolvers,
which
was
a
concern
that
came
up
early
on
so
terminology
split
horizon
dns
is
where
we
are
forking
off
a
different
view
of
what
the
dns
is
from
for
internal
use
or
for
non-public
use
and
then
what?
What
is
on
the
public
dns?
M
It's
been
around
for
a
long
time
frequently
frowned
upon,
but
this
seems
to
be
the
closest
definition,
closest,
concise
definition
that
we
could
reach
in
the
document
so
far
and
then
validated
split
horizon
is
the
thing.
This
draft
is
mostly
concerning
itself
with,
which
is
make
sure
that
when
there
is
a
split
horizon,
the
owner
of
the
domain,
the
public
owner
of
the
domain
feels
that
this
split
is
legitimate.
M
So
this
is
what
prevents
this
draft
from
being
useful
for
filtering,
and
this
has
been
some
confusion
with
earlier
versions
of
this.
That,
because
split
horizon
and
rpz
are
both
kind
of
used
today.
As
mechanisms
to
achieve
filtering,
this
draft
does
not
help
with
towards
those
ends.
The
validated
split
horizon
uses
either
dns
sec
or
querying
a
public
resolver
to
determine
that
the
split
is
authorized
by
the
domain
owner.
M
So
that
helps
constrain
our
scope,
of
course,
which
is
has
been
our
goal
in
the
draft
for
a
while.
But
again
it's
refined
a
little
bit
in
this
version,
so
we're
allowing
the
domain
owner
to
authorize
a
split
horizon
view
of
their
domain.
M
So
it's
useful
everywhere
that
this
might
be
needed
so
for
home
networks,
enterprise
networks,
service
providers,
especially
mobile
service
providers,
interested
in
this
sort
of
thing,
and
that
there's
no
prior
configuration
of
the
end
point
that
a
domain
hint
was
authorized.
It
can
all
be
checked
by
doing
the
dns
sect
check,
like
I
said,
or
the
public
dns
check.
The
public
resolver
check.
M
As
I
discussed
so
these
are
the
the
steps
what's
in
blue,
so
this
is
not
changed,
but
this
is
just
an
overview.
What's
in
blue
are
how
things
are
learned,
so
this
is
not
unique
or
or
introduced
by
this
draft.
M
What
is
unique
and
and
introduced
by
this
draft
is
what's
in
green,
so
that's
where
we
connect
to
the
cl
the
name
server
that
claims
to
own
this
split
horizon
and
verify
that
it's
been
authorized
by
talking
with
directly
with
it
and
those
that
and
some
steps
operated
on
the
client
are
how
we
achieve
that
verification
that
it's
an
authorized
split
of
dns.
M
And
this
is
something
probably
want
the
working
group
to
touch
on
or
to
you
know,
folks,
to
kind
of
highlight
to
review,
because
we
we've
kind
of
moved
around
on
this
text
a
couple
of
times
and
that's
how
how
to
best
word.
This
as
a
must-not
is
what
we
have
in
there
right
now.
But
we've
had
a
couple
of
comments
on
that
exactly
how
to
work.
This
is
how
to
do
the
dns
sect
validation
in
a
way
that
doesn't
weaken
anything
when
we're
trying
to
validate
the
the
split
horizon.
M
This
kind
of
touches
into
you
know
captive
portal
can't
do
dns
tech
validation.
Quite
yet,
when
we're
trying
to
do
this
split
horizon
validation,
oftentimes,
we
are
in
a
captive
portal
situation
so
when
that
when
that
gets
triggered
and
when
we
can
start
doing
the
local
dns
sec
validation
and
when
we're
out
of
captive
portal
turns
into
an
interesting
timing
issue
that
I
think
we
would
want
to
touch
on
and
get
some
further
feedback
on
from
the
working
group
and
read
this
section
of
the
draft
and
an
important
point.
M
Some
of
the
review
comments
early
on-
I
think
we've
resolved
these
completely
now,
but
to
not
leak
internal
domain
names.
So
we
do
leak
out
to
the
public
resolver.
If
the
public
resolver
is
queried
that
you
have
an
internal,
you
know,
split
horizon,
you
know
internal.example.com
or
corp.example.com
or
whatever.
That
is,
but
we
don't
leak
out
the
internal
host
name.
So
the
super
secret
hostname
of
www.
M
Example.Com,
we
don't
leak
out
the
mail,
the
hostname
portion
of
that
some
there's
some
interest
in
keeping
that
internal.
You
know
not
not
leaking
that
out
and
and
to
be
clear,
we're
not
leaking
out
that
hosting,
but
we
do
leak
out
if
we
are
triggering
off
of
that
zone
name.
So
the
internal
dot
example.com.
E
M
With
zero
zero
again,
mostly
tying
things
up
from
the
individual
draft
to
the
first
working
group
iteration
of
this
document,
so
are
there
any
comments,
questions.
L
Hi
ben
schwartz,
I'm
one
of
the
one
of
the
listed
authors
here
this
I
think
the
my
real.
My
big
question
here
is
is
really
what
changes
do
people
want?
You
know
this
draft
is,
in
my
view,
self-consistent.
L
You
know
implementable
as
written
and
and
so
you
know
we're
in
the
working
group,
but
you
know
there's
no
reason
to
stay
in
the
working
group
unless
and
you
know
no
reason
to
delay
a
last
call
unless
there
are
changes
that
people
want
and
it
you
know
from
the
discussion
during
adoption,
it
does
sound
like
there
are.
There
were
some
people
who
felt
the
changes
were
were
needed,
so
I'd
like
to
to
hear
those
concerns
and-
and
you
know
see
if
we
can
get
moving
on
them.
L
I
want
to
point
out
that
earlier
revisions
of
this
draft
said
something
very
specific
about
provisioning
domains
and
so
to
anybody
who
thinks
that
who's
still
thinking
about
this.
In
those
terms,
the
draft
has
evolved
somewhat
and
at
this
point
talks
very
generally
about
the
idea
of
a
local
domain
hint
and
there
are
all
sorts
of
different
ways
that
your
local
network
might
tell
you.
L
I
F
N
Hello
thanks
for
the
document,
I
think
one
thing
would
be
good
before
we
move
immediately
to
last
call,
since
it's
quite
new,
be
good
to
also
see
some
implementation
deployment
experience
in
some
networks
that
are
doing
this.
N
The
question
I
had
looking
through
this
when
we're
talking
about
validating
the
kind
of
the
authority
over
the
hints
one
of
the
requirements
it
has
in
there
is
that,
essentially
you
either
doing
dnr
on
your
network
or
you
have
like
v2
other
types
of
split
domains
is
that
is
that
a
strict
requirement
like
essentially
I'm
wondering
like
when
we're
asking
someone
to
be
able
to
do
this,
because
there
are
lots
of
scenarios
where
our
devices
are
in
split
dns
environments?
N
Are
we
saying,
like
you,
must
always
upgrade
to
dnr
before
this
is
really
viable?
Are
there
other
things
that
could
be
done
like,
like
is
you
know,
is
some
setup
of
ddr
okay
or
like?
Is
there
something
else
that
is
a
sufficient
hit
to
upgrade.
L
So
ben
schwartz,
the
the
restriction
to
dnr
and
not
ddr,
is
because
dnr
gives
us
a
unique
hostname
to
identify
the
resolver.
Ddr
does
not
provide
us
with
a
unique
hostname.
It
does
provide
us
with
a
valid
certificate
that
contains
zero
or
more
host
names.
If
the,
if
that
certificate
contains
one
or
more
host
names,
then
you
could
potentially
use
a
mechanism
essentially
just
like
this,
but
it
would
require
you
to
do
this
thing.
L
Do
this
slightly
odd
dance
of
connecting
to
the
server
getting
a
certificate
back
and
then
iterating
over
the
list
of
names
that
are
in
the
certificate
and
processing
them
through
checking
them
against
this
list?
Looking
for
a
match,
and
so
it's
a
very
unusual
mode
of
certificate
validation,
and
for
that
reason
we
didn't
specify
it,
but
it
can
be
done
securely.
So,
if
you
think
it's
worth
pursuing,
then
that's
something
that
we
can
certainly
push
on.
N
Yeah,
I
think,
that's
kind
of
the
main
feedback
I
would
like
to
see
because,
like
yes,
I
get
that
it
is
far
uglier
and
it
involves
more
steps
on
the
client.
However,
I'm
thinking
you
know
this
is
super
useful
for
enterprise
deployments,
where
I
imagine
it
will
be
far
easier
to
do
some
of
the
updates
on
the
back
end,
to
make
it
possible
to
do
this
validation
and
some
of
their
equipment.
C
O
Yeah
so
this
will
be,
I
would
say,
a
quick
presentation
of
the
the
recent
update
we
have
on
this
draft.
So
please,
if
you
can,
move
to
the
next
slide,
so
in
in
this
slides,
we
have
a
summary
of
what
we
have
in
the
during
the
last
80s
meetings.
So
this
is
the
we
shortened
the
list
of
the
attributes.
We
are
currently
advertising
for
the
reservoir,
so
we
have
something
which
is
really
very,
restrict
and
limited.
K
O
Mainly
used
for
the
diagnostics
that
it
can
be
exposed
not
not
exposed
directly
to
the
to
the
users
and
the
last
modification,
and
the
importance
that
we
made
is
that
we
stretch
the
validations
that
we
we
are
requiring
for
some
of
the
consumption
of
the
of
the
attributes.
Next
slide,
please.
So
this
is
basically
for
us.
I
think
as
we
as
authors.
O
We
think
that
the
the
document
is,
I
would
say,
in
a
stable
state,
and
we
would
like
to
to
proceed
with
the
the
I
call
for
adoption
for
for
for
this
document,
especially
because
this,
I
would
say,
meet
one
of
the
started
item
we
have
on
the
in
this
working
group,
which
is
explicitly
shorter
to
provide
them
a
solution,
for,
I
would
say,
the
discovery
of
the
information
of
the
reservoir
information.
O
So-
and
we
are
another
item-
is
that
we
are
using
this
solution
for
another
solution.
We
have
in
another
working
group
to
restrict
some
of
the
options
we
are
using
for
the
destructured
errors
that
we
are
providing
to
the
customers.
So
there
is
this.
I
would
say
a
clear
need
for
this
solution
to
provide
the
two
one
of
the
shorter
items
for
the
add
working
group,
but
also
for
other
use
cases.
C
Yeah,
okay,
thank
you
very
much.
The
queue
is
open
for
feedback.
G
Hi
punitsud
from
google
public
dns,
so
the
general
structure
looks
fine.
I
have
one
question
and
one
suggestion
on
the
format.
So
the
main
question
is
I
skim
through
the
list
to
see
the
discussion
and
it's
mostly
the
authors
and
benchmarks.
I
have
not
seen
interest
from
implementers.
So
I'm
curious
if
there
are
client-side
implementers
who
are
willing
to
implement
this
protocol.
O
Yes,
at
least
for
my
knowledge,
I
am
not
an
implement,
I
don't
have,
I
would
say,
a
client
in
which
we
we
will
implement
this.
We
are
more
on
the
network
side,
so
this
is
the
equation
for
the
working
group.
So
if
there
are
implementers
that
are
interested
to
have
this,
this
feature
it's
up
to
them
to
to
disclose
yeah.
O
G
Yeah,
because
I
would
like
to
see
some
implementer
interest
before
the
this
draft
is
taken
on
board
by
the
working
group,
the
other.
It's
a
suggestion.
The
the
format
of
the
resinfo
has
like
a
x
string
for
a
bunch
of
dns
options.
O
O
C
C
Yes,
we
have
no
magic
clicker,
so
you
just
go
ahead
and
this
is
the
verified
selection
of
the
option
right.
P
Hi
everyone,
so,
as
ben
mentioned
there
is
a
new
revision
of
this
draft
was
posted
two
weeks
ago.
It's
got
a
new
name,
so
it's
now
called
reputation,
verified
selection
of
upstream
encrypted
resolvers,
and
this
is
all
about
these
things
yeah,
so
the
home
routers
in
millions
of
homes
sitting
there
in
the
corner,
people
generally
ignore
them,
but
they
are
hard
to
upgrade
and
if
you,
even
if,
as
an
isp,
you
send
someone
a
replacement
router,
often
they
just
ignore
it.
P
So
the
question
is:
how
do
we
give
these
people
encrypted
service?
So
this
ben
presented
this
the
previous
one
in
in
vienna
and
subsequently
in
april
there
was
an
adoption
call
and
in
that
call
there
were
some
indications
of
support,
but
there
were
also
some
valid
points
made
that
we
agree
needed
thinking
about.
So
the
structure
and
flow
quite
confusing.
It
needs
a
normal
introduction.
P
It
defines
what
was
called
a
relaxed
validation
policy,
which
was
seen
as
problematic
because
it
didn't
really
go
into
what
the
client
should
do
it
was.
There
was
a
lot
of
discussion
about
the
problems
that
could
arise
but
they're
in
later
sections.
P
So
if
you
go
to
the
next
slide,
please
so
the
the
zero
two
draft
is
significantly
changed.
It's
it's
no
longer
informational,
which
is
what
the
previous
one
was.
This
draft
now
proposes
what
client
should
do
and
what
it
does.
It
requires
the
use
of
a
reputation
system
to
give
an
opinion
on
the
discovered
encrypted
upstream
resolver.
P
P
So
we
did
note
some
two
issues
with
this,
so
one
is
if
the
local
forwarder
is
providing
an
essential
blocking
function
like
for
malware.
It
should
be
told
to
block
this
cross
forward
upgrade
so
we're
assuming
here
that
any
resolver
that
is
doing
blocking
has
some
means
of
which
you
can
update
what
exactly
it's
blocking.
P
So
you
can
add
resolver.arpa
to
that,
and
by
that
means,
you're
blocking
the
cross
forward
upgrade
the
other
one
is
clients
should
be
capable
of
detecting
which
names
are
part
of
a
split
horizon,
so
they
can
exempt
those
queries
from
a
cross-folder
upgrade.
So,
for
example,
example.local.home.arpa.
P
P
So
this
is
all
about
the
reputation
system,
so
embedding
a
list
of
known
trusted
resolvers
in
the
client
is
only
one
possible
model
for
assessing
that
reputation.
So,
in
future
a
range
of
online
reputation
systems
might
be
available
to
queried
and
they
they
would
could
each
return
an
answer
according
to
their
own
specific
criteria.
So
you
might
have
a
wrong
property,
such
as
the
jurisdiction
of
the
resolver
or
its
certification
by
a
particular
body.
P
It's
out
of
scope
for
the
draft
to
define
the
query
methods.
Just
it
just
notes
that
designers
should
be
aware
of
bootstrapping
problems
in
looking
that
up.
P
So
if
you
are
a
developer
of
client
software,
why
should
you
care
about
this?
So,
as
we
kind
of
mentioned
at
the
beginning,
so
there's
a
larger
fraction
of
residential
internet
users
rely
on
local
dns
forwarders
that
are
not
compatible
with
ddr,
because
they
are
on
a
private
ip
address
and
they
are
difficult
to
upgrade.
P
So
if
we
do
nothing,
it's
likely
that
that
half
of
those
users
will
continue
to
be
relying
on
doe
53
and,
of
course,
that
means
that
they
are
subject
to
passive
monitoring
either
on
the
local
network
or
between
that
network
and
the
upstream.
P
P
So
in
the
draft
it
does
define
a
particular
way
of
confirming
the
identity
of
the
upstream
resolver
that
we've
been
pointed
towards,
and
in
fact
the
method
is,
is
the
one
that
ben
ben
mentioned
earlier
about
getting
the
certificate
and
iterating
through
doing
the
dance
as
it
was
put
another
an
alternative
to
that
is.
P
We
could
just
look
at
the
service
binding
target
name
and
use
that
as
the
resolver
identity,
but
that
would
require
the
use
of
s
I
and
it
would
not
be
compatible
with
all
upstream
resolvers.
P
The
other
open
question
is
we
could
simplify
the
resolver
identity
so
currently
for
do
the
resolver
identity
is
the
uri
template?
We
could
shrink
that
down
to
just
the
domain
name.
That
makes
the
reputation
systems
easier
because
you
just
have
to
define
a
reputation
for
whatever
the
domain
name
is,
but
the
problem
with
n.
Is
you
don't
you
can't
differentiate
between
different
uri
paths
on
the
same
domain
name?
P
K
Eric
google,
mostly
just
a
general
vote
of
confidence.
I
liked
the
last
version
of
this
and
thought
it
was
the
best
plan
to
solve
the
problem
of
upgrading
when
the
home
routers
are
in
play
and
this
new
version,
it
does
a
lot
of
clarifications.
It
mostly
mandates
the
part
of
the
original
strategies.
I
wanted
and
allows
other
parts
I
wanted,
and
so
for
all
I'm
still
happy
with
this
and
still
want
to
do
it.
So
I'm
still
enthusiastic-
and
I
still
want
this
to
be
adopted.
F
Hi,
I
just
wanted
to
say
on,
I
suppose,
on
the
second
question
that
chris
asks
given,
I
think
we
had
stats,
possibly
from
google,
that
85
percent
of
traffic
comes
from
private
ip
addresses
that
this
is
extremely
beneficial
to
users.
F
So
we've
got
to
have
a
solution
to
the
problem
of
how
to
support
consumers
in
probably
most
markets
geographically
around
the
world.
This
does
it
so,
unless
we've
got
a
better
idea,
we
need
to
move
forward
with
this
as
soon
as
we
can.
Q
I
find
a
new
direction
quite
interesting
if
I'm
understanding
the
presentation
correctly
admitting
that
I
haven't
read
the
full
text
yet
that,
instead
of
trying
to
address
the
problem
of
if
the
upgrade
was
secure,
it's
more
about
somehow
I
got
to
a
new
resolver
and
I
would
like
to
know
if
this
resolver
independent
of
how
I
found
it
is
trustworthy.
Q
Generally
speaking,
I
think
that's
a
better
security
approach,
so
thanks
for
addressing
that
feedback,
I
will
say
in
terms
of
interest
and
adoption
that
I'm
it's
hard
for
me
to
imagine
a
way
in
which
our
ecosystem
would
benefit
from
having
such
a
system.
I
say
that
because
we've
desperately
avoided
having
a
trust
list.
Note
that
the
list
of
resolvers
that
currently
ships
in
windows
is
a
bootstrapping
convenience.
Q
We
don't
trust
those
resolvers
any
more
than
we
trust
any
other
resolvers.
We
fully
rely
on
the
user
to
to
select
a
resolver,
and
so
the
question
I
would
pose
in
terms
of
interest
in
adoption
from
the
client
side
is
if,
as
a
client,
I
am
having
some
custom
solution
to
evaluate
the
trustworthiness
of
resolver.
That
means
I
have
some
idea
of
who
I
trust,
why
not
have
some,
similarly
out
of
band
specific
to
me
mechanism
to
simply
provide
the
resolvers
to
the
client?
C
Next
on
the
agenda
is
a
time
for
open
discussion
and
aob's.
If
anybody
had
either
something
they
want
to
revisit
some
general
comments
to
offer
glenn
and
I
actually
do
have
an
aob,
but
we
have
decided
to
put
it
off
till
ietf115
when
we
both
can
be
fully
engaged
in
it.
C
Tim's
making
motions
like
he
did,
but
I
think
in
that
case
I
want
to
invite
glenn
to
the
microphone
because
he
claims
he
has
a
working
microphone.
Now
glenn.
Try
your
mic!
Oh
he's
on
fantastic!
R
So
you
know,
I
think,
in
terms
of
planning
a
wrap-up.
Thank
you
for
being
patient
with
us
as
we
got
the
kinks
worked
out
of
the
system
here.
I
think
tail
and
myself
work
best
when
we're
a
team
and
when
one
of
the
team
is
actually
working
his
job
properly
and
and
not
just
dumping
on
the
other
guy.
So
my
apologies
from
from
not
holding
up
my
side
of
the
the
production
quality
here
other
than
that,
I
think
we
were
in
really
good
shape.
R
You
know
I'm
glad
that
we've
got
the
three
drafts
that
are
now
going.
You
know
through
through
the
final
parts
of
the
process.
That's
really
wonderful!
You
know
I
I
want
to
point
out.
This
is
the
first
time
addd
has
met
in
person.
Actually
you
know
at
least
the
first
time
you've
had
one
of
the
chairs
in
the
room.
So
you
know
pat
yourselves,
on
the
back.
R
We've
done
this
in
the
last
two
years,
all
virtually
and
the
fact
we've
actually
got
three
drafts
now
on
their
way
off
and
we've
got
a
couple.
More
good
ones
in
the
pipeline
is
quite
the
a
testament
to
how
well
this
group
has
come
together
and
worked
very
hard
over
the
last
two
years.
So
my
thanks
to
you
for
being
a
really
good
group
to
manage.
C
Yeah
along
those
lines,
perhaps
the
pandemic
actually
worked
in
our
favor.
The
word
ever
since
the
beginning
of
dough.
There's
always
been
this
expectation
that
there
were
going
to
be
a
lot
of
fisticuffs
around
this
whole
topic
area,
and
so
the
group
has
been
remarkably
civil
has
done
very
well
and
we're
all
very
thankful
for
that.
C
But
that
really
would
be
the
end
of
the
add
a
session
unless
eric
wants
to
comment
on
anything
he's
shaking
his
head.
No,
so
I
would
just
again
like
to
thank
everybody
for
participating.
You've
been
doing
a
wonderful
job
and
again
thank
you
to
paul
hoffman
for
volunteering
to
be
our
scribe,
and
now
I'm
going
to
turn
it
over
to
tim
to
run
the
deprive
half
of
our
session.
B
Thank
you.
Thank
you,
dave
and
dave's
going
to
run
slides,
mostly
because
I've
watched
this
laptop
drop
internet
twice
and
meet
echo
during
this
session.
So
sorry,
wireless
you're,
not
holding
up
for
me
very
well
so
so
welcome
to
the
to
the
deprived
section.
You've
seen
the
note
well
already
from
dave,
I'm
tim
wisinski
eric
over
there
is
our
very
responsible
a.d
he's.
It's
also
his
birthday
he's
29
years
old.
I
believe
he
said
so.
B
B
A
Me
know
this
is
barry
I'm
asking
about
logistics
for
dealing
with
this.
I
presume
that
we
all
stay
in
the
add
session.
A
About
the
the
chat
the
zulip
chat,
it.
B
Should
be
the
same
and
then
what
we'll
do
it
they'll
be
combined
into
the
minutes
and
we'll
probably
break
them
out
into
minutes
for
both
of
us
as
well.
That's
what
we
did
last
time
and
it
seemed
to
seem
to
work
very
well.
Thank
you.
So
we
like
I
like
to
copy
the
minutes
copy.
The
chat
into
the
minutes
at
the
end
is
sort
of
like
it's,
because
it's
a
great
way
to
sort
of
track
all
the
conversations
sort
of
thing
so
you've
seen
the
code
of
conduct.
B
You
know
about
the
masking
policy,
let's
pop
off
our
agenda's.
Pretty
short,
we
we've
got
some
working
group
status
where
we
stand
things
of
that
nature
and
we're
going
to
discuss
unilateral
probing
daniel.
He
submitted
some
slides
an
hour
ahead
of
time,
which
is
plenty
of
time.
I'm
not
sure
why
he
was
worried,
so
we're
ready
for
those
so
basically
sort
of
where
we
stand
and
brian
will
kind
of
speak
to
this
as
well.
B
If
he
actually
actually
showed
up
for
the
meeting,
is
things
are
moving
along,
but
they're
kind
of
slow?
We
understand
that
we're
considering
kind
of
maybe
going
dark
for
a
little
bit
while
implementations
go
on.
It's
like
we're,
not
sort
of
chasing
people
away,
but
we
want
to
see
some
stuff
get
built
and
some
flight
with.
We
like
the
work
going
on
in
unilateral
probing,
and
we
just
want
to
see
where
things
are
going
and
we're
hoping
there's
some.
You
know
folks,
some
implanters
sort
of
show
up
and
say
hell.
B
C
A
I
So
I'm
going
to
talk
to
you
all
about
the
unilateral
probing
document,
which
basically
is
about
probing
for
encrypted
transport
between
the
recursive
resolver
and
the
authoritative
dns
server,
the
basic
idea
behind
it,
while
this
draft
well,
this
slides
come
up.
I
Just
as
a
recap
to
remind
you
is
that
the
idea
here
is
people
have
some
concerns
about
how
how
well
recursive
resolvers
are
going
to
be
able
to
make
encrypted
connections
to
authoritative
servers,
and
we
wanted
to
just
get
more
experience
without
having
to
answer
the
hard
questions
of
like
how
do
we
authenticate
the
server
or
when
should
we
hard
fail?
Or
what
do
we
do?
I
If
there
are
problems
we
just
wanted
to
try
doing
it,
and
so
the
unilateral
probing
document
is
relatively
straightforward
and
that
it
basically
says
the
recursive
resolver
should
just
try
and
the
authoritative
server
should
offer
encrypted
transport
and
the
recursive
resolver
should
try
encrypted
transport,
and
it
gives
some
guidance
about
how
to
do
that
in
a
way
that
minimizes
excess
resource
consumption
that
reduces
the
amount
of
clear
text
but
makes
no
real
guarantees.
Certainly
no
guarantees
against
an
active
attacker
on
the
network.
I
I
I
don't
want
to
interrupt
this.
The
slides
issue
here,
but
the
the
baseline
for
this
is,
is
really
not
it's
really
not
that
hard.
It's
very
similar
in
some
sense
to
happy
eyeballs,
which
we
use
to
try
to
get
ipv4
and
ipv6.
I
So
the
idea
is
this
is
a
baseline
that
hopefully
can
be
then
merged
with
some
ability
to
do
authenticated
and
potentially
strict
encrypted
transport
between
on
that
leg.
When
that
becomes
available,
so
you've
got
slides
there.
I
All
right
you
hacked
around
it.
I
appreciate
that
I
did
the
recap
there
yep
so
yeah.
So
the
primary
goal
of
this
draft,
though,
is
that
there
should
be
no
need
for
explicit
coordination
between
the
authoritative
resolver
and
the
recurser
that,
basically,
this
is
really
just
about.
How
do
you
just
try
in
a
way
that
doesn't
make
everybody
on
the
network?
Sad?
I
The
main
changes
in
the
latest
version,
aside
from
adding
paul
to
the
authors
list,
as
we
took
some
discussion
about,
maybe
what
the
future
steps
might
be
and
move
that
to
an
appendix
to
not
distract
from
the
main
point
did
some
clarification
about
state
transitions
when
sending
over
encrypted
transport.
The
definition
of
the
state
transitions
was
slightly
wrong.
It
was
actually
a
little
more
strict
than
it
needed
to
be
with
this
kind
of
happy
eyeballs
approach.
I
We
actually
want
you
to,
even
if
you
got
an
answer
back
from
cleartext
we'd
like
you
to
keep
trying
with
your
encrypted
connection,
because
maybe
you'll
learn
something
on
that.
Try
for
the
next
time
you
have
to
talk
to
that
resolver
and
somebody
I
think
sarah
dickinson,
I
think,
noticed
that
the
the
way
we
were
looking
at
how
long
we
should
persist
was
measuring
from
the
first
connection
to
the
server,
as
opposed
to
the
last
connection,
the
most
recent
connection
to
the
server.
I
I
It's
easy
to
get
these
things
subtly
wrong,
and
people
who
have
experience
implementing
can
probably
identify
places
where,
where
we
got
it
wrong
better
than
somebody
who's
just
skimming
the
draft,
so
we
definitely
hope
to
see
more
implementers
on
that
note
next
slide,
please
powerdns
recurser
has
announced
that
they
are
basically
implementing
this
approach
for
adot
that
is
authoritative,
dns
over
tls.
I
The
draft
itself
is
agnostic
about
a
dot
versus
adoq
that
is
authoritative,
dns
over
quick,
so
some
folks
might
be
interested
in
trying
to
do
adoq
as
well.
We
encourage
implementers
to
try
that.
I
will
note
that
after
I
wrote
these
slides,
but
before
I
stepped
up
here,
I
noticed
that
a.n.s.facebook.com
is
answering
on
tls
on
port
853.
I
It
may
or
may
not
be
authenticatable
if
you're
using
a
standard,
tls
stack,
but
again,
that's
fine
for
the
purposes
of
this
draft.
So
if
you're
running
an
authoritative,
a
recurser-
and
you
enable
this,
you
might
be
able
to
encrypt
all
the
connections
that
go
to
facebook,
so
that
might
be
something
interesting
to
be
able
to
note
we're
looking
for
other
implementers
to
stick
their
head
up
and
say:
hey,
I
tried
to
do
this.
It
worked
for
me.
It
didn't
work.
For
me
this
is
what
we
ran
into.
I
A
G
I
Great
I'd
love
to
hear
feedback
from
that
and
again,
the
strap
is
not
claiming
to
be
perfect
and
feedback
from
the
implementers
who
have
experience
are
welcome.
Obviously,
coming
from
google
public
dns,
you
have
a
different
scale
of
implementation
than
than
somebody
who
might
be
implementing
it.
On
a
you
know,
an
office
network
or
something
victor.
D
Victor
de
carnegie,
google,
public
dns,
I'm
looking
for
operators
of
authoritative
servers
who
will
share
preferences,
particularly
around
their
tls
tuning.
Are
they
looking
to
do
tls
resumption?
Do
they
strongly
want
it?
Do
they
support
it?
Any
feedback
on
you
know
the
experience
with
timers
idle
and
the
like.
I
want
to
hear
about
tuning.
D
Please
get
in
touch,
especially
if
you
have
dns
servers
behind
load
balancers.
I
want
to
hear
how
that
works
with
a
dot
all
that
sort
of
stuff.
Thank
you.
I
J
Paul
hoffman
co-author
for
the
people
in
the
room
who
haven't
read
it
or
haven't
been
reading
it
carefully.
The
last
discussion
we
just
had
is
actually
not
that
relevant.
That
is
the
draft
says
if
you're
a
client
go
ahead
and
try
and
do
these
things
we
believe
and
if
we're
wrong.
We
certainly
want
to
hear
if
you
misimplement
the
client
side
of
the
draft
you're
not
going
to
hurt
anything,
you
may
have
some
extra
delays
and
such
but
you're
not
going
to
be
hurting
any
authoritative
servers
if
we're
wrong.
J
I
Yep
and
as
a
reminder,
the
document
also
offers
guidance
to
authoritative
server
operators
as
well,
in
terms
of
how
you
probably
want
to
configure
your
systems,
and
so,
if
you're,
implementing
this
on
the
authoritative
side,
and
you
think
that
that
guidance
is
lacking
or
insufficient
or
wrong.
Or
you
think
it's
good
we'd
love
to
hear
from
you.
I
So
yeah
next
slide
thanks
outstanding
questions
in
the
draft
there's
a
handful
of
fix
me's
that
are
related
to
error
handling,
mostly
on
the
guidance
for
the
recursive
resolver
side.
Again,
I
don't
think
that
these
need
to
be
perfect,
but
it
would
be
good
to
give
to
some
general
results
about
the
different
kinds
of
errors
you
might
be
able
to
see
if
you've
got
some
strong
opinions
about
how
you
want
that
to
see.
I
Want
that
to
happen
on
a
on
this,
opportunistic
unilateral
approach
be
good
to
receive
some
text
on
that.
There
is
a
question
about
whether
the
document
should
be
standards
track
as
opposed
to
experimental
or
informational,
or
something
like
that.
I
I
think
we
are
leaning
towards
standards
track,
but
we
good
to
hear
from
the
working
group
on
that
and
there's
some
open
questions
about
whether
we
want
more
explicit,
like
visualization,
of
the
types
of
steps
that
we're
expecting
the
resolver
the
recursive
resolver,
to
take
in
terms
of
how
it
keeps
track
of
whether
it
thinks
it's
got
a
good
connection
or
a
history
of
good
connections
to
a
given,
authoritative.
I
So
if
folks
are
good
at
doing
you
know
flow
control,
diagrams
or
things
and
think
they
can
do
it
draw
draw
some
nice
pictures.
That's
always
a
welcome
thing
for
implementers
who
to
look
at
so
come
talk
to
me.
I've
got
some
ideas
about
how
we
could
draw
those
pictures,
but
you
might
have
better
ones,
so
anybody
who's
interested
in
doing
that
kind
of
stuff
too
happy
to
have
contributors
next
yeah.
So
this
is
basically
what
I
just
told
you.
I
I
I
You
know
we're
hoping
to
have
a
version
of
this
with
all
the
fixmes
cleaned
up
before
the
next
ietf,
and
maybe
we
will
get
maybe
we'll
get
an
opportunity
to
ask
for
a
working
group.
Last
call,
then,
but
getting
more
feedback
from
implementers
in
the
meantime
would
definitely
be
preferable.
I
I
think
that's
what
I've
got
if
folks
have
questions
about
the
draft
or
or
or
complaints
or
gripes
or
whatever.
I
think
please
come
up
to
the
mic
line.
B
Queue
looks
empty
thanks
for
the
comments
we
have
and
thanks
for
the
work
you
guys
have,
you
all
have
been
doing
on
it.
So
please
carry
on
so
all
right.
Okay,.
B
And
that
was
it
on
our
business.
I
think
brian
finally
showed
up
for
the
meeting,
which
is
just
in
time,
so
we're
actually,
unless
you
know,
mike's
open.
If
people
have
something
to
say,
please
speak
up,
you
know,
except
for
you,
mr
farrell.
Everybody
else
is
welcome
to
no
no
thank
you
all,
and
otherwise
we're
going
to
call
this
an
early
meeting.
I
believe
which
we
kind
of
figured
it
would
be
a
short
reading.
So
thank
you
all
for
attending.