►
From YouTube: ADD WG Interim Meeting, 2021-01-27
Description
ADD WG Interim Meeting, 2021-01-27
A
B
B
We're
up
to
23.
so,
while
we're
waiting
does
anybody
want
to
put
their
hand
up
virtually
to
help
us
with
the
scribing?
We
need
somebody
from
that
room
to
act
as
a
jabber
scribe
to
bring
forward
any
important
issues
from
there,
and
we
also
need
one
or
more
volunteers
to
help
us
with
the
note-taking
nature
pad.
B
B
B
D
D
B
They
do
they,
I
don't.
I
don't
think
we
have
access
to
the
the
attendance
things
and
people
can
put
whatever
they
want
to
put
in
for
webex
when
they,
when
they
join.
It's
not
like
restricted
to.
Like
you
know,
you
put
your
real
name
in,
so
people
should
be
doing
the
blue
sheets
inside
the
ether
pad.
D
E
B
B
We
had
some
great
conversations
during
them
and
actually,
I
think,
produced
a
lot
of
momentum
going
forward.
We
talked
about
authenticated
unauthenticated
networks.
In
the
past
we
talked
about
this
concept
of
equivalency
and
and
how
we
sort
of
feel
about.
You
know
where
things
fit
and
and
that
approach-
and
I
think
this
really
moved
the
group
very
effectively
along.
So
thank
you
for
your
participation
of
the
interns
and
thank
you
for
coming
today.
B
D
B
Please
be
aware,
this
is
an
itf
official
meeting,
so
notewell
does
apply.
So
please
read
it
and
be
aware
of
its
provisions
in
terms
of
tips
for
the
meeting.
We
will
be
using
the
webex
chat
to
manage
the
queue.
So
please,
when
we
do
open
the
mic
line,
go
there
at
a
plus
q
to
add
yourself.
Do
a
minus
q
to
take
yourself
out
david
lawrence
will
be
managing
the
queue
and
and
the
those
sessions,
and
I
will
be
managing
the
screens
and
the
presentations.
B
B
D
B
What
else?
Oh
sorry,
getting
back
to
dark?
We
have
three
presentations,
so
the
first
one
will
be
from
a
design
group
that
the
chairs
helped
kick
off.
That
worked
with
the
draft
box
requirements
and
has
produced
a
new,
quite
substantial
revision
to
draft
box
requirements
and-
and
that
was
released
a
couple
days
ago
to
the
group
we'll
have
a
15-minute
overview
from
that
group
and
and
the
output
from
that
followed
by.
B
We
have
a
btw
home
12,
that's
going
to
be
presented
and
draft
polygear,
and
my
apologies
on
both
those
on
the
updates
on
the
slides.
I
failed
to
put
in
the
dash
adv
that
they
are
part
of
our
group
but
anyways
and
on
the
on
the
last
bit
on
the
draft
poly
dear
the
links
and
everything
you
have
right
now.
B
B
F
D
G
B
F
F
That
that
debate,
which
I'll
come
on
to-
but
we
also
we
also
looked
at
what
else
do
we
have
in
the
space?
We've
got
deer
we've,
which
says
yeah.
That
gives
you
a
mechanism
to
do
discovery
from
a
resolver
and
we've
got
the
add
home
draft.
That
tells
you
how
you
can
do
discovery
in
it
from
a
network,
so
we've
as
well
as
simple
designation,
which
is
what
my
new
version
is
talking
about.
F
We've
also
got
some
some
ideas
about
going
beyond
that.
So
if
we
go
on
to
the
next
slide,
so
the
main
changes
compared
to
one
of
the
draft
is
that,
because
we
had
a
lot
of
debate
about
what
was
meant
by
equivalence
and
that's
for
good
reasons,
that
networks
and
resolves
and
users
they're
all
diverse
and
they
have
different
needs.
So
this
draft
doesn't
use
that
word
equivalence
it
just
it
just
talks
about.
How
do
you
designate
a
resolver
and
designation?
F
D
H
H
So
that's
the
the
existing
draft.
We
also
in
this
presentation
have
three
sketches
of
other
scenarios
that
go
beyond
this
to
more
advanced
use
cases
you
can
think
of
each
of
these
sections,
like
a
sketch
of
a
requirements,
draft
that
analyzes
some
potential
collection
of
use
cases,
so
the
first
one
presented
by
tiru
will
be
about
configuration
where
the
user
has
identified,
authenticated
and
explicitly
authorized
a
particular
network
to
control
configuration.
H
H
Next
slide
just
to
be
clear,
we're
not
proposing
that
the
working
group
has
to
solve
all
of
these
scenarios.
These
are
offerings
to
the
working
group
to
see
what
people
are
interested
in
trying
to
solve
and
we're
not
trying
to
take
control
away
from
the
client
here,
but
we
and
we're
not
trying
to
communicate
policy
instructions
to
the
client.
G
Hey
thanks
man
next
slide,
please
this.
This
section
is
specifically
with
regard
to
enterprise
networks,
where
the
endpoint,
typically
a
previous
device,
would
have
connected
to
the
enterprise
network
using
the
unique
credentials
that
is
provided
by
the
id
admin
and
in
those
cases,
these
use
cases
are
basically
talking
about
scenarios
where
you
have
an
unmanaged
poi
device
which
is
very
common.
G
And
how
do
you
provision
these
devices
to
use
the
enterprise,
doh
or
dod
server,
and
then
and
then
the
user
would
have
authorized
the
client
to
override
the
local
data
setting
on
these
networks
and
in
addition
to
be
where
it
is,
we
now
see
an
explosion
of
iot
devices
that
join
these
enterprise
networks,
and
many
of
these
devices
may
or
may
not
have
a
device
management
tools.
So
if
these
devices
both
void
and
iot
devices
can
be
provisioned
with
the
enterprise
encrypted
dns
service
next
slide.
I
G
Yeah,
so
the
standard
discovery
mechanisms
that
would
work
for
boid
and
iot
devices
either
it
could
be
based
on
the
existing
mechanisms
that
the
working
group
has
already
come
up
with,
or
is
there
any
better
way,
because
there
is
an
explicit
preconfiguration
and
trust
between
the
endpoints
and
the
network?
In
this
case,
the
one
of
the
most
important
one
that
we've
been
discussing
was.
G
The
local
names
basically
similar
to
splitters
and
dns,
where
the
endpoint
would
want
to
know
what
are
the
internal
domain
names
that
the
enterprise
dns
server
would
resolve.
This
is
very
similar
to
what
we
see
in
high
quality
or
spread
vpn
scenarios,
where
the
vpn
client
would
learn
the
internal
domain
names
and
use
the
internal
dns
server
to
resolve
only
those
domain
names.
G
So
that
way,
the
endpoint
has
a
flexibility
to
either
pick
the
enterprise
dns
server
to
resolve
all
the
domains
or
just
use
the
enterprise
dns
server
to
only
resolve
the
local
domains
for
which
the
enterprise
dns
server
is
acting.
As
the
32
server
we've
seen
several
working
groups
at
iitf,
I
mean,
if
you,
if
we
decide
to
have
any
new
standardized
discovery
mechanisms
beyond
network
discovery
or
dns
space
discovery
that
the
working
group
has
already
adapted.
G
There
seems
to
be
some
work
happening,
at
least
in
an
email
working
group
with
regard
to
bootstrapping
remote
security
infrastructure,
which
talks
about
bootstrapping
iot
devices
with
network
configuration
both
for
authentication
and
other
configuration
purposes.
That's
a
secure
mechanism,
unlike
the
mechanisms
that
the
working
group
has
discussed.
Iq2
has
already
proposed
various
extensions
to
learn
the
dns
server
information
and
other
local
network
configuration
using
eye
creative
extension.
So
that's
one
extension
that
could
be
easily
done,
which
would
leverage
the
existing
like
video
mechanism
without
having
to
invent
a
new,
secure
discovery
mechanism.
G
Next
slide,
please
what
we've
been
discussing
is
hey.
What
kind
of
devices
would
need
this,
and
what
we
have
identified
is
that
if
you
have
it
managed
devices
and
iot
devices
with
the
device
management
tool,
it's
pretty
easy
for
this
device
management
tool
to
configure
and
decide
whether
the
item
managed
device
or
iot
device
needs
to
send
all
the
dns
queries
to
the
enterprise,
dns
server
or
just
to
split
horizon
dns
and
provide
the
internal
domain
name.
G
So
the
goal
is
not
to
target
these
kind
of
devices
which
are
managed
by
any
device
management
tool,
and
even
bod
devices
managed
by
mdm
can
be
provisioned.
With
that,
I
will
also
see
byd
devices
typically
deployed
in
enterprise
networks,
with
a
configuration
profile.
The
configuration
profile
would
probably
today
provides
the
endpoint
with
a
client
certificate
for
8.2.1
authentication.
G
It
also
provides
various
configuration
information
related
related
to
the
enterprise
network,
configuration
it's
a
secure
configuration
that
happens
today
and
even
that
could
be
extended
to
provide
the
information
that
we
are
discussing.
So
these
type
of
devices
with
mdm
or
configuration
profiles
are
beyond
the
scope,
so
the
scope
is
pretty
much
restricted
to
unmanaged
byd
devices
without
any
mdm
next
slide.
Please.
J
J
J
There
are
several
cases
today
where
content
providers
will
actually
allow
isps
to
have
local
caches,
where
an
isp
resolver
may
know
that
it
can
provide
an
optimized
results
to
a
query
that
the
client
will
probably
not
get
from
other
resolvers
next
slide,
please
defining
the
resolver's
identity
in
a
more
useful
way.
One
example
may
be
that
the
resolver
can
provide
human
friendly
descriptions
that
can
power
ui
to
make
dns
ui
more
user
friendly.
J
Another
example
is
to
provide
human,
legible
documentation
things
like
debugging
or
other
documentation
that
may
have
to
be
found
via
web
searches.
Today.
The
idea
behind
this
use
case,
specific
that
we
should
specifically
call
out
is
that
these
descriptions
should
not
be
used
by
the
protocol
automatically
to
make
decisions.
This
isn't
about
providing
any
verifiable
trust.
It's
about
optional
interaction,
so
this
would
not
be,
for
example,
a
good
way
to
say
these
are
the
terms
of
service
a
user
must
agree
to.
J
J
The
other
category
would
be
defining
protocol
support
beyond
what's
needed
to
connect.
One
example
is
dns
extended
errors.
Are
there
specific
codes
that
the
server
would
like
to
give
the
client
a
heads
up?
It
should
expect
with
frequency,
but
a
more
common
example
would
be
access
controlled
resolvers.
If
the
resolver
requires
clients
authentication
to
log
in
as
it
were,
it
should
be
able
to
describe
what
is
required
to
do
that
and
how
to
signal
that
the
authentication
has
failed
and
how
to
try
again
next
slide,
please
I'll
hand.
A
So
we're
thinking
here
besides,
the
three
actors
in
this
there'll
be
some
sort
of
publisher
that
creates
and
maintains
some
list
of
distinct
resolvers
and
the
client,
obviously,
which
is
going
to
retrieve
that
list
somehow
saves
me
hand
waving
frantically,
and
then
there
are
the
resolvers
themselves
that
are
in
that
list
of
sets
of
lists
depending
on
who's,
actually
providing
it
now
as
tommy.
Sorry
as
ben
pointed
out
earlier,
and
the
word
directories
is
perhaps
a
little
bit
loaded
in
context.
Really.
A
A
A
We've
also
got
the
scenario
of
a
software
vendor
who
we
may
be
maintaining
a
list
of
trusted
resolvers
for
some
definition
of
trust
and
needs
to
update
that
list
without
requiring
an
update
of
the
software
itself.
So
the
software
scenario
that
might
apply
to
something
similar
to
what
mozilla
is
doing
with
its
tir
tr
service
in
firefox.
A
The
resolver
will
describe
its
own
self-description
and
it's
being
entered
into
that
list
of
the
resolver's
capabilities
and
the
protocols
are
going
to
be
used
for
doing
that.
Self
description,
so
on
are
the
ones
that
top
the
interior
mentioned
before
in
the
in
the
presentation
will
potentially
have
the
ability
for
the
publisher
to
offer
more
repeatability
so
that
whenever
the
list
is
published,
the
end
client
is
a
reasonable
satisfaction
of
knowing
that
the
information
that's
being
provided
by
the
publisher
can
be
identified,
whether
it
be
verified
by
danasec.
A
There's
obviously,
potentially
an
on-screen
interactive
menu
in
case
of
user
wants
to
know
the
pictures
over
of
choice
that
you
want
next
slide.
Please
things,
we've
expressly
looked
decided
not
to
make
part
of
the
requirements
is
defending
against
malicious
and
ineq
behavior,
either
by
the
publisher
or
or
the
resolver
module
this
information.
Potentially
you
want
the
putability
of
the
data
you
get
from
the
publisher.
A
We're
not
going
to
consider
cases
where
there's
going
to
be
extremely
long
lists
of
resolvers
remembered
here
is
up
for
grabs,
wrote
a
thousand
seems
ridiculous.
Maybe
I
would
have
thought
the
low
tens
would
be
a
reasonably
long
enough
list,
but
again,
we've
not
made
any
final
decisions
about
that,
and
we've
been
working
with.
Have
some
suggestions
on
that.
B
B
G
Yeah,
so
what
we
have
done
in
the
last
couple
of
revisions
is
to
update
the
draft
to
address
several
comments
that
we
received
from
the
working
group.
I
think
we
have
presented
this
draft
several
times
so
just
probably
quickly
walk
over
the
critical
pieces
that
this
draft
proposes
dhcpr
extensions
to
provide
the
encrypted
dns
server
that
the
network
offers
and
it
returns
both
the
authenticated
domain
name
and
a
list
of
ip
addresses
where
the
interpreting
server
resides.
G
It
could
return
one
or
more
encrypted
dns
protocols
that
the
dns
server
supports
and
these
servers
may
be
hosted
on
the
same
or
different
ip
addresses
than
the
clear
text.
Dns
server
and
the
dns
extensor
also
supports
alternate
port
numbers,
which
dot
and
doq
do
talk
about
and
does
typically
runs
on
443.
So
it
also
discusses
a
list
of
ip
addresses
that
would
be
written
and
they
are
ordered,
and
it
has
some
optimizations
with
regard
to
reducing
the
dhcp
response
size,
especially
to
handle
fragmentation.
G
K
G
G
G
Okay,
so
one
of
the
questions
that
we
have
for
the
working
group
is
after
the
client
learns
the
domain
name.
What
should
you
do
with
regard
to
learning
the
uri
templates
that
the
do
it
server
supports?
So
we
have
two
options
in
the
draft
currently
either
we
rely
on
the
rear
mechanism
to
use
dns
to
learn
the
uri
templates
or
use
an
dhcpr,
a
message
to
learn
the
uri
templates.
K
G
K
K
L
Thank
you
so
I'll
be
presenting
just
the
status
of
the
open
issues
on
deer,
which
is
now
going
to
be
adopted
and
the
current
title
and
the
acronym
is
for
the
descript
discovery
of
equivalent
encrypted
resolvers,
given
the
discussion
around
equivalency,
that
will
likely
change,
but
the
content
of
the
protocol
remains
the
same
next
slide.
Please.
L
So
I'm
just
trying
to
summarize
kind
of
the
different
categories
of
issues
and
comments
we
had
during
the
adoption
call
first
kind
of
the
obvious
bike
shed
is
the
name
and
terminology
it
currently
refers
to
equivalent
resolvers.
That
was
mainly
just
because
that
was
what
the
requirements
draft
was
specifying.
Then,
based
on
our
discussion,
we
want
to
change
that.
L
I
think
talking
about
discovery
of
designated
resolvers
would
make
a
lot
of
sense.
It
doesn't
really
fundamentally
change
the
mechanism,
but
I
think,
from
the
author's
perspective
we'd
like
to
have
a
new
name
acronym,
for
when
we
upload
a
working
group.
Draft
one
option
is
to
switch
it
from
deer
over
to
dance
dance
revolution.
I
mean
discovery
of
designated
resolvers
if
other
people
have
opinions
or
bike
sheds.
Just
let
us
know
next
slide.
L
This
allows
clients
to
avoid
hard
coding,
the
path
that
they
expect.
The
dos
server
to
be
running
on.
It
also
allows
them
to
do
a
bit
more
of
a
normal
certificate
evaluation
for
a
name
and
have
an
authority
request
for
a
specific
name
rather
than
being
trying
to
infer
or
guess
what
that
name
would
be.
So
we
think
it
still
is
a
very
important
piece.
L
L
There
are
also
a
couple
other
details
for
opportunistic
mode,
and
particularly
there
is
a
pr
from
ben
schwartz
that
proposes
a
way
to
upgrade
to
private.
I
p
address
an
ultimate
private
ip
address,
so
currently
the
draft
allows
you
to
have
a
different
ip
address
for
your
resolver.
As
long
as
these,
the
original
ip
addresses
are
kind
of
public
ip
addresses
for
which
you
can
have
a
certificate.
L
We
want
to
do
a
couple
of
updates
around
the
text
for
the
use
of
the
service
binding
records.
There's
some
text
there
for
address
hints
and
how
they're
used
that
make
it
sound
like
you
can
only
use
the
addressing
to
not
do
any
other
queries.
This
is
not
technically
correct,
they're
more
of
an
optimization,
so
we
need
to
update
that
also
on
the
mailing
list.
I
think
stephen
farrell
had
some
comments,
just
kind
of
asking
about
the
overall
status
of
client
support
for
svcb.
L
I
think
we
believe
that
it
is
an
appropriate
thing
to
use
from
the
measurements
we've
done
and
you
know,
speaking
for
myself,
we've
been
running
queries
for
svcb
on
ios
and
macos
devices
for
six
months
now
on
the
public
releases,
and
things
have
been
going
well
there.
So
I
think
it
is
appropriate,
but
that
is
of
course
something
that
we
can
continue
to
discuss
as
a
working
group.
L
And
then,
finally,
there
have,
of
course
been
discussions
around
the
specific
certificate
requirements
around
the
use
of
ip
addresses
and
certificates
for
the
public
ipaddress
upgrades.
I
I
think
you
know.
We
believe
that
this
is
an
appropriate
mechanism
for
the
addresses
that
are
eligible
to
have
certificates,
but
I
think
there
does
need
to
be
some
clarification
around
the
requirements
as
far
as
having
the
addresses
and
names
in
the
certificates.
L
B
B
B
Hello,
everybody
and
welcome
back
it's
44
past
the
hour
or
a
half
hour
later
in
newfoundland.
If
you're
from
canada,
that's
an
old
joke,
they
used
to
put
that
on
the
tv
stations
whenever
they
tell
you
what
the
time
the
tv
show
was
on,
they
always
would
indicate
there
was
at
such
a
time
and
a
half
hour
later
in
newfoundland.
So
you
sort
of
got
used
to
just
hearing
that
as
a
kid.
B
D
B
D
M
Thanks
everyone
for
presenting,
I
have
to
admit
I
sort
of
watched
that
first
presentation
with
a
feeling
of
dread
about
the
level
of
scope
creep.
I
see
here
the
it
seemed
like
we
were
converging
on
a
relatively
narrow
scope,
initially
the
scope
largely
built
by
deer
and
does
understand
by
btw
sorry
about
vw
home.
It
seems
to
be.
M
We
should
like
stick
to
that
scope,
which
is
to
say,
oh,
how,
like
employees,
to
learn
the
set
of
resolvers
which,
like
their
network,
things
they
might
want
to
use
it
seems
to
be
deer.
We
already
agreed
to
accept
deer,
which
clearly,
like
fits
into
that
in
that
category,
I'm
open
to
being
persuaded
that
that
it'll
be
useful
to
also
standardize
the
dcp
dhcpra
mechanism.
M
Sorry
or
a
mechanism
as
a
a
as
bw
home
suggests.
I
think
we
should
stop
there
and
since
at
the
mic,
I
it
seems
like
it'd,
be
very
attractive,
given
that
dpw
home
and
deer,
more
or
less
morally
standardizing
delivering
the
same
information
via
different
channels.
The
right
thing
to
do
here
we
try
to
center.
The
data
format
have
to
look
for
the
same
thing.
I
So
on
the
draft
specifically,
I
mean
there
was
a
question
on
the
ui
scheme
for
a
bdw
home
and
I
think
we
should
pretty
much
keep
that
to
dhcp
ra,
because
there
is
in
the
ecosystem,
stuff,
like
ra
or
or
dsgp
guard,
that
kind
of
gives
some
security
on
the
lower
network
levels.
There
is
no
such
thing
as
dns,
which
is
the
is
the
automatic
upgrade
now
there
is
the
need
for
an
automatic
upgrade
with
with
the
ears,
so
I
support
adoption
of
both
drafts,
but
into
in
the
kind
of
ra
dhcp
scheme.
I
L
Yes,
that
is
correct,
just
to
jump
in,
I
was
referring
to
svcb
records
in
the
the
the
general
draft
sense,
including
both
those
in
https
records,
you're
correct
that
they
are
https
records,
but
actually
we're
also
currently
relying
on
a
draft
from
ben
schwartz
and
he's
in
the
queue
later.
So
he
can
comment
about
that
using
kind
of
the
dns
domain
of
that
specifically.
B
Either
wearing
no
hat
other
than
participant,
I
want
to
make
a
comment
of
the
on
the
requirements
draft
that
jim
presented
on
jim
reed,
and
this
notion
of,
like
you
know
that
there's
some
form
of
a
thing
you
get
back
at
a
url.
I
kind
of
like
that
and
ultimately,
if
there's
some
form
of
maybe
like
a
assigned
json
document
as
part
of
the
concept
for
people
when
they're
doing
design
work
here,
that
might
be
useful.
They
will
actually
have
a
means
to
you
know
I
like
that
ability
to
display
it.
H
Fed
schwartz
so
to
to
ecker
and
ralph's
point
about
scope
here.
What
I'll
say
is,
I
think,
the
I
think
the
working
group
has
its
priorities
straight.
I
think
that
the
the
current
work
that
the
working
group
is
clearly
the
the
highest
priority
and
best
motivated
and
what
we
were
trying
to
do
with
this
with
this
presentation,
is
to
sort
of
lay
out
what
what
is
possible
beyond
our
current
scope.
I
do
think
that
we're
looking
at
essentially
diminishing
returns,
the
the
subsequent
things
that
we've
proposed.
L
L
A
couple
other
minor
points,
as
I
noted
we
are
in
deer,
currently
relying
on
the
use
of
svcb,
that's
defined
in
a
draft
that
ben
schwartz
has
and
that
one,
I
believe,
is
not
currently
adopted
anywhere.
So
we
should
talk
about
you
know
what
is
the
path
for
that
document?
Do
we
want
that
to
be
folded
in
to
what
we've
already
adopted?
Should
it
be
a
separate
document
that's
adopted
here
or
in
another
dance
working
group.
B
If
I
can
jump
in
with
my
chair
hat
on
there,
tommy
that's
a
good
question.
The
we've
been
talking,
the
chairs
of
add,
have
been
talking
with
the
chairs
of
the
other
dns
groups
about
that,
and
so
right
now
we're
waiting
for
the
the
progress
on
svcb
itself
to
progress
along
to
where
it
gets.
Actually,
I
guess
my
understanding
is
that
it's
it's
either
in
or
approaching.
L
That's
great
that's
great
to
know,
and
then
the
last
comment
I'll
make
is
to
ecker's
original
point
of
kind
of
the
scope.
I
I
definitely
agree
that
we
don't
want
scope
creep
and
I
think
the
set
of
things
we
have
now
is
something
very
concrete
that
the
working
group
should
work
on
and
ship
first
and
I
I
would
encourage
people
to
try
to
view
maybe
some
of
those
other
use
cases
as
things
that
can
be
written
as
extensions
to
the
mechanisms
we're
talking
about
here.
C
I
think
that's
that's
helpful,
so
I
think
I
think
it's
appropriate
to
move
ahead
with
the
user
requirements
document
and
for
what
it's
worth.
I
think
there
are
some
good
things
in
there
and
then
secondly,
on
the
deer
draft
on
the.
If,
if
I
recall
correctly
from
the
discussion
on
the
list,
the
point
about
certificates
was
to
avoid
specifying
things
which
encouraged
yet
more
centralization.
C
Activity,
I
think
that
if
I
record
an
apologies,
have
gotten
this
slightly
wrong.
That
was
very
simplistically
the
concern
the
the
stephen
raised.
I
thought
it
was
a
good
concern
and
to
make
sure
that
we
conscious
of
the
word
that
we
don't
make
the
current
sort
of
drift
towards
centralization
even
worse,
even
if
doing
we've
done
so
accidentally.
K
K
K
I
have
no
idea
how
to
do
that,
but
that's
something
I
think
we
should
discuss.
The
other
thing
is,
but
it's
maybe
for
the
chairs
or
I'd
like,
maybe
to
remind
where
the
discussion
is
happening.
So
is
it
on
the
github
or
the
mailing
list.
So
when,
when
the
the
github
repo
is
started
with
the
new
update
of
the
draft
or
the
working
group
document,
I
think
it's
a
something
that
should
be
maybe
regularly
reminded
then
yeah
svcb.
K
K
Similarly,
the
user
requirements
is
something
I
think
is
important
for
the
working
group,
and
here
it
should
be
also
reminded
maybe
to
the
working
group.
So
we
have
everyone
participating
to
the
discussion
where
the
discussion
is
happening
so
github
mailing
list
and
so
on
so
yeah.
So
that's
all
for
me
now.
F
Hello,
can
you
hear
me?
Okay,
yes,
cool.
Yes,
I
wanted
to
respond
to
ecker's
point
that
this
is
too
much
scope,
so
there
are
two
answers
to
that.
First
of
all
is,
of
course,
the
in
the
charter
of
the
working
group
yeah.
The
second
item
is
communication
of
resolver
information
to
use
in
selection
decisions,
but
my
other
answer
is
we'll
consider
what
happens
if
we
stop
work
after
we
after
we
define
how
you
designate
a
resolver,
you
know
what
the
client's
gonna
do.
Are
you
expecting
that
they
always
follow
the
designation?
F
N
Thank
you.
Thank
you
very
much.
First
of
all,
I
just
want
to
reiterate
some
thanks
to
ecker,
actually
for
his
honest
explanation
regarding
the
bindings
for
why
you
have
the
ip
address
in
a
certificate
my
and
that
that
really
helped
me
advance.
I
think
that's
probably
a
good
add
to
the
to
the
draft
his
explanation.
L
I
think
we
are
creating
mechanisms
here
to
do
discovery,
but
leaving
it
at
that
and
letting
the
individual
client
implementations
decide
what
is
the
right
trust
model
for
their
users
and
that
interaction
is
something
that
should
be
left
to
those
and
not
something
that
they're
working
worker
tries
to
dictate,
and
we
are
best
to
stay
clear
away
from
that,
and
thank
you
elliot
for
bringing
up
the
scalability
points.
I
think
that's
something
that
we
should
definitely
continue
to
discuss
and
have
issues
about.
L
M
Yeah,
sorry,
you
couldn't
find
me
earlier.
I
I
managed
to
mute
and
couldn't
find
the
the
window
to
understand.
So
I
mean
I
think,
like
first
I
took
a
look
at
the
charter
again,
there's
chris
probst,
probably
too.
I
find
this
second
point
to
be
extremely
badly
written,
so
I
don't
really
know
what
it
means,
but
it
seems,
like
you
know,
communication
of
dns
or
information
to
clients
for
use
and
selection
decisions.
M
That
seems
like
it
quite
possibly
could
be
the
same
as
the
first
point,
which
is
allowing
you
to
discover
resolvers.
In
any
case,
as
far
as
I
can
tell,
deer
does
define
such
a
mechanism,
which
is
basically
you've,
got
a
sensible
thing
which
will
let
you
say
anything
you
wanted
in
that,
so
the
relevant
question
would
be
what
information
ought
to
be
communicated
and
that
ought
to
be
driven
by
what
information
clients
would
consume
to
the.
You
know,
to
the
specific
point
that
you
raised
about.
M
You
know
what
information
you
know:
multiple
trr
programs
stuff
like
that.
You
know.
I
think
we
do
have
a
worked
example
of
like
how
this
works
in
other
fields,
for
instance
in
in
ca
root
programs
where
there's
a
relatively
small
number
of
root
programs
and
they
publish
their
roots,
and
then
consumers
figure
out
how
to
get
those
roots
and
adopt
them.
So
the
point
where
you're
thinking
what
you
have
is
a
centralized
evaluation
function
or
a
small
number
of
centralized
evaluation
functions.
M
I
don't
really
think
the
primary
problem
is
exactly
what
format
those
functions
ought
to
publish
their
their
evaluations
in
you
know,
it's
not
like
it's
very
difficult
when
you,
when
you
make
that
when
you
make
the
decision
I
want
to
use,
you
know
whatever
root
format,
trying
to
figure
out
like
how
to
parse
whatever
json
file
or
text
file
they
give.
You
is
not
really
your
main
problem
so
so
to
send
to
which
that
is
the
problem.
I
don't
think
we
need
to
do
anything
since.
M
What's
the
problem
is
having
a
bunch
of
information
with
resolvers,
as
I
say,
it
seems
to
me,
deer
can
easily
be
sent
to
do
that
and
then
we're
interesting,
interesting
questions
of
what
that
information
ought
to
be,
and
so
far
I
haven't
heard
anybody
who
actually
provides
you
know
a
customer
of
the
resolver
say
what
information
they
want.
That
would
be
plausibly
indicated
in
the
in
the
deer
advertisements.
H
Hi,
so
I
want
to
address
a
specific
point.
What
I
heard
chris
talking
about
was
the
question
of
clients
applying
additional
layers
of
filtering
or
additional
conditions,
on
top
of
the
deer
upgrade
to
say
that
they're
going
to
get
an
instruc
an
upgrade
instruction
via
deer,
and
then
they
may
decide
that
they
don't
actually
want
to
execute
that
upgrade.
They
have
some
some
additional
opinions
on
the
client
about
which
upgrades
they're
actually
going
to
follow,
and
that's,
of
course,
perfectly
fine
within
the
context
of
deer.
There's.
H
F
All
right,
yes,
tommy.
I
certainly
wasn't
trying
to
say
that
we
in
this
working
group
should
be
aiming
to
tell
the
client
what
to
do.
Absolutely,
not
I'm
simply
saying
that
it's
helpful
to
standardize
information
that
we
can
deliver
to
the
client,
because
they
might
want
to
use
that
information
in
deciding
whether
to
use
the
designated
result.
F
You
know
that
any
kind
of
self-description
could
be
useful
and
likewise
the
directories
of
encrypted
resolvers
that
that
fulfill
some
attributes
that's
another
example
of
information
that
could
be
useful
to
the
client
that
it
might
want
to
make
use
of
in
its
selection
decision.
We're
not
saying
how
it
should
use
that
information.
C
L
Andrew
can
I
clarify
something
on
that
sure
yeah
I
was
referring
specifically
to
the
point
about
having
an
ip
address,
be
in
the
cert
that
that
particular
section
of
deer
applies
to
the
publicly
accessible.
There
are
other
sections
that
describe
what
to
do
for
those
other
use
cases
retirement,
so
it
does
cover
those,
but
it
just
doesn't
require
that
private
ip
addresses
go
inserts,
because
that
is
not
a
valid
approach.
K
While
we
still
have
no
drafts
being
adopted,
and
I
I
I
to
me-
it
looks
a
little
bit
counterproductive
because
it
means
that
if
your
use
case
is
not
been
in
the
current
their
specification,
then
it's
not
going
to
be
treated
by
the
working
group.
Or
am
I
I
mean
I'm.
I
know
I.
I
don't
understand
why
we
are
having
that
discussion
now.
K
B
Trigger
hat
daniel,
so
our
intention
is
not
that
deer
is
the
only
document
and
the
only
approach
that
is
going
to
be
adopted.
As
I
said
earlier
after
this
interim
session,
we're
also
going
to
be
putting
up
btw
home
for
working
group
adoption,
as
well
as
the
plan,
is
to
put
up
the
requirements
document
that
was
discussed
earlier
as
well
for
just
for
potential
work
group
adoption.
B
K
B
If
the
current
requirements
document
as
it
stands,
when
we
do
put
up
for
working
group
adoption,
if
that
does
come
up
it
does
get
adopted,
then
the
other
pathway
would
be
to
make
proposals
for
group
consensus
for
that
for
additional
material
to
be
added
to
that
requirements
document,
but
we're
still
open
we're
still
accepting
new
drafts.
This
is
not
an
end
of
day
right.
You
know
we're
not
we're
not
finishing
up
and
packing
up
ready
to
go
home
daniel.
M
My
question
when
that
comes
up
is
going
to
be
which
client
wishes
to
consume
the
the
the
indications
which
are
being
discussed,
because
what
I've
seen
throughout
the
support
process
has
been
an
enormous
number
of
proposals
for
sending
information
to
clients
that
someone
speculates
the
clients
might
use
and
that
the
people
who
people
want
to
generate
the
indications
which
the
clients
would
use.
But
I
don't
see
any
indication
the
clients
are
willing
to
use.
M
So
I
guess
I'd
be
much
more
interested
in
the
proposals
at
the
beginning
of
this
beginning
of
of
this
session.
If
I
heard
from
some
client
which
wanted
to
consume
them-
and
I
see
tommy's
in
the
cubes
or
perhaps
tell
me-
which
is
to
that
person-
but
that
seems
to
be
that
seems
to
be
a
threshold
requirement
for
like
and
you
save
all
that
type.
G
K
K
G
J
Thank
you
so
to
eckers
point
and
others.
The
the
working
group
should
most
definitely
not
be
working
on
topics
that
either
don't
have
a
strong
chance
of
adoption
or
that
don't
address
a
common
need.
I
think
the
point
in
the
the
first
presentation
we
built
today
was
to
call
out
some
specific
use,
cases
that
have
been
brought
up
or
that
we
collectively
felt
could
use
working
group
attention.
J
So
the
working
group
can
look
and
say
this
is
how
we
prioritize
those,
and
if
the
answer
is
the
working
group
thinks
none
of
them
are
addressable,
then
that's
great,
but
at
least
we
had
the
conversation
and
said
these
are
impor.
We
thought
these
may
be
important
and
we
went
through
and
decided.
They
were
not
I'll.
Give
a
concrete
example,
though,
of
something
that
as
a
client,
I
would
be
interested
in
consuming,
which
is
a
specific
description
about
resolver
authentication.
J
Once
you
have
encrypted
dns
servers
available,
it
only
stands
to
reason
that
you're
going
to
want
to
have
a
scenario
where
the
encrypted
resolver
gates
access
trust,
and
that
would
be
something
I'd
be
interested
in
consuming.
Today.
One
could
ad
hoc
that
and
say
we
can
use
whatever
client
authentication,
https
uses
and
that's
great,
and
if
all
we
do
is
say,
we
recommend
that
dns
clients
do
x
where
x
is
already
defined
elsewhere.
That
may
be
the
end
of
that
discussion,
but
for
some
reason
I
suspect
that
that
won't
be
as
simple.
J
So
yeah,
so
the
idea
being
that
a
private
entity
may
want
to
have
their
resolver
be
publicly
routable.
Such
you
know
say
that
the
world
was
facing
a
global
pandemic
that
required
lots
of
people
to
work
from
off
a
corporate
network.
It
would
be
nice
to
have
an
employee,
only
access
gate
on
a
resolver,
that's
actually
routable
publicly.
J
Thank
you.
I've
heard
that's
just
in
other
places
too.
So
that's
that's
one
example
I
can
think
of,
and
having
said
that,
though,
I
do
want
to
call
out.
I
agree
with
you
that
the
what
dear
and
what
btw
home
address
are
the
highest
priorities
and
I'm
in
no
way
suggesting.
I
don't
think
the
other
authors
of
that
first
presentation
are
suggesting
that
we
get
all
of
these
cases
shoehorned
into
those
two
drafts,
rather
to
define
than
the
next
priority
requirements
for
other
drafts
to
address.
B
N
O
Yeah,
just
continuing
the
discussion
a
little
bit
on
this
point
of
resolvers
authenticating,
the
users
and
stuff
like
this
is
something
that's
come
up.
A
couple
times
for
chrome
and
mostly
we've
been
pushing
back
on
just
because
things
like
client
authentication
is
something
that
chrome
doesn't
support
well
in
general,
and
we're
kind
of
pushing
back
and
saying
if
you
can
do
other
stuff,
like
proxy's
authentication,
maybe
go
there
instead
for
this
sort
of
use
case,
but
at
the
same
time
it
does
feel
like
there
is
some
valid
stuff
there
and
we've
also
been
saying.
O
Maybe
the
os
platforms
are
a
little
bit
better
position
to
handle
it,
but
as
to
the
point
of
whether
or
not
this
working
group
should
be
handling
this
topic
at
all,
I
think
it's
very
clearly
within
our
scope
of
our
charter.
When
we're
discussing
things
like
the
resolver
advertising,
I
support
this
mechanism
for
client
authentication,
actual
authentication
mechanisms
themselves.
O
They
might
be
out
of
charter
and
honestly,
a
lot
of
those
mechanisms
probably
already
exist
in
other
in
other
working
groups
and
have
already
been
published
as
specs.
So
I
don't
know
if
it
even
needs
to
be
discussed
anywhere
for
creating
new
such
mechanisms,
but
certainly
resolvers,
saying
I
support
this
mechanism
for
client
authentication.
That's
very
seems
very
much
in
scope,
and
maybe
that
is
one
of
the
things
that
might
be
higher
priority
handles
sooner
or
are
obviously
the
top.
D
Yes,
and
so
peter
van
dyke
just
brought
up
a
good
point
by
the
way.
I
thank
you
for
that
eric
it
didn't
mean
to
overlook
it.
I
want
us
to
be
aware
of
the
time,
because
I
think
glenn
wanted
five
minutes
at
the
end
of
our
session,
which
is
imminent,
so
I'm
going
to
close
the
queue
right
after
andrew
and
then
and
and
then
glenn
can
wrap
up
and
we'll
point
out
that
there's
another
interim
of
interest
in
many
folks
happening
about
half
an
hour
from
now,
so
so
andrew.
D
C
Thank
you.
I
just
wanted
to
pick
up
on
a
point
that
ekka
made
a
few
minutes
back.
I
don't
think
it'd
be
consistent
with
the
charter
of
the
working
group
that
there'll
be
some
sort
of
gate
that
the
client
developers
had
to
buy
in
to
a
user
requirement
before
the
discussion
was
pursued
within
the
working
group.
D
M
Well,
what
I'm
saying
is
that,
if
someone
proposes
a
requirement
that
they
think
users
already
be
interested
in
and
no
client
is
interested
in
it,
that
discussion
should
be
very
short,
because
we
shouldn't
standardize
things
that
aren't
going
to
get
implemented
and
the
same
will
be
true
for
no
server
being
interested
in
in
involving
it.
It's
just
like,
basically
shouldn't
standardize.
Things
only
have
the
required
two
endpoints.
They
only
have
one
endpoint.
D
H
B
Awesome,
hey!
Thank
you
everybody.
I
I
think
this
has
been
a
particularly
a
good
session,
very
quick,
wrap
up,
and
I
know
a
lot
of
people
are
going
to
be
a
half
hour
later
on
deep
river
at
their
interim.
So
looking
ahead
to
110
plan,
I
just
want
to
let
everybody
know.
We
have
requested
two
sessions
at
itf
110
with
the
first
one
being
the
longer
session
and
then
a
shorter
session
later
in
the
week.
We're
still
waiting
to
hear
back
from
the
secretary
on
that
scheduling.
B
If
there's
particular
topics
again,
we
tend
to
have
found
that
these
things
work
better
as
discussion
forums
versus
presentation
forms.
So
if
there
are
issues
that
people
believe
that
we
really
should
be
talking
about
at
the
itf
meeting,
please
let
the
chairs
know
so
we
can
make
sure
that
they
appear
on
the
agenda
and
then
between
now
and
light
f110.
It
looks
like
we're.
Gonna
have
a
couple
of
proposals
hitting
the
list
in
the
near
future.