►
From YouTube: IETF112-ADD-20211108-1600
Description
ADD meeting session at IETF112
2021/11/08 1600
https://datatracker.ietf.org/meeting/112/proceedings/
B
A
A
And
while
we're
waiting
for
tail
to
join,
it's
somebody
willing
to
act
as
our
scribe.
We
don't
need
like
line
for
line.
This
is
being
recorded,
so
we
don't
need,
like
the
narrative
and
the
whole
dialogue
captured.
What
we
really
need
is
any
decisions
that
get
made,
or
you
know,
sort
of
resolutions
we
come
to
captured
please
so,
hopefully,
it's
easier
subscribe
well,
really
describe
the
subscribe
for
the
the
the
hedgehog
dock,
the
hedge
dock,.
A
A
A
A
We've
every
working
group
has
had
to
apply
a
little
additional
focus
around
making
people
aware
of
the
contact
and
the
behavior,
not
that
we're
it's
calling
out
and
saying
anybody
in
add
has
been
causing
a
problem.
We've
been
getting
along
very,
very
well
in
my
opinion,
so
this
is
more
of
a
reminder
to
all
of
us
in
in
not
in
any
form
a
slap
on
anybody's
wrist,
but
please
be
aware
that
you
know
we
are
all
working
here
together,
be
kind
to
one
another.
A
The
itip
does
have
anti-harassment
policies
in
place.
We
have
an
ombudsman
to
work
with,
and
you
know
if
you
just
take
an
extra
second,
if
you're,
if
you're,
heated
and
passionate
in
the
discussion,
you
know
take
the
extra
second
to
have
an
extra
breath
before
you
maybe
respond
harshly
or
unkindly
to
somebody's
point
that
they've
made
and
we'll
all
get
along,
very
well
and
historically
add
has
gone
along
very
very
well.
It's
been
one
of
my
pleasures
to
co-chair
this
group
because
in
fact
we
are
so
well
behaved.
A
I'm
glenn
dean.
Obviously
I'm
one
of
the
co-chairs
of
edd
and
tail
a.k.a
david
lawrence
is
my
co-chair,
mr
eric,
and
I
I
I
don't
think
I'm
saying
eric's
last
name
perfectly
properly,
because
I
don't
have
the
proper
accent
but
he's
our
our
lovely
area
director
and
he
gives
our
good
oversight
and
an
overview
and
management
of
the
edd
working
group.
A
So
here's
our
agenda
for
today
we
are
going
through
that
we've
done
the
note.
Well,
they've
done
the
admin
portion.
This
is
the
part
where
we
have
the
agenda
bash.
If
people
looked
at
the
agenda
last
night,
there
was
one
change
overnight
in
that
we
had
an
additional
topic
here,
which
was
the
svcd
draft.
There
just
wasn't
a
lot
of
new
material
for
there,
so
we
don't
have
any
slides
being
presented
on
that.
A
A
F
A
E
E
E
So
that
leaves
us
with
one
currently
open
issue,
with
one
pull
request
that
I
have
made
to
satisfy
that.
So
I
want
to
go
into
detail
now
on
the
contents
of
this
pull
request
and
there
are
a
couple
different
changes
in
it,
and
so
I
want
to
walk
through
these
different
ones
and,
as
I
go
through
these,
I
want
to
make
sure
that
we
kind
of
all
understand
it
and
that
if
we
have
any
clarifying
questions
or
concerns
about
each
point
that
we
can
sort
those
out
now
all
right.
E
So
the
first
change
in
here,
which
I
think
is
kind
of
like
the
main
core
change,
is
something
we've
discussed
before.
I
think
it's
ultimately
not
going
to
be
really
controversial.
It's
just
what
is
actually
being
verified
previously.
The
text
for
the
case
where
you
already
knew
a
name
like
I
I
knew
I'm
talking
to
dns.google.
E
E
E
E
E
J
E
Yeah
specifically,
this
is
if,
if
the
thing
I
had
received
over
dhcp
or
had
manually
configured
was
8.8.8.8,
and
I
issued
a
udp
port
53
query
for
the
svcb
record
of
dns.resolve.opera
to
quad
8,
then
when
I
actually
connect
to
the
doe
or
dot
server.
I
look
for
quad
8
being
in
that,
because
the
thing
I
started
with
was
quad
aid.
A
K
Well,
so
now
I
now
I'm
confused
so
well,
so
I
thought
I
understood
so
I
think
we
all
agree
that
the
thing
you
started
with
bettering
the
certificate,
I
think
the
question
is
is
is:
does
the
thing
that
you
got
as
a
result
that
you
ddr
had
to
be
in
a
certificate,
so
I
start
with
quad
eight.
I
get
hey
look
over
here
at
you
know
I
don't
know
quad
four
and
then
squad
four
for
me
in
the
certificate
as
well.
E
K
E
E
There
are
a
couple
other
changes,
the
first
one
here,
I
also
think,
is
very
non-controversial.
We
need
to
clarify
that
you
didn't
start
with
resolver..
You
must
not
use
that
within
the
s
and
I
or
your
doe
request
authority.
That
is
not
a
thing.
So,
just
really
laying
that
out,
I
think
that's
a
good
thing
if,
for
some
reason
you
disagree
with
that,
please
speak
up,
and
then
I,
the
last
thing
which
I
think
needs
most
discussion
here-
is.
E
So
in
the
case
I
gave
before
we
have
quad
8,
but
there
also
is
this
identity
of
the
thing
I'm
connecting
to,
which
may
be
a
doe
server
that
is
running
on
as
dns.google
or
something
like
that
and
should
I
be
allowed
to
as
the
client
use
something
other
than
that
original
ip
address,
quad
8
as
the
authority
as
the
name
there's
the
host
I'm
connecting
to
in
the
doe
uri
martins
and
queue
I
do.
I
do
have
an
example
that
I
want
to
walk
through
here.
E
E
It
has
a
doe
server
running
h2
great
I'm
going
to
use
that
along
with
that,
because
this
is
svcp
I
will
either
have
received
ip
address
hints,
but
I'll
have
to
either
have
additional
records
that
came
along
with
this
for
a
and
quality
or
I'll
issue.
Specific
queries
for
a
in
quad
a
of
dns.google,
and
so
that
resolves
me
to
quad
8,
8.8
4.4
and
I
have
some
ipv6
addresses.
E
Our
client
stack
prefers
that
we
use
ipv6
addresses,
and
so
now
you
know
I'm
connecting
to
an
ipv6
address.
That
I
know
is
for
dns.google.
That's
the
thing
I
resolved
I'm
going
to
check
quad
8
in
the
certificate,
but
you
know,
is
the
client
allowed,
because
it
knows
that
it.
This
is
dns.google
to
put
that
as
the
authority
or
must
it
put
quad
8
as
the
authority.
F
F
If
you're
doing,
there's
obviously
two
places
s
I
and
the
host
headerfield
and
the
sni
field
is
a
simple
one:
don't
put
it
in
because
you
you
have
config
been
configured
with
or
have
discovered
an
ip
address,
and
you
don't
put
ip
addresses
in
that
field
for
some
reason,
the
host
header
field,
I
think
the
same
applies
there.
You've
got
an
ip
address
and
that's
what
you
started
with
and
that's
what
you
put
there
as
well.
E
F
E
F
K
But
I
I
think
I
basically
agree
with
martin,
but
I
actually
have
a
more
less
less
philosophical
and
possible
practical
concern.
Imagine
the
illustration
in
which
you
have
name-based,
virtual
hosting
and
and
in
which,
in
which
you
get
one
thing.
If
you
stuff
in
8888
as
a
host
header,
you
get
another
thing
you
stuff
in
you
know
safe,
maybe
safelookup.google.com,
right
and
so,
and
so
what?
K
So
I
I
I
for
a
little
bit,
and
maybe
maybe
you
could
persuade
me
that
that
already
is
a
problem,
but
I
don't
think
it
is,
and
the
reason
is
because
I
I
think
I
think
there's
I
mean.
Maybe
there's
no
actual
configuration
this
way,
but
it
seems
to
me
you
could
have
a
configuration
with
this
way
and
and
because
the
point
is
it's
not
really
a
matter
of
auditing
the
certificate.
K
It's
a
matter
of
what
the
client
tells
the
server,
what
its
expectations
are
and
and
and
and
the
server
may
or
might
use
us
an
eye
for
this
purpose
and
and
the
host
site
is
what's
intended
for
this
purpose.
And
so,
if
you
key
only
on
the
host
header,
it'll
be
legal.
In
this
case,
then
you
would
get
different
responses,
and
so
I
think
I
think
that
this
is
a
vulnerability
which
they
shouldn't
do.
E
So
I
think
this
is
something
that
already
exists,
because
you
also
have
the
the
doe
path,
which
could
also
be
a
way
of
splitting
up
like
I
could
have
a
different
path
for
different
functionality.
I
could
have
you
know
safe
dns
query
and
this
dns
query,
and
we
could
also
imagine
extensions
to
the
svcb
format
for
resolvers.
E
If
someone
is
attacking
me
to
try
to
get
me
to
go
to
a
different
variant
of
that
server,
they
already
could
by
changing
the
path
and
that
that
means
that,
essentially
it's
a
feature
of
this
that
you
could
have
different
things,
and
now
we're
essentially
saying
if
you
have
different
services
offered
by
something
that
can
be
delegated
by
quad
8.
They
can
only
use
the
path
and
they
cannot
use
the
name
to
offer
those
different
services
and
I
think
that's
an
unnecessary
restriction.
E
K
K
If
we're
gonna
have
anything
that's
not
covered
by
that,
then
the
text
needs
to
say
that
then
the
text
of
the
specifications
to
forbid
differential
behavior
based
on
anything
that
can
be
configured
by
the
attacker,
and
so
that
would
mean
do
a
path,
and
it
would
it's
that
aminopathy
would
mean
in
this
case
host
if
we
were
allowed
that.
So
I
think,
like
I'm,
happy
to
file
a
separate
issue,
but
I'm
just
saying
like
that:
it's
not
it's
not
a
reasonable.
K
K
It's
not
possible
for
the
attack.
If
cloudflare.
If
fire
only
has
one
dns
path
right,
then
there's
not
possible
attacker
to
forcing
the
wrong
answers.
But
in
the
situation
with
with
a
lot
of
specified
the
host,
then
in
fact
then
in
fact
I
can
just
I
can
just
divert
them
entirely.
My
resolver
and
my
fake
was
over
and
I
can
say
anything
I
want
so
it's
actually
much
much
worse.
K
E
K
K
E
J
J
L
I
L
L
L
Right
because
it
would
allow
things
like
allowing
anybody
in
the
world
to
rewrite
your
gmail
cookies
or
extract
them.
So
if
you
know
maybe
in
in
a
you
know
completely
stateless
isolated,
http
context,
somehow
it's
safe,
but
it
definitely,
I
think,
would
constitute
a
violation
of
the
http
semantic
rules,
because
https
urls
are
only
valid
for
authorities
that
have
proven
cryptographic,
control
of
the
that
have
cryptographic
proof
of
control
of
the
authority
name.
L
B
I
E
M
M
I
think
the
issues
that
the
the
attacks
people
just
raised
added
on
to
some
of
the
ones
like
I
think,
even
the
even
the
topic
of
what
to
do
with
sni,
is
critical
here,
because
a
lot
of
these
things
are
sufficiently
multi-hosting
environments
that
we
need
to
make
sure
that
the
client
must
send
a
s
I
that
matches
what
it
expects
to
come
back
but
s,
but
there's
the
messy
situation
that
the
draft
or
the
specifications
for
s.
I
only
allow
names
to
get
sent.
M
And
I
think
we
we,
but
I
think
we
need
to
have
an
sni
here,
because
some
of
these
are
multi-tenant
enough.
Like
you
take
the
google
front
end
if
you
just
send
it
over
quite
a
a
practical,
if
you
send
to
dns
google.google
a
request:
you're
not
going
to
get
back
a
cert
that
contains
ip
addresses,
because
those
are
on
those
are
sufficiently
multi-tenant
that
that
the
server
is
not
going
to
know
what
to
apply,
and
that
applies
to
a
lot
of
other
similar
services.
And
we
what
we
do.
M
E
M
M
Those
are
practical
deployment
considerations
we
may
we
should
look
at
even
at
least
for
some
of
the
examples
we're
using
as
to
whether
or
not
those
would
actually
work
in
production
and
whether
or
not
those
are
going
to
be
whether
or
not
they're
going
to
be
new
vulnerabilities,
like
the
ones
that
were
suggested
that
show
up
could
have
given
these
default
configurations
of
of
how
a
number
of
things
provided.
Those
services
today
work.
A
D
I
think
this
proposed,
I
think
this
proposal
is
the
best
we
can
do,
and
that
makes
me
very
unhappy
because
we're
taking
this
ip
address,
you
have
this
name
flying
around
that
you
then
resolve
and
you
don't
actually
use
for
anything
and
then
with
sni
you're
sort
of
going
to
have
to
send
it
to
the
same
same
ips
that
that
name
resolves
to
set
them
all
up
to
work
static.
There's
just
nowhere
around
that,
and
this
whole
thing.
D
If
you
feel
very
sad
that
we
can't
use
domain
names
freely
everywhere
and
have
to
stick
with
ip's,
I
don't
see
a
way
around
it,
because
what
you're
looking
for
is
an
alternate
way
to
read
something.
You
only
know
by
an
ip
address
and
so
you've
got
your
got
an
ip
address
as
your
root
as
the
thing
you
want
to
connect
to.
N
N
I
don't
know
if
that's
still
amenable
to
people,
because,
like
tommy
said
this
isn't
about
requiring
that
name
be
used.
It's
not
forbidding
name
to
be
used
where
ip
address
can
also
be
used,
because
ben
has
a
point
making
an
https
connection
where
we're
not
authenticating
the
host
name
is
is
very
odd.
Ddr
itself
doesn't
require
it,
because
the
identity
that
ddr
is
authenticating
is
the
starting
ip
address
in
practice.
N
That's
fine,
but
if
they
want
to
provide
a
name
like
dns.google,
instead,
that's
fine
too,
but
I
totally
acknowledge
that
that
name
can
be
modified
by
attacker
on
the
path
back
and
so
not
branching
on
that.
Behavior
is
wise,
so
I'd
be
fair,
adding
that
security
consideration,
but
I
don't
see
that
as
a
reason
to
forbid
providing
a
name
that
includes
alpha
characters
outside
of
just
ip
addresses
in
that
target
name.
L
All
right
so
responding
to
tommy.
First,
I
think
there's
a
slight
miscommunication
there,
so
the
the
example
record
that
tommy
paulie
has
at
the
top
of
the
slide,
would
be
considered
valid
and
acceptable
as
a
ddr
record,
regardless
nobody's
demanding
a
change
to
the
contents
of
the
target
name
field.
Here,
it's
just
a
question
of
what
the
client
is
allowed
to
do
with
that
information.
L
As
for
servers
not
branching
on
the
authority,
I
think
to
summarize
ecker's
point
that
is
currently
a
very
common
generally
allowed
behavior
and
so
declaring
that
servers
are
not
allowed
to
do
it
in
the
ddr
context
would
be
a
pretty
remarkable
deviation
from
the
rest
of
http,
where
they
are
always
allowed
to
branch.
On
that
I
I
wanted
to
quickly
say.
I
think
the
ideal
solution
here
might
well
be
to
enable
essentially
ip
addresses
in
sni.
L
L
That's
not
the
same
certificate
that
you'll
get.
If
you,
if
you
try
to
open
that
connection
to
www.google.com
yeah
exactly
so,
it
depends
on
the
on
the
host
configuration.
If
you
want
more
flexible
virtual
hosting,
then
I
think
currently,
we
just
don't
have
the
ability
to
do
that
securely
and
also
just
to
briefly
to
the
point
about
dopath
being
attack
controlled.
E
P
I
see
the
I
see
the
rfc
8738,
the
acme
ip
identifier,
validation
extension
does
allow
ip
addresses
in
sna
hostname,
but
with
a
suffix
of
ipv,
with
the
rpa
to
create
a
domain
name
with
the
ip
address.
So
it
does
allow
sna,
hostname
extension.
So
that
should
work
for
this
specification
and
we
should
be
able
to
take
host
names
within
the
sni
host
field.
K
Right
just
waiting
so
yeah.
I
think
these
are
a
number
of
issues
here,
probably
which
I
feel
like
we're,
not
we're
getting
we're
getting
we're
going
to
need
someone
to
labor
all
this
stuff
down.
There's
the
issue
of
like
what
has
to
be
in
the
certificate.
There's
the
issue.
What
the
client
has
to
say
to
induce
it
to
be
in
the
certificate.
K
K
Yeah
exactly
it's
a
matter
of
saying
like
this
is
what
you
have
to
do
if
you're
one
of
these
things
right,
yeah
and
then
there's
this
question
because
I
host
right,
so
I
think,
like
those
are
all
like
kind
of
separable
here,
I
guess
one
thing
I
would.
I
guess
one
thing
I
would
say
is
at
the
current
moment:
it's
really
not
it's
not
sensible.
K
H
K
And
I
I
don't
think
this
that
opera
thing
is
a
good
idea,
but
I'm
sure
you'll
find
a
way
to
do
it.
Another
thing
you
could
do
is
by
the
way,
just
have
a
fls
fly.
That
says
I
didn't
send,
dress
and
I,
but
I
meant
ip
address
right,
because
we
now
have
this
purpose,
so
I
think
that
that
problem
is
emily
soluble.
I
would.
E
All
right,
I'm
done.
Thank
you,
okay,
cool
zeo,
so
that's
essentially
it
it
sounds
like
I'll
modify
the
pr
to
just
say:
hey
you
use
the
ip
address.
I
think
it'll
just
simplify
the
text
and
I
can
share
a
link
to
that
on
the
list.
I
believe.
After
that,
then
we
should
be
ready
for
working
group.
Last
call.
A
Q
Yeah
they
don't
advance
for
me,
so
I
only
have
one
thing:
authors
consider
this
ready
for
a
working
group.
Last
call.
I
know
we
were
holding
off
on
doing
that
to
to
do
ddr
and
dnr
at
the
same
time
to
make
sure
that
some
of
the
security
aspects
of
both
are
aligned
and
we
have
no
changes
to
the
dock,
but
we
consider
this
ready
to
go.
A
A
A
L
L
So,
in
this
context,
in
ddr
when,
when
you're
trying
to
upgrade
starting
with
insecure
dns,
an
active
adversary
can
always
win
the
an
active
adversary
between
the
client
and
their
sort
of
closest
apparent
resolver
can
always
just
drop
the
ddr
queries
and
prevent
ddr
from
ever
happening.
Keep
the
client
unencrypted
and
monitor
and
modify
their
their
requests.
So
there's
no
real
authenticated
encryption.
There's
no
real,
strong
security
possible
here.
We're
only
talking
about
shades
of
opportunistic
encryption.
L
If
the
forwarder
is
has
been
upgraded
to
fully
implement
ddr
itself,
but
otherwise
it
it
basically
excludes
upgrade
across
a
forwarder,
and
we
have
a
bunch
of
reports
and
and
sort
of
experience
in
the
working
group.
That
says
that
there
are
a
very
large
fraction
of
internet
users
who
are
essentially
stuck
behind
one
of
these
forwarders,
where
otherwise
they
would
be
able
to
use
encrypted
dns
to
the
upstream
resolver.
L
So
this
draft
is
an
informational
draft,
we're
discussing
client
policy,
which
the
working
group
has
it's
at
least
a
challenge
to
to
say
normative
to
make
normative
statements
about.
So
this
draft
doesn't
attempt
to
make
any
normative
statements
about
it.
It
considers
a
client
policy
that
would
have
this.
That
would
be
able
to
upgrade
in
this
context,
and
the
key
thing
that
changes
with
this
client
policy
is
that
we
remove
this
requirement.
L
So
first
I
want
to
emphasize
things
that
don't
change
between
that
aren't
affected
by
this
discussion.
Malware
and
threat.
Main
filtering
services
are
not
affected
here,
because
they
can
very
easily
just
add
resolver.rpa
to
the
list
of
domains
that
they
don't
allow.
Access
to.
That
list
has
to
be
dynamically
modifiable
because
they're
chasing
an
evolving
threat,
landscape
or
an
evolving
set
of
services
that
fall
into
their
categories.
L
So
it's
it's
really
straightforward
for
them
to
actually
maintain
control
and
prevent
the
cross-forward
or
upgrade
here
if
they
want
to
prevent
it,
and
also
there
are.
There
are
a
lot
of
other
things
that
our
people
like,
like
upstream
resolvers,
doing
things
on
behalf
of
the
client.
That's
obviously
not
effective
because
we're
not
changing
which
upstream
resolver
is
in
use,
but
there
are
some
real
concerns
with
this.
You
know
clarifying
questions
please,
neil.
R
L
R
L
So
I
would
definitely
be
interested
in
learning
more
about
the
implementation
examples
there.
As
we
pointed
out
in
the
draft,
it's
it
seems
like
it
can't
be
implemented
in
any
effective
way,
using
dns,
because
clients
have
substantial
amounts
of
caching.
So
major
services
like
if
you're
accessing,
I
don't
know
youtube
or
something
there's
a
good
chance
that
it's
just
going
to
continue
to
work
after
the
dns
stuff.
R
L
A
A
L
Yeah
yeah,
okay,
so
this
does
raise
some
concerns.
One
of
the
concerns
here
is
that
somebody
injected
a
long-lived
ddr
response
appeared
on
the
network
for
a
few
minutes
injected
a
long-lived
ddr
response
that
redirects
everybody
to
their
server
and
then
walks
away.
They
can
their
attack
can
continue
after
they
cease
to
be
present,
and
so
there
are
some
potential
that
that's
a
real
concern
and
there
are
some
mitigations
that
can
reduce
the
surveillance
of
that
concern.
One
one
way
to
mitigate
it
would
be
to
limit
how
long
you
cache
these
records.
L
L
Another
class
of
security
concerns
is
related
to
how
this
interacts
with
forensic
logging.
So
the
draft
has
some
advice
on
how
to
configure
forensic
logging
to
to
make
sure
that
you
can
still
capture
any
attacks.
That
might
happen,
and
there
are
also
some
interesting
compatibility
impacts
that
could
arise
if
a
client
tried
to
do
this.
So
split
horizon
namespaces
are
a
little
bit
like
a
little
bit
like
the
threat
domain
filtering
that
we
talked
about
earlier,
but
they're,
not
necessarily
dynamic.
L
A
forwarder
could
have
been
configured
with
the
same
split
horizon
namespace
10
years
ago
and
never
touched
since
we
want
to
make
sure
that
we
don't
break
those
configurations,
and
so
there
are
ways
to
solve
this,
or
at
least
there
are
nations
that
can
can
avoid
visible
break
in
situations
like
this
and
one
mitigation
we
mentioned
in
the
draft
is
nx
domain
fallback.
So
try
to
look
up
the
domain
through
the
upstream
resolver,
but
if
it
fails,
you
can
disable
encrypted
dns
and
try
again
through
the
through
the
network's
unencrypted
resolver.
L
There's
some
interesting
questions
around
safe
search
type
domains,
which
we
coined
the
term
interposable
domains
for
these
domains.
That
are
deliberately
meant
to
be
modified
by
resolvers,
in
particular
ways
again
that
that
might
have
been
done
10
years
ago
once
and
we
don't
want
to
break
those
configurations
with
a
with
any
client
side
changes.
That
would
be
a
problem.
So
there's
some
discussion
of
do
about
that
best.
L
L
L
It
doesn't
have
any
recommendations
on
what
you
should
do
and
it's
it's
seeking
working
group
adoption.
One
thing
that
I
I
guess
I
just
skipped
reading
the
slide
is
that
this
alternative
client
policy,
while
it
carries
a
bunch
of
tricky
trade-offs,
would
likely
enable
a
lot
more
ddr
upgrades.
So
it
would,
it
would
be
likely
to
result
in
a
large
increase
in
the
amount
of
encrypted
dns
on
the
internet.
J
Example-
and
I
think
chris
verified
this
in
chat-
that
the
blocking
really
only
applies
to
being
done
at
the
forwarder,
because
you
never
know
if
that
request
is
actually
making
it
to
a
cloud-based
malware
inspection
service
right,
it
could
be
man
in
the
middle
before
then
so
yeah.
This
comment
here,
I
think,
only
applies
if
the
forwarder
itself
is
providing
that
service
right.
L
So
we're
talking
here
about
legacy
forwarders,
which
means
they're
not
in
the
context
of
this
draft,
means
that
they're
in
general,
not
modifying
queries
on
either
leg.
So
an
on
path
attacker
on
either
section
of
the
path
can
always
prevent
the
ddr,
upgrade
just
by
dropping
the
ddr
query
or
response.
J
L
Yes,
that's
right,
so
this
does
impact
other
uses
of
ddr.
It
impacts
the
client
security
generally
and
the
draft
walks
through
the
implications
of
that,
but
it
only
applies
when
the
apparent
resolver
is
identified
by
a
local
ip
address,
which
means
that
authenticated
security
is
not
really
possible
anyway.
L
O
O
I
know
that's
one
of
the
questions
you
have.
Of
course
we
have
been
discussing
about
some
of
the
ipv6
issues
and
things
like
that
and
yeah.
I
just
think
these
need
to
continue
to
be
discussed,
and
this
gives
me
some
hope
that
we
might
find
some
sort
of
way
that
devices
behind
forwarders
could
get
upgraded
thanks.
J
P
That
are
there,
but
I
think
I
think
it
should.
I
think
we
need
more
lot
more
details
to
be
discussed
in
the
security
constitution,
especially
with
these
legacy
routers,
where
even
the
config
cannot
be
updated
and
that's
the
case.
This
draft
is
addressing
and
even
if
the
config
cannot
be
updated,
then
it
seems
like
if,
with
these
home,
routers
they're
easily
susceptible
to
several
firmware
vulnerabilities
and
typically
they
have
several
firmware
upgrades
to
address
those
vulnerabilities.
If
those
vulnerabilities
are
not
getting
fixed,
then
to
support
that
kind
of
a
deployment
right,
I
mean.
P
L
L
F
Yeah,
so
ben
thanks
for
thanks
for
doing
this.
This
has
got
a
bunch
of
interesting
sort
of
implications,
but
I
suspect
that
people
are
going
to
be
doing
this
exact
behavior
and
it
will
serve
a
very
large
number
of
people
and
provide
them
with
some
amount
of
encryption.
I
don't
know
how
good
it
is,
because,
obviously
this
is
vulnerable
to
on
path.
Attackers
and
mr
points
out
one
of
those
on
path.
F
Attackers
is
the
unpatched
router
that
hasn't
been
updated
report
this
stuff,
but
it's
certainly
not
worse
than
it
was
before
in
in
any
way,
and
so
I'd
like
to
see
his
work
on
this,
I
don't
think
we
need
to
set
the
bar
particularly
high
when
it
comes
to
making
sure
that
everything
across
the
board
is
is
covered
in
the
security
considerations,
particularly
because
that
increases
her
exposure
to
the
sorts
of
things
that
barbara
mentioned
I'd
be
interested
in.
Why
barbara
thinks
that
this
might
not
get
through
a
last
call.
S
S
Specifically,
I
think
for
your
draft.
One
of
the
biggest
issues
may
be
that
actually
most
of
these
proxies
or
forwarders
are
not
true
forwarders
in
the
dns
sense
at
all,
but
are
actually
just
simple
udp
algs
application
rate
gateways.
They
actually
don't
really
speak
the
dns
protocol
at
all.
They
just
forward
it
over
udp
up
to
an
upstream
device
and
send
the
responses
back.
S
But
if
ppp
session
drops,
which
is
quite
common
over
dsl
type
home
gateways,
there
simply
is
no
upstream
dhcp
information
to
have
to
be
had
so
say,
that's
probably
more
for
the
dnr
draft
than
for
this
one,
but
I
would
very
strongly
recommend
both
authors
have
a
look
at
that
previous
rfc
and
do
get
back
to
me.
Please.
If
you
want
any
further
details
on
that
research,
I
did
thank
you.
L
G
Those
of
us
familiar
with
isps
will
know
that
consumer
customers,
you
know
you're
lucky
to
get
them
to
change,
we're
in
a
10-year
time
frame.
That's
not
because
the
isp
doesn't
want
to
change.
That's
because
the
consumers
have
got
a
lot
of
inertia,
you
can
send
them
free
stuff
and
they
won't
necessarily
unwrap
it.
Let
alone
switch
it
on.
G
So
this
isn't
a
problem.
That's
just
going
to
disappear
in
12
months.
You
know
most
people
don't
have
the
budgeting
of
a
of
a
tech
firm,
and
I
think
we
need
to
consider
that
yeah.
This
is
a
long-term
hardware
problem,
not
a
software
problem
and
the
other
thing
which
we
shouldn't
overlook,
overlook
either
yeah,
let's
remind
ourselves.
This
is
85
of
the
market
yeah.
This
is
a
non-trivial
thing.
G
L
Thank
you,
andrew
one
thing
I'll
quickly
say
is
that
there
might
even
be
cases
in
the
indefinite
future
for
this.
If
you
imagine
a
a
forwarder
that
really
wants
to
get
out
of
the
way
is
trying
to
get
out
of
the
way
it
might
actually
want
clients
to
do
this
kind
of
cross-forward
or
upgrade,
but
we
can
talk
about
that
later
back
to
you,
glenn.
A
Okay,
thank
you
ben.
You
know
by
the
way,
I'll
comment.
I
think
this
is
a
having
these
smaller
drafts
that
we
can
focus
on
issues
around
this.
This
is
a
great
way
to
work
through
and
resolve
them.
So,
thanks
to
both
you
and
and
chris
for
putting
this
one
together
and
letting
us
talk
to
us,
because
we've
been
touching
this
issue
for
quite
a
while
now,
so
it's
good
to
see
us
making
progress
on
it.
So
thank
you.
A
A
Okay,
thank
you
and,
and
so
the
chairs
have
been
trying
to
work
through
what
the
right
path
here
and
we're
looking
for
direction
for
the
group,
because,
ultimately,
it's
the
working
group
that
decides
what
gets
adopted
and
what
we
work
on
so
the
first
one
we're
going
to
do
here
is
we're
going
to
talk
about
the
split
verizon
dns
configuration
and
let's
keep
the
the
top
focus
right
there.
What
we're
really
looking
for
here
is
not
to
turn
this
session
into
like
a
debate
on
you.
A
Do
we
adopt
do
we
not
adopt,
but
let's
talk
about
the
document-
and
you
know,
is
this
something
that
the
group
feels
that
we
should
be.
You
know
you
know
ultimately
adopting
or
not.
You
know
what
what
are
your
feelings
on
that
and
then
ultimately
we're
gonna.
You
know
we
have
the
request
for
adoption
out
on
the
list
still
and
ultimately
we're
looking
for
a
feedback.
You
know
here
and
there
and
then
we'll
try
to
figure
out
if,
if
we
move
forward
with
one
or
boulder
either
of
these
drafts.
Q
A
G
T
A
A
C
A
Q
All
right,
maybe
maybe
the
echo,
will
be
better
too.
Let
me,
let
me
know:
okay,
yeah
yep
go
to
slide
two,
so
the
so.
The
last
time
we
presented
this
was
last
itf.
It
was
version
four
we're
now
at
version,
seven
removed
a
little
bit
of
latent
text
that
was
accidentally
in
there
talking
about
the
enterprise
use
cases.
Q
Q
Then
what
we're
proposing
in
the
document
to
do
differently
is,
after
gathering
the
information
from
steps
one
through
seven,
which
is
what
are
the
local
dnr
host
names?
What
are
their
ip
addresses
and
what's
the
fqdn
for
the
the
provisioning
domain
and
learning
the
details
of
the
provisioning
domain
and
getting
that
json
back
after
getting
all
that
stuff
in
steps?
Q
One
through
seven
is
go
off
and
talk
to
the
public
to
a
public
resolver
and
ask
it
who
owns
that
domain
and
see
that
there's
a
match
if
there
is
a
match,
then
continue
using
that
network
encrypted
resolver?
That
claimed
to
be
authoritative
for
that
domain
and
claim
to
be
responsible
for
it
and
use
it
for
that
domain,
and-
and
that's
that's
the
the
gist
of
of
what
we're
proposing
and
that's
really
my
update.
I
have
a
another
slide.
Q
We
may
want
to
just
foot
back
and
forth
between
this
one
and
the
last
one
to
help
frame
the
discussion,
but
the
last
slide
that
I
have
is:
does
this
describe
a
real
problem?
Do
we
want
to
have
strong
authentication
and
authorization
of
horizon
dns,
and
is
this
mechanism
reasonable,
and
I
think
there
are
two
separate
questions.
This
is
just
the
mechanism
we
thought
was
reasonable
and
go.
A
Paul-
and
let
me
make
one
comment
from
the
chair
of
you-
is-
I
believe
that
you
know
there's
we're
gonna.
If
we
do
adopt
it,
it
will
get
renamed,
so
people
are
upset
with
the
word
enterprise
in
there.
I
think
there
was
general
agreement
that
we're
enterprise
we
get
removed
in
a
renamed
adopted
version.
H
Okay,
paul
speaking,
so
I'm
still
a
little
confused
about
the
relationship
of
the
split
dns.
That
is
not
in
the
public
view
and
sort
of
asking
the
public
few
for
confirmation
that
this
non-global
space
exists,
because
if
you're
asking
a
public
server
if
it
exists-
and
you
get
a
confirmation
it
exists,
then
it's
not
a
private
space
anymore.
So
then,
why
is
anything
needed
at
all,
especially
if
you're
not
talking
about
an
enterprise
split
but
about
like
some
custom
portaling
page
then
didn't
they
just
put
it
in
public
dns?
Q
So
a
lot
of
enterprises
enjoy
doing
this
split
so
that
they
only
have
their
public
servers
on
the
public
dns
as
we
know,
and
they
have
all
of
their
thousands
and
thousands
of
private
domains
on
their
their
split
horizon
dns
that
are
only
accessible
internally
and
that's
how
lots
of
enterprises
have
enjoyed
deploying
their
dns.
You
know.
Q
H
I
H
Q
We
can
prove
that
it
does
not
own
apple.com
and
it
it
should
not.
Have
the
split
dns
queries
sent
to
the
local
starbucks
name
server,
that
someone
is
advertising
there
with.
You
know
their
ssid
and
their
raspberry
pi
sitting
in
the
corner
or
whatever
is
to
detect
that
very
case
and
prevent
that
from
happening.
A
D
Hi
watson,
clever,
I
am
very
confused
by
the
at
first.
I
don't
think
split
split,
that's
a
good
idea!
You
don't
need
it,
it
conflates
name,
visibility
and
being
able
to
access
servers
and
that's
not
how
the
internet
works
and
then,
with
this
draft
I
have
the
same
confusion
as
paul.
If
you
have
a
public,
if
you
have
a
namespace,
that's
public
and
you're
just
trying
to
get
your
result
answer
you
know
by
using
a
public
recovery
for
this.
D
D
That's
saying
we're
going
to
end
up
different
answers
through
public
resolvers
or
notice
that
our
name
servers
are
we
get
back
from
the
public
because
you
don't
get
the
names
from
public
customers.
You
get
the
answer
back.
So
if
you're
only
you're
going
to
do
the
crawling
of
dns
yourself,
you
don't
really
have
a
problem,
or
maybe
I'm
just
misunderstanding.
This
entirely.
Q
D
Q
A
E
All
right-
and
I
I
think
this
is
definitely
a
real
problem
for
better
or
worse.
You
know
I,
I
care
a
lot
about
how
we
handle
split
dns
paul
and
I
wrote
a
document
for
how
to
do
it
in
ip2.
So
I
think
it's
I
think
the
answer
to
the
first
one
is
yes,
there
is
a
real
problem
here,
I'm
not
quite
sure
about
the
solution
and
I
think,
more
importantly,
for
the
question
of
adoption-
and
this
is
what
I
brought
up
on
the
list.
E
E
This
is
going
into
a
much
bigger
question
about
how
a
network
expresses
authority
over
specific
resources,
which
is
really
interesting,
but
that
could
have
its
own
working
group
to
talk
about
all
the
details
there.
You
know
I
like
the
idea
of
using
pvds
somewhere
in
this
pvds
was
done
in
into
area,
and
we
we
need
some
of
that
audience
to
do
the
work,
not
just
what
we
have
in
80d,
okay
and
then
just
to
the
solution
a
little
bit.
E
I
think
the
case
where
you
have
you
know
a
purely
private
name
or
a
private
domain,
which
I
think
this
tries
to
address.
I
don't
see
that
as
too
much
of
a
hard
scenario,
so
you
know
we're
already
using
encrypted
dns
for
our
icloud
private
relay
service
with
apple,
and
we
fail
over
for
non-public
names.
If
you
try
to
get
to
some
resource
on
the
internal
mobile
network
that
doesn't
resolve,
we
try
it
publicly
and
then
we
try
it
locally
and
by
policy
that
can
work.
E
A
E
L
J
L
It's
secure
and
appropriate
for
them
to
be
to
be
connecting
to
particular
servers
to
get
answers
for
particular
names,
and
I
think
this
draft
actually
achieves
that.
So
I
think
it's
it's
worth
moving
forward
with.
For
that
reason,
I
do
think
that
there
are
two.
As
you
pointed
out,
there
are
two
separate
solutions
here
and
essentially
for
these
two
cases,
one
of
which
for
names
that
truly
do
not
exist
in
the
public
dns.
L
So
if
you're
talking
about
cases
where
the
name
does
not
exist
in
the
public
dns,
that's
the
case
where
annex
domain
fallback,
as
tommy
paulie
mentioned
already
handles
quite
well.
It's
also
the
case
that
creates
the
risk
of
typo
squatting
that
paul
routers
pointed
out.
I
think
it
would
be
worth
considering
removing
that
from
this
draft
and
focusing
on
the
hard
case,
the
the
case
where
the
name
potentially
does
exist
in
the
public
dns,
but
you
still
want
users
to
resolve
it
differently
on
your
network.
L
I
think
that
the
mention
the
discussion
of
use
of
public
resolvers,
while
it's
very
practical,
I
think,
is
raising
a
lot
of
hairs
on
on
people's
necks
and
is
not
actually
necessary.
I
think
it
would
be
clearer
if
the
draft
based
that
entirely
in
dns
sec
and
the
draft
can
be
done
without
any
discussion
of
public
resolvers
if
you,
or
at
least
without
any
reliance
on
them.
L
If
you,
if
you
just
if
you
say
that
the
authentication
of
the
relationship
between
the
covered
name
and
the
local
resolver
is,
is
based
in
dnssec
and
then
you
know
if
people
want
to
delegate
dnsec
validation
to
a
trusted
third
party,
that's
their
business.
We
don't
have
to
tell
them
to
do
that,
so
so,
overall,
I'm
supportive.
But
I
think
the
draft
needs
a
lot
of
work
and
may
not
be
ready
for
adoption,
but
that
doesn't
mean
it's
not
worthwhile.
K
Anchor
yeah,
I
I
also
so
I
think
this
is.
I
guess
we
take
this
in
order.
It's
an
interesting
problem
which
was
not
a
problem
but
like
probably
when
we
do
have
to
attempt
to
attack
in
some
way,
or
at
least
like
make
a
run
at
by
we
I
mean
I
have
collectively
I'm
I
I
don't
think
the
draft
else
was
quite
ready
for
adoption.
I
think
I
could
have
better
understand
what
the
solution
was
like.
K
I
I
think
there's
like
enough
questions
that
we
can
actually
solve
the
problem,
but
I
have
a
solution
that
I
was
pretty
confident
up
in
hand,
I'm
agnostic
on
the
question
of
whether
it
goes
in
add
or
in
some
other
group.
I
would
like
that
ads
worry
about
that.
You
know
this
is
excitation
people
float
around
a
little
bit.
I
agree
with
ben
that
the
the
the
non-existence
case
is
less
interesting
than
the
the
multiple
answers
case.
We
we
also
fall
back.
K
That's
like
like
the
kind
of
solution
people
are
gonna.
I
mean
that
that's
the
thing
you're
gonna
have
to
do
anyway.
I
mean
because
this
is
the
employment
realities.
This
will
not
be
universally
deployed
and
therefore
there'll
be
a
lot
of
places
with
horizon,
where
you'll
have
to
fall
back
anyway,
and
it's
like
really
like.
Doesn't
it
help
you
that
much
to
have
to
have
this
this?
J
Yeah
thanks
so
tommy
back
to
the
comment
you
made
earlier
and
I
put
this
in
chat.
The
problem
with
nx
domain
in
terms
of
enterprises
is
you're
leaking
enterprise,
private
names
to
public
dns
servers
and
we've
put
a
lot
of
work
over
the
last
15
years
into
vpn
clients
to
actually
block
that
behavior,
because
customers
have
demanded
that
right.
They
don't
want
their
private
dns
names
resolved
by
or
attempted
to
be
resolved
by
resolvers
other
than
their
own.
J
So
I
think
you
know
that
problem
needs
to
be
solved
in
a
way
that,
and
I
think,
beyond
just
vpn
in
a
way
generically
for
for
dns
right.
Additionally,
we've
put
a
lot
of
effort
into
you,
know:
zero
round
trip
time,
protocol,
improvements
and
nx
domain
processing
you
know
adds
latency,
for
every
request
has
to
fail,
then
try
to
get
on
a
different
interface.
Now
there
is
some
parallel
dns
opportunistic
dns
resolutions,
but
again
those
start
sending
dns
enterprise
dns
names
out
over
interfaces
that
the
enterprise
doesn't
want
them
sent
over.
J
C
And
if
you
see
this
one
discussing
the
chat,
not
if
okay
but
whatever
so
I
hear
a
lot
of
interest
in
this
draft
also
here
there
are
some
issues,
but
you
are
talking
about
for
a
call
for
adoption.
So
my
only
slight
concern
about
the
call
for
adoption
is
whether
it
should
be
done
in
admd
or
someplace
else.
My
understanding
is
really.
C
It
fits
a
dd
charger.
So
for
me,
that's
good.
We
may
want
to
check
with
the
chair
with
dns
top
and
interior
chairs
as
well,
whether
there's
a
best
fit
outside,
but
for
me
it
fits
led.
People
are
ill,
are
aware
of
the
problem,
so
it
should
stay
there,
but
I
will
double
check,
but
again
it's
just
for
call
for
adoption.
So
that's
normal
to
have
issues.
Let's
solve
those
issues
before
the
group
last
call.
T
Thanks,
so
this
space
has
a
huge
amount
of
history
in
it
and,
though
you
know
it
may
seem
like
80d
is
interesting,
first
place
to
hit
it.
It's
it's
actually
quite
old,
and
I
just
sent
a
note
to
the
mailing
list
that
includes
even
a
draft
going
back
to
2007
for
how
to
deal
with
split
dns
within
dns.
Second,
how
hard
that
is
as
well
as
rfc
8244
should
definitely
be
read.
T
You
know
when
considering
this,
because
it
talks
about
all
the
issues
with
private
namespaces
and
how
much
trouble
that's
caused,
and
you
know
between
both
both
dns
within
the
ietf,
including
dns
op
and
within
icann.
This
problem,
you
know,
has
a
very
ugly
rearing
head.
That
is
much
much
larger
this
than
this
group,
so
I'd
I'd
tread
cautiously,
because
if,
if
you
think
you're
going
to
add
a
split
dns,
just
in
the
context
of
add
or
how
to
deal
with
it,
just
here
there'll
be
huge
dragons
there.
A
Q
Yeah
that
2007
dns
sec
split
horizon
draft
was
was
great.
I
have
not
dug
into
the
history
of
why
it
was
abandoned,
but
it
describes
four
ways
of
deploying
dns
sec
with
horizon.
Three
of
them
would
work
with
what
what
we
have
in
mind.
One
of
them
doesn't
and
that
would
take
on
you
know
that
would
eliminate,
like
several
people
suggested.
It
would
eliminate
having
to
talk
to
the
public
dns
to
ask
any
questions.
Instead,
you'd
have
all
the
answers
in
the
dns
signed
records
yourself,
so.
T
Q
T
A
A
R
Okay,
this
is
old-fashioned,
you
do
it
for
me,
yeah
I'll
I'll,
do
it
for
you,
so
you
let
me
know
when
you
want
to
change
the
page.
Okay,
all
right
change,
the
page
all
right,
so
I'm
going
to
speak
on
behalf
of
my
co-authors,
so
this
is
really
the
approach
here
is
just
very
high
level
architectures
to
just
to
to
capture
like
the
deployment
scenarios
that
cover
the
ad
protocols,
specifically
really
about
in
home
networks,
when
you're
deploying
ad
protocols
and
home
networks,
it's
not
going
into
any
kind
of
network
specifics.
R
We
really
use
this
when
we
were
kind
of
figuring
out
how
to
do
dnr,
we
used
it
really
to
just
describe
all
the
different
options
for
what
dnr
would
do,
what
what
ddr
would
do
and
just
kind
of
go
through
the
different
scenarios.
You
go
to
the
next
slide,
so
this
was
actually
part
of
the
the
dnr,
the
dnr
spec.
Originally,
so
we
pulled
it
out.
R
R
What
it
mainly
focuses
on
is
the
target
deployment
so
managed
and
unmanaged
home
router
scenarios,
and
what
do
you
do
if
you're
hosting
a
forwarder
in
the
in
the
local
network?
So
so?
When
would
you
use
dnr?
I
wanted
to
use
ddr
some
some
options
when
you
might
use
acme
these
kind
of
things,
there's
some
nice
network
diagrams.
When
would
you
use
what
would
it
look
like
when
you
have
a
legacy
router
that
can't
be
upgraded?
What
would
you
do
if
you've
got
a
legacy?
Router?
R
You
can
upgrade
all
of
that
kind
of
stuff.
So
I
think
the
target
is
for
people
who
so
isps
who
might
be
looking
at
how
they
would
what
they
would
do
to
upgrade
their
their
routers
with
with
with
encrypted
dns
what
they
would
put
forwarders
on
proxies
on
them,
for
example,
how
they
would
do
that
people
who
actually
want
to
put
forwarders
and
proxies
on
on
on
routers.
You
know
like
for
myself
I
work
for
I
work
for
powerdns.
R
R
The
question
is:
is
this
appropriate
for,
for
or
add
is
this?
Is
this
something
that
we
should
have
as
a
working
group
document?
I
mean
the
best
it's
informational,
but
is
this
something
we
want
to
work
on
as
a
a
group?
I
don't
think
it's
actually
requires
a
great
deal
of
work.
As
a
group,
I
I
know
eckers
was
saying
this.
Isn't
you
know
this
is
something
that
would
have
priority
as
a
working
group
document.
R
I
don't
think
it
would
need
a
lot
of
priority
as
a
group,
but
I'd
just
be
interested
if
folks
want
to
want
think
it's
it's
useful
for
us
to
adopt
as
a
group
or
not-
and
I
I
think
as
as
as
an
author
and
I
think,
I'm
speaking
on
behalf
of
my
co-authors.
We
we're
not
like
super
we're,
not
going
to
stand
here
and
like
fight.
You
know
we're
not
going
to
die
on
on
this
particular
hill,
but
I
said
we
found
it
useful
when
we
were
developing
it.
A
The
relevant
and
useful
pieces
import
it
into
that
new
draft
and
that
becomes
sort
of
where
this
all
ends
up.
It
doesn't
end
up
in
the
dnr
draft.
It
doesn't
end
up
in
this
draft.
Potentially
it
ends
up
in
that
broader
informational
document
which
we
do
have
in
the
charter.
So
that's
one
thought
that
you
know
we
were
thinking.
Obviously
that's
just
you
know
from
the
chairs
perspective.
A
G
G
That
to
me
underlines
the
the
usefulness
of
actually
documenting
this,
because
there
are
clearly
very
different
understandings
of
market
requirements
in
different
places.
So
writing
it
down
in
an
informational
document
and
just
using
that
as
a
helpful
reference
would
seem
to
be
to
serve
a
very
helpful
purpose.
Just
so
so
we're
all
clear
what
use
cases
we're
covering.
So
I
absolutely
think
this
should
be
adopted
as
an
informational
document
that
we
use
thanks.
K
Eric
right,
so
I
think
first
like
this
is
not,
as
you
say,
this
is
not
even
remotely
the
thing
is
in
the
charter.
The
charter
is
an
information
mechanism
for
detect
for
describes
mechanisms
for
clients
to
test
specific
network
environments,
which
is
actually
much
more
like
the
presentation
we
just
saw
prior
to
this.
So
so
perhaps
we
could
like
stuff
some
stuff
from
here
into
that
into
that
document,
but
like
until
someone
starts
that
document
that
this
is
not
like
that.
K
We
have
proposals
for
two
actual
things
and
we
should
up
or
down
on
those
proposals
and
on
their
own
merits,
and
this
document
is
perfectly
fine
cities.
Internet
draft
and
people
continue
to
update
it,
and
people
can
refer
to
as
they
please
and
people
can
be
informed
by
it,
but
which
does
not
need
to
be
any
kind
of
work.
R
I
I'm
really
interested
that
you
say
that
there's
this
there's
a
bunch
of
stuff
in
here
that
you
don't
agree
with,
because
I
I'm
like
astonished
by
that,
because
I
thought
it
was
like
completely
uncontroversial
because
it
mainly
just
sort
of
sits
there
and
lists
a
bunch
of
scenarios
of
how
you
can
use
add
protocols.
So-
and
I
haven't
seen
anything
for
you
on
the
list
about
like.
K
R
K
I
E
Yeah,
I
mean
largely,
I
agree
with
what
hecker
was
saying.
I
I
think
yeah
I
mean
the
content
here
isn't
bad,
but
it
also
doesn't
feel
like
it's
directly
deeply
tied
into
add,
and
a
lot
of
this
may
just
be
also
the
framing
of
how
it
reads
I
I
would
strongly
suggest
you
know,
since
we
have
an
informational
document
in
the
charter
that
needs
to
get
done
at
some
point,
and
we
have
a
bunch
of
authors
who
want
to
write
the
informational
text
to
help
people
understand
how
to
do
deployments.
E
R
Right
I
mean
I
I
mean
I
I
personally,
I
don't
not
speaking
for
my
co-authors
here,
but
I
personally
see
the
idea
of
it
being
a
part
of
a
larger
document
perfectly
reasonable.
I
I
don't
quite
get
the
point
about
it,
not
being
that
relevant
for
add
it
pretty
much
exclusively
covers.
Add
scenarios.
It
certainly
doesn't
cover
the
whole
of
led.
It
covers
a
specific
topic
about
add,
which
is
deployment.
Essentially,
you
have
add
and
home
networks
where
you've
got
cpes.
R
So
it's
a
kind
of
a
narrow
subset
of
add,
but
it
almost
exclusively
covers
add.
It
covers
the
discovery
of
of
encrypted
protocols
in
the
situation
where
you've
got
cps
and
home
networks,
which
is
by
the
way,
and
can
I
just
remind
everyone
the
most
common
way
that
people
around
the
world
access
the
internet,
because
I
think
that
often
gets
lost
here.
That
is
the
most
common
way
that
people
access
the
internet.
So
everything
we're
talking
about
here
if.
J
R
E
R
C
I
can
only
suggest,
because
the
content
seems
interesting
and
useful
to
aid
in
with
dns
up
or,
like
already
said,
include
it
into
a
la
the
larger
informational
document
deliverable
which
is
in
the
charter
and
the
milestone
of
add
but
like
it
is,
I'm
afraid
it
cannot
go
forward
adopt
it
cannot
be
adopted.
This
issue
can
continue,
obviously,
as
it's
relevant
to
a
dd.
A
Okay,
well,
thank
you,
neil
okay
and
and
we'll
continue
discussion
on
lists
and
and
and
among
the
chairs
and
we'll
I
guess
the
other
two
do
there
is
for
us
to
go.
Have
a
conversation,
at
least
on
the
chairs,
to
go,
have
a
conversation
with
maybe
diana's
laps
as
well.
Okay,
so
that
brings
us
to
the
end.
I'm
gonna
stop
sharing
that
so
everyone,
that's
it.