►
From YouTube: IETF106-ABCD-20191119-1330
Description
ABCD meeting session at IETF106
2019/11/19 1330
https://datatracker.ietf.org/meeting/106/proceedings/
B
B
A
Just
a
couple
of
quick
notes,
so
I'm
David
Lawrence-
this
is
Ben
Schwartz.
We
will
be
co-chairing
this
working
group
forming
buff,
but
I
also
wanted
to
thank
Tim
woods
in
ski
and
Joe
Lorenzo
hall.
For
being
our
note
takers
on
the
etherpad,
if
you'd
like
to
follow
along
to
make
any
Corrections
as
you
go,
that
will
also
be
helpful
and
Susanne
wolf
will
be
our
chapter
scribe.
Thank
you.
B
Those
began
to
get
significant
client
of
a
client
implementation
starting
last
year
in
2018.
So
here's
again
a
timeline
of
a
few
of
the
notable
client
implementations.
We
just
yesterday
had
a
very,
very
important
announcement
of
another
in
client
implementation
in
the
form
of
Microsoft
Windows.
So
this
list
is
now
even
more
incomplete.
B
Just
this
year
there
have
been
a
large
number
of
drafts
presented
to
the
various
working
groups
related
to
configuration
of
DNS
client,
so
I
certainly
won't
go
through
all
of
these
here,
but
all
of
these
are
drafts
introduced
this
year
that
that
affect
how
DNS
clients
are
configured
I
suspect.
There
are
more
that
I've
missed
here
and-
and
there
may
well
be
more
coming.
A
couple
of
these
will
be
presented
today.
Only
one
of
them,
I
believe,
is
currently
adopted
by
a
working
group.
A
One
thing
I'd
really
like
to
point
out
here
too,
is
though
a
lot
of
the
discussion
that's
been
going
on,
has
centered
around
DNS
over
HTTPS.
You
can
see
from
these
graphs
that
we
are
not
just
talking
about
DNS
over
HTTPS.
We
are
talking
about
the
evolving
DNS
landscape
and
it
is
not
restricted
by
any
stretch
of
the
imagination,
to
only
doe.
B
They're
also
been
several
drafts
that
are
less
focused
on
on
client
configuration
and
more
focused
on
systemic
issues
that
are
a
result
of
either
DNS
over
HTTP
deployment
or
other
interesting
changes
over
the
over
the
past
years,
in
the
way
that
DNS
is
deployed.
These
also,
this
has
been
a
set
of
drafts
that
have
come
up
this
year.
None
of
these
are
currently
adopted
in
a
working
group.
B
This
year
there
have
been
a
number
of
controversies
regarding
this
topic:
I'm
not
going
to
talk
through
these
I'm,
mostly
surfacing
these
example
headlines
from
the
press
as
a
way
to
remind
people
to
be
respectful
with
your
comments
during
this
session
that
this
is
a
very
charged
space
and
we'd
like
to
try
to
be
focused
and
and
productive
and
cordial,
and
the
purpose
of
our
conversation
today
is
to
discuss
forming
a
working
group.
This
is
a
working
group
forming
buff.
This
is
not
a
standards
development
meeting,
so
we
are
not.
B
B
B
Our
next
segment
is
10
minutes
for
presentation
and
discussion
of
a
proposal
by
Mozilla
I
want
to
emphasize
that
this
is
not
a
standards
development
meeting.
The
purpose
of
these
presentations
here
is
to
provide
us
with
some
examples
of
the
kinds
of
work
that
a
working
group
might
adopt
if
a
working
group
is
formed,
but
we
are
not
here
to
to
talk
through
a
full
discussion
of
these
of
any
standards
proposals
here.
Thank
you,
Andy
all.
D
D
So
so
Mozilla
has
taken
a
inclusive
position
in
terms
of
enabling
go
for
us
users
of
our
products.
Now
that
one
of
the
side
effects
well,
there's
a
couple
of
different
side
effects,
which
I'm
sure
a
lot
of
you
are
aware
of,
but
consequences
of
us
doing.
That
is
that
we
were
working
to
mitigate
those
as
much
as
possible.
So
one
of
the
things
that
application-based
dns
does
is
it
bypasses
any
sort
of
dns
based
parental
controls
that
are
present
on
the
network.
D
D
It's
not
it's
not
good
to
like
take
a
experimental
approach
and
like
try
to
trigger
this
for
actual
domains,
because
that
I
think
it's
kind
of
sub
obvious.
But
you
know
if
there's
logging
or
something
like
that.
These
are
these.
If
they're
explicit
domains,
then
we
don't
want
the
user
to
be
tagged
as
having
visited
them
when
they
actually
happened,
it's
their
it's
their
software.
D
So
we
tried
to
make
that
as
easy
as
possible
to
do,
but
the
the
the
essence
of
it
is
that
if
you
visit,
if,
if
the
browser
or
tries
to
resolve
the
domain-
and
it
gets
a
blocked
or
modified
results,
then
we
deduced
that
that
means
that
the
that
epic
DNS
policy
is
present
and
we
disabled
though
so
then
there
can
be.
You
can
have
multiple
community
drains.
So
obviously
you
don't
really
want
that
many,
because
it's
kind
of
a
pain
to
keep
track
of
them
and
make
sure
that
your
you're
heading
them
all.
D
D
So
in
as
we
roll
outs
making
those
the
defaults,
we
resolve
this
using
the
platform
DNS
and
if
there's
an
error
that
comes
back
or
if
there's
a
success
result,
but
it
doesn't
contain
an
A
or
quad
a
result.
Then
we
take
that
as
being
a
positive
indication.
The
Canary
domain
is
triggered
and
disabled
though
so
this
requires
some
work
on
the
server
side
or
in
the
network
side
to
enable
that
and
we
try
to
make
that
as
easy
as
possible.
D
So
if
you're
using
parental
control,
software,
then
presumably
there's
some
easy-to-use
UI
to
to
flag
domains,
and
we've
also
talked
to
some
parental
control,
software
providers
and
that's
something
that
they're
interested
in
and
adding
and
sometimes
just
like,
hey
we're
interested
in
doing
this
they're
like
oh,
we
already
blocked
it.
Okay,
so
if
you're
using
by
nine,
then
the
use
of
a
response
policy
zone
was
a
good
way
to
do
it,
and
we
also
heard
from
other
when
we
started
talking
about
this
and
blogging
about
this.
D
We
heard
from
some
people
using
other
DNS
servers
where
so
our
initial
approach
was
to
just
treat
an
X
domain
as
triggering
the
canary
and
we've
changed
that
so
that
any
error
results
and
any
success
result.
Besides
that
didn't
return
any
or
quad-a
was
to
make
some
kind
of
make
it
easier
for
whatever
your
software
is
to
to
engage
the
canary
domain.
D
A
lot
of
studies
are
leading
up
to
the
decision
to
roll
out
dough,
and
we
continue
to
do
that
and
looking
at
the
heuristics
and
the
the
percentages
of
users
that
that
are
disabling
dough
or
would
have
dough
disabled
if,
depending
on
the
very
various
heuristics
and
we're
seeing
we're
seeing
non
amounts,
non-trivial
amounts
of
of
triggering
the
canary
domain.
So
a
contrary
to
what
the
slide
says.
I
just
got
an
update
this
morning,
so
Firefox.
D
This
is
only
in
the
United
States,
but
dough
has
rolled
out
to
1%
of
the
users
and
is
going
to
be
rolling
out
to
another
1%
of
the
users.
Very
soon,
so
we're
continuing
to
monitor
all
the
heuristics
but
the
canary
domain
usage
via
lemon
tree,
and
one
thing
that
we're
concerned
about
is
that
it's
really
based
upon
what
the
end
network
operator
has
decided
that
they
want
to
do
rather
than
some
higher-level
network
operator,
so
we're
watching
for
abuse
and
making
making
sure
that
the
canary
domain
blocking
is,
at
the
end,
end
customer
level.
D
So
here's
a
couple
pre-emptive.
Why
didn't
use?
Why
didn't
you
wait
for
Standardization?
Well,
we
floated
a
extremely
flimsy
trial
balloon
about
six
months
ago,
but
we
really
needed
a
solution
quickly
and
we
especially
when
we
came
to
the
conclusion
that
we
are
going
to
require
people
to
add
something
or
change
their
configuration
in
the
network.
Some
way
that
we
make
that
as
easy
as
possible,
and
we
couldn't.
D
We
wanted
to
make
that
as
easy
and
as
fast
as
possible
and
avoid
any
sort
of
new
versions
or
anything
like
that
which
was
kind
of
some
of
the
initial
feedback
was
well.
Why
don't
you?
You
know?
There
was
kind
of
more
expansive,
maybe
better
solutions,
but
that
would
have
required
those
software
changes.
But
we
really
needed
something
pretty
quickly.
D
So
that
didn't
seem
to
be
quite
as
good
to
us
for
the
two
reasons
listed
there
that
that
was
kind
of
like
a
little
bit
I
mean
if
you
just
like.
If
you
have
a
parental
control
solution,
and
then
you
just
add
another
thing
to
the
block
list,
that's
like
a
very
natural
thing
to
do,
as
opposed
to
as
opposed
to
having
the
logic,
be
the
opposite
way,
and
the
other
piece
of
that
is
that
the
NX
domain
substitution
can
cause
trouble
with
that
approach
as
well.
D
So
that's
basically
it
we've
kind
of
done.
This
thing
on
our
own
seems
to
be
working,
but
it
is
kind
of
a
unilateral
thing
and
we'd
like
to
to
look
at
at
sanitization
and
seeing
if
they'd
be
useful
for
other
people
and
that
we
could
move
off
that
and
to
more
more
standard
things,
so
increased
adoption
would
be
good.
Fewer
canary
domains
will
be
good.
That
would
make
it
easier
for
applications.
E
E
You
thank
you
for
the
clarification.
The
other
point
I
wanted
says
for
possible
reserved
names.
The
IAB
is
made
under
DARPA
available
under
much
less
difficult
processes
than
reserved
TLT.
So
you
may
want
to
consider
whether
your
reserved
domain
actually
needs
to
be
a
TLD
to
do
its
function.
Oh
yeah.
G
G
So
you
can
see
directly
what
they
do,
unfortunately,
they're,
probably
not
really
suitable
for
Standardization,
because
they
involve
because
they're,
basically
looking
at
operating
system,
api's
looking
to
see
whether
someone
is
configuring
on
you
know
a
firefox
universe,
firefox
properties,
so
I'm
not
really
standardized
herbal,
though
I'm.
Certainly
there's
been
conversations
about
the
operating
system
is
exposing
some
API
that
indicated
that
the
user
had
made
conscious
choices
like
it
didn't
like
go
or
some
like
that.
Our
protocol
tools
were
on
and
I
said.
That's
that's
a
potential
area
for
Standardization
yeah.
A
H
My
atoms
from
ICANN
I'll
I'll
keep
it
short.
The
canary
domain
is
use
application
DNS
net.
It's
a
to
label
domain
in
binds
I
need
to
use.
As
an
operator
I
need
to
use
now
policy
zones.
It
would
be
much
simpler,
much
more
straightforward.
If
I
can
configure
a
zone,
let's
say
use
application,
DNS
dotnet
and
deny
the
existence
of
X
dot,
use
application.
Dns
dotnet.
H
In
order
to
deny
it
now,
I
either
need
to
use
added
policy
zone
which
is
kind
of
complex
or
I
need
to
locally
configure
the
net
zone
in
order
to
deny
use
application.
Dns
dotnet
so
may
I
suggest
to
make
that
domain
and
have
another
label
in
front
of
it.
If
that
makes
any
sense,
if,
if
you
need
more
clarification-
and
we
could
take
this
off
Mike,
okay.
I
Spill
new
horizon:
it's
a
little
of
a
problem
to
do
parental
control.
Okay,
I
have
another
problem
about
parental
control,
doing
it
to
BIA
DNS
at
the
first
place,
I
think
it's
not
full
I
get
to
parental
control
by
a
DNS
in
the
first
place,
yeah,
so
I'm,
not
quite
sure
at
all.
You
should
really
help
to
do
things.
The
wrong
way.
J
K
K
The
ITF
has
standardized
ipv4
only
dot
our
pub
and
it's
kind
of
similar
to
this,
where
by
spec
it
exists
to
only
return
to
a
records
and
nothing
else
and
operators
override
those
results
to
share
with
clients
that
there
is
a
dns64
and
an
at
six
four
on
the
network.
So
we
have
precedent
for
specifically
using
dns
as
a
way
to
say:
hey
you
override
this
you
by
overriding
this,
you
get
the
functionality
you
want,
so
this
seems
very
similar.
It
makes
sense
to
me
yeah.
A
L
While
he's
walking
go
okay,
all
right,
Iranian
run
from
Google
Android.
One
just
comment:
I
found
a
little
confusing.
Is
that
so
the
whole
presentation
focuses
on
basically
the
usage
for
permits
on
control,
but
I
don't
see
anything
in
particular
that
I
mean.
For
me,
the
parents
on
culture
is
just
like
one
subset
of
censorship.
Basically
and
I
don't
see
anything
in
here
that
you
know
it's
specific
to
pirate
or
control
compared
to
like
in
general,
whatever
you
could
use
for
censorship
in
general,
and
so
considering
that
I
think
you
know
in
further
communication.
L
D
M
N
Right,
hello,
everyone,
I'm
Tommy
Pali
from
Apple,
so
in
light
of
the
fact
that
this
is,
you
know,
information
over
you
guys,
there's
you
know
two
sides
of
this
one
is
to
share
some
of
the
work
that
we
are
doing
at
Apple
as
a
kind
of
an
operating
system-level
thing.
We
have
a
lot
of
experience
of
people
trying
to
do
dough
in
the
browser
right
now.
You
know
we
have
people
looking
at
how
to
do
it
as
an
operating
system
service
in
the
system.
N
Resolver
we've
done
a
lot
of
good
feedback
already
on
this,
also
from
the
teams
at
Android,
as
well
as
the
Microsoft
Windows
DNS
teams.
So
part
of
us
is
to
share
this
information,
but
then,
hopefully,
also
be
kind
of
the
questions.
We're
trying
to
address
in
this
as
we're
working
on
design
architecture
are
some
of
the
things
that
if
ABCD
is
a
group,
it
would
likely
come
up
and
so
right
now.
These
are
a
couple
documents
that
we
have
put
forward
in
deprived
and
so
we'll
be
presenting
those
later
in
the
week.
N
If
you
think
that
there
was
make
sense
in
deprived,
then
that
maybe
influence
kind
of
like
where
we
see
this
particular
group
going
alright.
So
we
have
this
overall
thing,
we're
calling
it
adaptive
DNS
privacy.
So
what
does
it
mean?
So
here
we
have
the
normal
status
quo,
DNS
setup,
and
when
we
look
at
the
different
parties
involved,
we
have
our
client
device.
It's
talking
to
some
local
resolver
generally
at
least
a
locally
provisioned
resolver
using
standard
DNS
over
UDP
port
53
and
then
there's
some
actual
origin
server
that
I'm
connecting
to
example
comm.
N
So
what
we've
seen
with
a
lot
of
the
doe
deployments
so
far
is
something
that's
a
little
bit
more
like
this.
We
are,
you
know,
potentially
skipping,
that
first
step
and
we
have
some
other
external
public
for
cursive
Doe
that
we're
using
instead
to
replace
that
role
so
that
achieves
some
goals.
I
think
people
are
doing
this
because
of
privacy,
but
it
also
has
other
concerns
that
have
been
clearly
brought
up
on
the
ad
D
list
and
others.
N
So
when
I
look
at
this
from
the
point
of
view
of
the
operating
system,
there's
a
couple
of
different
questions
that
come
to
mind
and
I
want
to
go
through
those.
What
we're
thinking
here
as
some
of
the
prompts
for
this
group
so
first,
how
do
we
as
a
client
discover
the
different
encrypted
resolvers
that
are
available,
not
necessarily
when
to
use
them
with
just
their
existence?
Next,
how
do
we
understand
the
local
policy
of
the
network?
N
That's
kind
of
like
the
canario
domain
that
we
just
saw
and
then
kind
of
the
big
one
if
we're
doing
this
at
a
system
level,
and
not
just
in
a
browser
like
how
do
we
know
as
a
client?
What
are
the
right
things
to
use
at
the
right
times,
because
there
can
be
some
very
complex
scenarios
going
on
so
I'm
gonna
go
through
all
three
of
these,
and
that
will
be
the
talk
so
first,
how
do
we
discover
different
resolvers?
N
So
there's
a
couple
of
different
options:
I
think
what
we're
seeing
today
oftentimes
we
have
some
hard-coded
lists
of
things
that
we've
white
listed
and
audited
in
that's
one
approach.
Certainly,
you
can
also
there
have
been
proposals
to
like
bootstrapping
off
of
an
HTTP
connection.
I'm
you
almost
like
an
alt
service
type
thing
that
you
connect.
You
learn
that
this
thing
supports
doe
and
then
in
the
future
you
start
using
doe
from
a
privacy
perspective.
That's
not
necessarily
great,
because
it's
very
opportunistic.
It's
a
little
bit
lazy
on
that
regard.
N
So
what
we're
proposing
here
this
is
just
one
option
is
actually
using
records
in
the
DNS.
Ideally
DNS
sex
signed
records
that
can
prove
some
official
designation
of
what
a
zone
wants
to
use
as
its
associated
trust
the
resolver.
The
point
of
this
is
saying
that
if
I'm
going
to
a
Google
domain,
then
it's
probably
appropriate
to
use
a
Google
resolver
it'll
have
accurate
results.
It
will
allow
us
to
do
connection
coalescing
and
it
actually
kind
of
makes
this.
N
N
It
allows
us
to
do
multiplexing
and
if
we
are
indeed
doing,
resolution
of
Google
names
to
Google
servers,
there's
a
much
higher
chance
that
we're
going
to
end
up
seeing
coalescing
and
getting
benefit
of
multiplexing.
It
also
allows
us
to
get
more
of
a
direct
transition
to
quick.
We
can
go
from
HTTP
to
to
HTTP
3
without
redefining
a
protocol
mapping.
It
also
allows
proxying
requests
which
I'll
get
into
a
bit
later,
so
essentially
the
world
with
a
designated
DNS
service,
a
designated
dose
over
kind
of
looks
like
this.
N
So
then
we
also
want
to
look
at
how
do
we
handle
local
policy
that's
being
advertised?
So
again
we
have
options
like
doing
canary
domains.
This
is
I,
think
a
really
good
first
step,
although
maybe
it's
not
the
long
term
architecture
that
we
want.
You
can
also
put
things
in
DHCP
or
RA
options.
What
we're
doing
right
here
is
using
something
that
we
are
it's
in
tension
off
of
off
of
Ras
called
provisioning
domains.
It
allows
us
to
fetch
a
fairly
large
blob.
N
That's
fetched
off
of
a
HTTPS
connection
is
a
JSON
blob,
that's
a
bit
flexible
here,
and
we
imagine
that
this
type
of
information
can
be
used
to
indicate
walled
garden
status,
captive
status
as
well
as
filtering
rules,
and
so
it's
essentially,
how
do
I
use
this
network.
What
are
the
things
that
are
available,
and
one
of
the
important
things
here
also
is
the
even
in
cases
in
which
I'm
allowed
to
use
DOE
to
public
services.
N
We
may
want
to
break
out
certain
services
locally,
so
you
know
I
have
Comcast
as
my
ISP
and
if
I
have
local
Xfinity
streaming
services
that
are
very
well
optimized
it'd
be
great
to
do
my
dns
and
ideally
do--,
to
Comcast
over
the
local
network.
The
same
goes
for
enterprise
network
scenarios,
in
which
we
need
to
know
kind
of
like
the
split
DNS
world
here.
So
we
need
to
be
very
cognizant
of
split
DNS
as
we
are
doing
this
solution
for
local
networks.
N
N
We,
as
we
had
some
discussions
with
various
ISPs
and
I,
think
we're
gonna
have
scenarios
in
which
we
have
some
required
filtering
in
which
it's
like,
oh
let's,
say,
I,
have
a
school
environment.
This
really
needs
to
be
locked
down
and
essentially
indicating
ahead
of
time.
We
will
block
you
if
you
try
to
evade
this
and,
like
that's
going
to
be
bad
news,
but
you
can
also
have
things
that
are
more
opt-in
services
of
saying
this
is
a
parental
controls.
N
We
also
want
to
make
sure
that
we
do
highly
respect
the
services
that
are
local
that
are
either
on
our
home
network.
Local
network
are
things
that
we
know
are
locally
provisioned
and
we
can
have
proof
that
these
are
things
that
the
local
network
is
truly
authoritative,
for
we
also
want
to
then
kind
of
use
these
provable
designations
for
other
public
services.
N
N
One
question
that
can
come
up
on
all
of
this
is:
how
do
we
bootstrap
this
world?
If
we,
you
know
so
there
are
different
ways
of
setting
up
these
designations.
If
we
do
trust
the
local
network-
and
we
aren't
too
worried
about
things,
then
you
know
I
connect
to
Google
I.
Do
a
resolution
for
Google
the
first
time
I
say:
Oh
Google
has
a
public
doser
that
I
can
use
I
bootstrap
off
of
that
if
I,
don't
trust
the
local
network.
N
That's
what
we
have
this
scenario
for
oblivious
Doe
going
on
and
you
can
find
out
more
about
that
at
deprive
anyway.
So
that's
it!
We
do
have
some
drafts.
They
are
in
deprive
you
can
file
issues
read
about
them,
make
full
requests
at
the
github
and
we
also
have
some
sample
code.
That's
available.
All.
G
G
So
what
happens
if
say,
I
have
a
domain
which
is
served
by
you
know
to
CDN
store,
call
a
and
B
and
on
and
a
decide,
and
so
when
I
content
and
a
decides
to
publish
a
record
saying
that
it
should
be
the
designated
server
for
a
badge
domain.
What
is
the
impact
of
that
on?
Doesn't
that
effectively?
Pin
me
to
a
more
or
less
indefinitely
right,
so.
N
This
this
is
one
of
the
kind
of
issues,
and
so,
if
we're
looking
at
just
as
a
quick
answer,
I
think
there's
two
general
approaches.
We
can
take
what
we're
using
to
communicate.
This
designation
is
actually
the
same
record
that
we're
going
to
be
using
for
yes
and
I,
and
so
you
could
have
just
two
designations
and
presumably,
if
I'm
doing
more
resolutions
through
A's
Doh
server,
it
should
also
not
hide
the
fact
that
there
is
a
destination
for
B
as
well
and
there's.
N
G
P
Work:
komari
Google:
can
you
go
back
to
14,
it's
possible
I'm,
asking
the
same
question
as
acre,
but
I'm
not
sure?
Yes,
so,
for
the
designated
doe
server
can
I
also
say
that
the
google.com
servers
should
be
able
to
resolve
YouTube.
Yes,
can
I
also
say
that
they
should
be
able
to
resolve
Apple
right.
N
This
is
where
you
know
the
notion
of
okay
we're
to
get
the
authority
from
so
what
we
are
saying
this
document
is
these
records
that
give
these
designations
should
be
DNS,
X
science,
so
that
we
have
proof
that
the
person
who
does
have
authority
over
that
name
is
truly
indicating
this
relationship,
not
everyone,
loves,
DNS,
SEC,
but
I
think
it
points
to
that.
You
need
some
way
to
prove
this
relationship
that
you
can't
just
claim
authority
over
something
else
right,
that's
general
for
any
solution,
I
think
yeah.
K
So
first
I
want
to
thank
you.
I
think
this
is
very
interesting
and
I
put.
This
will
be
very,
very
useful.
One
of
my
concerns,
at
least
with
some
of
the
deployment
models,
has
been
that
you
end
up
with
two
months
centralization
and
you're
able
to
provide.
You
know
multiple
parties
that
provide
different
types
of
services,
so
so
that
that's
a
big
improvement,
so
so
that's
good
I
did
have
one
more
technical
question
about.
K
K
N
Fact
that
a
doe
server
could
resolve
multiple
many
things
like
a
lot
of
these
could
be,
and
if
I
talk
to
cloud
fire
for
something
or
quad
8,
it
can
resolve
the
whole
internet.
The
question
is:
when
should
I
do
it
and
it
gets
into
the
notion
of
do
I
have
a
strong
designation,
an
indication
from
the
zone
owner
some
signed
record
that
says
yes,
this
is
the
thing
you
should
be
used
for
this
period
of
time,
so
I
think
it's
gets
into
the
same
conversation.
Q
I'll
come
on
I
loved
in
a
sec,
so
that's
the
part
of
the
draft
I
certainly
approve
of
and
I
mean
there's
a
more
I
think
probably
technical
discussion
on
on
on
Friday.
Yes,
so
the
one
thing
that
concerns
me
a
bit
I
mean
it
is
a
fairly
complex
picture.
How
are
you
going
to
back
this
or
how
can
we
make
sure
that
it's
kind
of
bulletproof
so
that
my
ISP
doesn't
get
a
call
for
me
because
doesn't
work
right.
N
N
At
that
point
it
would
know
the
first
time
I
talk
into
a
given
zone
right
like
the
first
time,
I
talk,
resolve,
Google
and
then
at
that
point
Google
becomes
encrypted
over
dough.
So
you
know,
hopefully
it
would
be
able
to
debug
kind
of
like
those
initial
things
and
then
essentially
any
name
that
I
see
off
of
Google.
After
that
point,
it's
kind
of
the
Google
servers
fault.
N
A
A
R
The
interesting
things
well,
when
I've
nailed
down
rebellious
IC
I,
can
you
go
back
114
it's
on
one
yeah,
so
there's
at
least
one
box
missing
on
that
one,
which
is
names
that
are
not
DNS
names.
For
example,
you
saw
from
NS
switch
Kampf
so
yet
C
localhost
other
naming
systems
that
are
not
DNS,
yep
stuff,
that
the
operating
system
will
do
for
free
if
you're
using
gaturro
phone
anymore
similar.
Yes,
it's
a
great
white.
Finally,.
F
Brian
Dixon
Go
Daddy
go
forward
a
slide
or
two
yeah,
so
what
I'm
wondering
about
is
from
a
scalability
and
caching
perspective,
whether
having
the
client
flipped
from
one
to
another
to
another
resolver,
whether
it
might
be
worth
considering
having
the
fourth,
the
first
one
be
a
forwarder
and
can
take
the
advantage
of
the
scalability
of
client
queries.
Anybody
who's
connected
to
the
closest
cache
to
them.
Forwarding
is
going
to
benefit
if
other
people
are
making
the
same
kind
of
queries.
Plus
it's
gonna
have
more
local
benefit.
Yeah.
N
That's
fair,
you
know
there
is
definitely
the
privacy
aspect
in
which
we
don't
necessarily
want
to
put
all
of
our
names
through
something
that
can
see
things
that
we
don't
trust.
Also
one
of
the
benefits
of
going
to
things
that
are
not
necessarily
authorities,
but
something
that
are
designated
is
that
they
should
have
really
high
hit
rates
right
like
so.
If
I
go
to,
you
know
the
Google
Doh
server
and
everyone
else
is
going
to
that
particular
server
for
those
names,
or
at
least
their
local
top
of
it.
N
B
A
Take
one
interruption
here,
just
to
kind
of
for
those
of
you
not
familiar
with
the
process
of
a
working
group
forming
ball.
What
we're
looking
here
is
trying
to
identify
whether
there
are
concrete
work
items
that
we
could
adopt
in
it.
That
makes
sense
to
have
their
own
working
group
for
us
to
focus
on
being
able
to
work
toward
actual
deliverables
and
of
note
a
couple
of
things
is.
The
final
decision,
of
course,
is
not
really
up
to
this
room.
A
It
is
ultimately
up
to
the
isg,
but
whatever
discussion,
while
we
are
presenting
a
draft
possibility
for
the
Charter,
we
are
able
we
are
discussing
that
here
and
able
to
modify
it
as
seems
appropriate.
We
will
be
trying
to
drill
down
on
some
of
these
stickier
questions
there
and
also
of
note
so
that
the
final
determination
of
you
know
like
what
we
would
like
to
advance
to
the
isg
to
make
a
final
decision
about
chartering.
A
working
group
will,
of
course,
take
as
part
of
normal
idea.
A
Processes
will
take
place
online
and
also
important
to
note,
although
Ben
and
I
were
co-chairs
of
DOE
and
in
our
co-chairs
of
this
both
we
are
not
necessarily
the
co-chairs
of
your
new
working
group.
That
is
a
separate
matter
to
be
determined.
So
if
that
kind
of
influences
your
decision
about
which
way
you
think
things
should
go.
That's
a
separate
issue
to
the
chartering
discussion.
B
Thanks
David,
so
there
was
a
when
this.
When
this
working
group
forming
Boff
was
announced,
it
was
announced
with
a
draft
charter
in
order
to
solicit
feedback.
That
feedback
largely
came
on
the
a
DD
mailing
list.
There
was
quite
a
bit
of
discussion
of
that
draft
of
the
Charter.
Based
on
that
feedback,
we
attempted
to
produce
an
updated
Charter
proposal
that
reflected
as
much
as
that
feedback,
as
as
we
could
manage
and
I
wanted
to
highlight
some
of
the
differences
from
that
original
Charter
proposal.
B
There's
also
since
been
extensive
discussion
on
the
list
of
this
latest
draft
of
the
Charter
proposal
and
we'll
have
some
more
discussion
of
that
today.
So
the
the
first
set
of
notable
changes
are
in
what
the
original
draft
called
initial
areas
of
focus.
We've
clearly
expanded
the
the
detailing
of
what
these
areas
are
to
to
try
to
clarify
precisely
what
it
is
that
might
be
of
interest
to
this
working
group,
and
these
are
intended
to
be
essentially
technical
and
less
controversial.
B
B
So
if
you,
basically,
if
there's
substantial
disagreement
within
the
working
group,
those
disagreements
have
to
be
resolved
outside
the
working
group,
not
during
working
group
time
in
order
to
allow
the
working
group
to
continue
to
make
progress
on
less
controversial
topics.
So
that
is
the
current
proposed
charter
text.
I'm
also
going
to
pull
up
here,
the
full,
the
full
current
draft
charter
and.
B
The
the
rest
of
this
time
is
open
discussion,
but,
as
the
the
first
topic
I
would
encourage
you
to
consider
especially
the
question
of
these
controversial
topics,
which
has
been
much
debated
on
the
mailing
list.
It
seems
to
me
that
there
are
essentially
three
major
major
considerations
here.
Whether
we
should
essentially
keep
the
text
more
or
less
as
it
is
whether
we
should
render
these
topics,
as
included
in
the
working
group
scope
without
any
special
conditions
or
whether
we
should
exclude
them
entirely
and.
A
One
last
thing
that
I'd
like
to
request
as
you're,
making
your
microphone
comments.
Please
also
offer
just
a
general
statement
about
whether
you
support
the
formation
of
a
working
group
at
all
and
then
on
that
point
that
been
brought
up.
What
your
particular
feeling
is
as
far
as
resolving
or
dealing
with
these
controversial
areas.
S
B
My
my
interpretation
of
that
line
is
to
say
that
essentially,
in
the
course
of
the
working
group,
if
somebody
comes
up
to
the
microphone
and
says
no
we're
not
gonna
do
like
I,
don't
want
to
do
it
this
way,
then
then,
the
the
further
argument
between
proponents
and
opponents
on
those
topics
has
to
happen
outside
the
working
group
and
the
working
group
can
move
on
to
other
topics.
I.
S
T
Gentleman,
kava
random
network
copywriter
I'm
excited
to
see
the
opinion
because
I'm
a
bit
scared
about
potential
implications
for
networks,
I'm
Iranian,
so
it
might
sounds
like
a
neat
picking,
but
I
would
love
to
see
dns64
being
explicitly
mentioned
as
a
sync.
We
need
to
think
about
because
I
suspect
some
of
that
behavior
might
have
unexpected
implications
for
v6.
Only
networks
is
dns64.
K
A
A
Up
and
DNS
off
itself
is
now
three
working
group
chairs
and
very
frequently
two
sessions,
every
IETF
there's
a
lot
going
on
in
DNS
up
that
and
a
lot
of
people
that
are
interested
in
these
other
areas
are
not
interested
in
participating
in
the
full
breadth
of
DNS
up,
and
so
the
you
will
also
have
noticed
in
the
draft
charter
that
there's
a
paragraph
at
the
end
that
says
you
know
we
will
closely
be
working.
This
working
group
would
be
closely
working
with
both
deprive
and
dns
off
in
doing
its
business
and
I.
A
Personally
speaking
without
a
hat,
but
just
my
own
personal
expectation
would
be
that
the
chairs
of
each
of
the
working
groups
would
be
working
closely
to
identify
which
particular
working
group
would
be
most
suited
to
the
type
of
work.
That's
being
done.
Some
of
these
things,
I,
agree,
I
think
are
more
specifically
DNS
up,
but
quite
a
few
of
them.
A
K
Thank
you
does
clarify
things,
but
I'm
not
true.
So
maybe
someone
can
tell
me
if
there's
president
here
but
saying
that
another
working
group
is
Genda
is
too
full
doesn't
sound
like
a
good
reason
to
form
something
else,
and
I'm
not
saying
we
shouldn't
form
this,
like
I'm
just
saying,
a
lot
of
these
items
like
dns
should
be
debuggable,
like
that's
an
operational
issue
of
the
dns,
and
we
have
a
working
group
for
that.
So
I
think
this
needs
to
be
narrowed.
A
lot.
K
K
If
you
don't
focus
too
much
on
where
the
work
actually
ends
up,
whether
it's
in
this
working
group
or
some
other
working
group,
that's
a
management
issue
that
you
guys
in
the
IES
table
handle
somehow,
but
we
should
focus
on
which
things
actually
we
we
believe
are
needed
and
useful,
and
and
should
be
done
it
now
or
not
yet
done.
Obviously,
if
there
already
are
being
addressed
somewhere
else,
then
that
we
shouldn't
list
it
here.
So
that's
one
comment.
K
The
other
comment
is
is
on
your
other
list
and,
while
I,
you
know
basically
agree
with
you
know
much
of
what
is
said
here.
I
do
take
exception
with
one
of
these
items,
and
that
is
the
privacy
and
pervasive
surveillance
item
and
I
think
it's
our
job
to
worry
about
things
such
as
the
end
user,
privacy
and
pervasive
surveillance,
and
when
we
are
working
on
these
topics
like
we're,
some
of
the
proposed
work
items
include
like
these
architectures.
K
That
would
do
you
know
some
kind
of
distribution
and
to
not
be
able
to
analyze
what
the
impacts
of
those
architectures
or
you
know.
If
you
don't
do
those
architecture,
it
is.
That
seems
like
a
major,
Mis
and
also
I,
believe
it's
so,
according
to
our
PCPs
that
we
have
to
address
some
of
these
issues
if
we
work
on
particular
pieces
of
technology.
Thank.
B
A
Our
note-taker
is
helpfully
noted
that
this
is
a
danger
danger
danger
list
right
on
this
particular
like
the
ITF,
as
I've
mentioned
in
the
past.
One
of
the
challenges
is
that
we
very
frequently
like
to
say
that
we
don't
do
policy,
but
it's
also
very
clear
that
a
lot
of
technology
we
develop
greece's
policies,
kids,
one
direction
or
the
other,
and
in
this
particular
area
at
least
the
ITF
came
out
with
a
very
clear
statement
on
how
it
perceives
pervasive
monitoring
and
and
therefore
the
design
of
protocols
are
enhancing.
A
Our
our
defenses
against
pervasive
surveillance
also
have
this
additional
problem
of
blocking
benign
surveillance
and
Danger
Danger
Danger,
just
even
using
those
terms
together.
I
realize
is
a
giant
minefield
but
I
that
the
intent
of
this
bullet
point
was
to
say
that
arguing
that
point
back
and
forth
is
not
going
to
be
a
productive
discussion
in
the
working.
B
O
We
seem
to
be
I,
mean
dialogue
where
people
make
comments,
and
then
you
respond
as
if
you
are
proponents
for
the
responses
and
that's
an
unusual
model,
and
the
most
important
question
in
front
of
us
is
whether
this
buff
has
a
charter
in
front
of
us,
and
that
should
be
used
is
the
basis
for
a
new
working
group.
I,
don't
believe
is
so
for
a
bunch
of
reasons.
It's
one.
The
Charter
lacks
specificity.
In
fact,
it
actually
has
almost.
It
has
no
deliverables
in
the
Charter
at
all,
but
almost
everything
is
in
scope.
O
We
need
consensus
that
any
deliverables
have
a
high
chance
of
success,
but
there's
no
clarity
and
what
those
deliver
both
might
be.
The
Charter
relies
on
a
number
of
new
concepts
that
are
not
really
normal,
IETF
consensus
processes,
the
notion
of
full
consensus
and
the
more
novel
topic
that
some
things
are
relevant,
but
the
group
shall
not
try
and
resolve
their
disagreement
on
them.
This
has
a
low
probability.
O
I
would
suggest
if
working
at
all-
and
you
know
mostly
most
importantly-
this
is
not
a
matter
of
just
refining
the
Charter
I-
really
think
this
is
inherent
in
the
nature
of
what
we're
discussing
here.
This
is
politics
that
is
not
well
suited
to
our
consensus
process.
So
RFC
54:34
has
some
considerations
for
a
successful
Baath.
We
might
look
at
those
I
miss
the
scope
for
the
problem
well
understood,
and
that
is
people
generally
understand
what
the
working
group
will
work
on.
I
suggest.
You
know
there
are
no
deliverables,
so
that's
not
really
very
clear.
O
There's
an
agreement
that
the
specific
set
of
deliverables
are
the
right
set.
Perhaps
the
null
set
is
the
right
set
of
model
I'll
go
that
far
I'm
is
it
believed
that
the
working
group
has
a
reasonable
probability
of
having
success
ie
in
completing
the
deliverables
in
the
Charter
in
a
timely
fashion?
Well,
there
are
no
deliverables,
so
I
guess
we
kind
of
got
that.
U
O
G
Erica
squirrel
longtime
listener,
first-time
caller
yeah
I
mean
Patrick.
That
was,
you
made
me
almost
irrelevant
almost
so,
let's
take
a
step
back.
Remember
what
happened
the
history
of
what's
happened
here,
which
is
the
ITF
published
specification
published.
Oh,
there
was
consent,
specification
mission
accomplished,
and
then
there
was
discussion
of
deployment
of
the
specification
vendors
made
a
bunch
of
choice,
decisions
about
different
vendors
made
different
decisions
and
their
announcements.
G
A
bunch
of
people
were
sad
about
those
decisions
and
we've
now
spent
a
basically
the
past
year,
going
back
and
forth
between
the
people
with
other
decisions
were
good.
The
people
for
the
decisions
were
bad
and
now
that's
a
perfectly
healthy
kind
of
debate.
I
think
we
have
not
advanced
like
one
nanometer
in
in
actually
getting
consensus
from
like
the
positions
we
started
run.
So
that's
not
been
super
helpful,
and
so
the
question
now
is
what,
as
honnest
Ruffini
pointed
out
in
montreal,
we
publish
technical
specifications.
G
That's
the
purpose
of
this
enterprise
we're
all
collectively
in,
and
so
we
had
asked
what
technical
specifications
can
we
publish
that
are
the
output
of
this
work,
and
so
the
some
of
the
things
on
your
like
group.
One
list
you
know
of
things
we
might
work
on
seemed
like
interesting
ideas,
I'm
on
particular
interested
in
number
two
there's
way
too
many
there.
We
ought
to
start
small
and
make
some
progress
on
one
of
them.
G
The
second
things
all
the
things
you
do
about
like
at
oxford
debating
society,
which
we
are
not
so
I
like
it
is
not
a
good
use
of
our
time
to
attempt
to
reach
resolution
on
things
which
you
already
know.
We
have
violent
disagreement
upon
and
we
do
have
common
ground.
So
I
think
that
while
I
appreciate
your
full
consensus,
suggestion
I
think
striking
those
entirely
give
you
much
better,
and
if
people
wish
to
discuss
those
in
some
other
forum,
perhaps
you
could
find
out
what
that
way
to
do
that.
F
V
A
working
group
in
in
my
experience,
working
groups
set
up
in
this
fashion
are,
are
very
likely
to
fail
you're
building
conflict
into
the
charter.
It's
much
better
to
have
something
small
and
distinct
that
you
know
you
can
get
agreement
on
that.
We
want
to
do
this
and
move
that
forward
and,
and
that,
in
my
experience,
is
a
much
more
successful
model
for
a
charter.
I
acknowledge
we
need
to
continue
discussing
this.
V
We
need
a
forum
for
that
discussion
that
doesn't
have
to
be
a
working
group,
though,
and
what
I'm
concerned
about
is
is
that
there
are
some
interesting
and
I
think
useful
things
in
this
space
I,
especially
like
Tommy's
proposal
that
if
they
were
adopted
by
working
group
like
this,
they
would
be
put
at
risk
by
the
circus
that
would
surround
it.
So
I
strongly
against
this
charter
or
anything
like
it.
G
Hi
Brian
Trammell
I,
actually
kind
of
like
the
Charter
on
the
left
more
than
the
Charter
on
the
right
like
this.
This
this
looks
like
I
mean
people
often
say
the
IETF
process
is
terrible
because
it
leads
to
protocols
designed
by
committee.
This
reads
like
a
charter
designed
by
committee,
because
it
actually
was
I,
think
that
is
a
it's.
It's
useful
to
basically
have
had
the
discussion
to
say:
let's
expand
the
list
of
things
that
were
willing
to
consider
because
I
think
there's
a
lot
of
work.
That
needs
to
be
done
in
this
space.
G
I'll
say
when
I
was
looking
at
the
the
two
sort
of
introductory
presentations
here.
I
was
like,
oh
that
that
all
looks
like
that.
Those
look
like
interesting,
small,
well
scope,
questions
that
would
work
perfectly
in
a
working
group
and
I
can
see
the
deliverable-
and
this
sounds
great
and
maybe
saying
like
going
over
and
saying
so.
Both
of
them
had
to
do
with
the
resolver
discovery
and
sort
of
the
generalized.
How
do
I
figure
out
what
my
environment
looks
like
for
resolution,
which
is
what's
kind
of
missing
from
from
doe
right
like
so?
G
That's.
That's
where
the
technical
friction
is
here
and
I
would
say
going
back
looking
at
all
of
the
of
the
input
we've
gotten
from
the
community
on
sort
of
the
what
needs
to
be
in
the
latest
draft
and
saying:
let's
pick
one
pick
one
and
then
and
then
explicitly
in
the
Charter
say
closer
recharter
right.
It's
like
doing
these
in
a
more
serial
way
will
be
much
more
productive.
G
You
can
actually
write
down
deliverables
which
makes
it
easy
to
determine
whether
write
deliverables
and
it
fixes
the
problem
that
people
came
in
the
door
with
the
beginning,
Great
Lakes.
So
there
was
all
the
discovery.
Thing
does
actually
seem
like
it
needs
work
and
it
eats
work
quicker.
Then
we're
gonna
get
to
if
we
argue
over.
The
exact
scope
of
the
thing
on
the
right.
G
I
have
opinions
about
the
next
slide,
but
I
don't
want
you
to
put
the
next
slide
up
in
order
to
talk
about
them,
because
it's
kind
of
like
red
meat
and
red
flags
and
so
I
would
say
entering
a
working
group
based
on
a
much
on
a
cut-down
version
of
this
Charter.
That
looks
more
like
the
one
before
the
discussion
makes
sense,
and
you
really
need
to.
We
need
to
have
like
it's.
Gonna
require
discipline
chairs
right,
like
it's,
not
gonna,
be
a
thing.
G
It's
like
hey
we're,
gonna
talk
about
these
things,
but
only
like
in
full
consensus
is
actually
gonna,
be
your
a
list
of
things,
we're
not
gonna
or
talk
talk
about
outside
of
the
scope
of
the
very
specific
technical
decisions
that
we're
making
on
deliverables.
So
with
that
caveat,
I
think
that
that
this
working
group
really
needs
to
exist
not
with
this
charter,
but
I
would
hope
that
we
could
iterate
on
this
on
the
list
and
do
like
spend
something
up
before
Vancouver.
X
Jim
reads:
I'm,
supportive
of
creating
about
group
something
supposed
to
the
slides
and
I'm
totally
happy
with
the
chapter.
That's
before
the
draft
updated
chatter.
This
been
in
place
the
moment
I.
Think
the
choice
of
these
mods
for
consensus
is
perhaps
me
what
button
forts
it,
because
that's
creatively
stifling
fusion
misunderstandings
and
that's
maybe
something
needs
to
be
tweaked.
Yes,
some
of
the
deliverables
or
maybe
could
be
fleshed
out
a
little
bit
more,
but
I
have
to
disagree
with
from
the
points
that
mark
was
meeting
or
about
the
potential.
X
X
Then
things
should
keep
themselves
pretty
much
in
line.
Yes,
as
a
theater
grist
that
things
could
maybe
go
wrong,
but
before
you've
got
the
right,
leadership
and
I
have
to
give
common
sense.
This
shouldn't
happen,
maybe
I'm
just
being
too
optimistic
about
that.
But
I
think
we
can
solve
these
problems
if
they
too
much
difficulty
and
get
down
to
the
job
of
solving
the
real
issues
such
as
the
ones
that
we've
been
talked
about
before
do
the
two
presentations
before
going
to
the
Charter
discussion.
Thank
you.
F
Brian
Dixon
GoDaddy,
there's
one
thing
on
I
think
the
next
slide
op
that
forward
just
for
a
second
from
the
right
hand,
side.
The
first
bullet
I,
think
that
bullet
point
might
better
be
handled
through
making
that
a
required
element
of
any
working
group
draft
as
a
section
the
same
as
currently
there's
a
security
requirements,
requirements
for
a
security
section,
given
the
nature
and
scope
of
the
the
working
group,
if
it
forms
I,
think
that
would
be
sufficient
for
addressing
that
and
please
get
rid
of
that
slide.
Go
back
one!
F
Sorry
on
the
issue
of
some
of
the
the
consensus,
specifically
the
single
person,
saying
no,
that's
a
huge
red
flag
for
me
from
a
process
this.
This
flies
back
to
my
experience
over
the
last
twenty
years
in
the
ITF,
where
there's
been
a
lot
of
bad
behavior
that
is
under
the
covers
or
behind
the
scenes
that
has
been
alluded
to
by
various
different
people,
and
it's
left
a
lot
of
bad
tastes
and
a
lot
of
people's
mouths.
This
is
exactly
the
wrong
approach
to
take.
F
You
know
nominate
and
second,
we
really
want
to
avoid
blocking
valid
and
valuable
contributions
and
discussions,
even
if
they
are
contentious
general
rough
consensus
is
not
the
same
as
unanimity
and
I
think
that
it's
extremely
important
in
some
of
the
issues
and
thirdly,
from
a
process
perspective
I,
think
something
having
been
previously
established
in
some
working
groups
somewhere
should
not
preempt
revisiting
some
of
those
discussions.
There's
a
specific
to
one
particular
area
but
I
think
as
a
process.
We
should
be
opening
open
to
discussing
those.
F
Without
being
you
know,
obstinate
or
uncooperative
and
strong
working
group.
The
chair
is
critical
to
the
whole
thing.
As
a
general
comment,
I
would
say:
I'm
in
form
of
I'm
in
favor
of
forming
the
working
group,
I
believe
for
the
working
group
content.
It
would
make
more
sense
for
maybe
I'm
more
structured
rather
than
a
simple
linear
list,
maybe
group
things
together
that
belong
together,
so
they
can
be
prioritized
and
linked
together
and
then
ask
for
volunteers
to
write
the
material
and
to
review
it
following
the
precedent
from
DNS
xed,
which
predates
dns
off.
Y
Nalini
Elkins
I
would
like
to
support
very
much
that
the
support
for
debugging
and
analysis
and
also
put
in
measurement
there
was
just
recently
an
IEP
G
presentation
where
it
appears
that
multiple
queries
are
sent
where
one
who
would
have
expected
one
query
for
reasons
that
are
not
well
understood,
and
these
are
exactly
the
kind
of
issues
that
we
need
to
be
able
to
understand
on.
Certainly
the
networks
that
I
work
on,
which
are
large
enterprise
networks.
Z
Suzanne
Wolfe
first
is
jabber
scribe
and
then
I'm
gonna
plead
for
the
chairs
indulgence
for
a
very
brief
comment,
as
Deanna
Saab
co-chair
first
from
the
jabber
room,
Chris
lemons
I'm
significantly
in
favor
of
working
group
formation,
it's
unclear
to
me
how
to
put
discussion
in
scope,
but
not
resolution
of
disagreement.
Resolution
of
disagreement
is
a
major
part
of
what
working
groups
do.
Every
working
group
has
to
narrow
scope
of
discussion,
sometimes
taking
the
discussion
offline
to
breakouts
when
topics
get
hot
in
order
to
get
things
done,
I
think
monitoring.
Z
That
conversation
is
just
part
of
the
admittedly
difficult
work
of
the
chairs.
I,
don't
know
how
that
Charter
should
put
these
topics
out
of
scope,
particularly
since
we'd
benefit
significantly.
If
we
came
to
consensus
on
some
of
those
topics
further
responding
the
Patrick
Chris
lemons,
while
it's
true
that
the
Charter
could
use
improved
specificity
and
deliverables,
it's
inaccurate
to
say
that
there
are
no
deliverables
present.
Z
Also
as
dan
Asaf
co-chair,
the
DNS
op
Charter,
and
this
one
might
in
fact
need
some
further
discussion
to
refine
what
goes
where.
But
with
that
said,
the
current
day
and
I
thought
Charter
was
designed
in
part
significantly,
so
that
we
could
in
fact
push
off
work
to
other
working
groups
to
support
having
a
narrower
or
more
specific
set
of,
and
constituents
in
a
dedicated
working
group.
So
for
any
of
the
encrypted
DNS
topics
for
the
application.
Z
Specific
aspects
of
these
topics
certainly
I
think
that
what
what
David
said
as
chair
of
this
session
is
true,
that
the
two
working
groups
would
collaborate
closely
at
the
idea
and
at
the
area
and
the
Cheras
level,
but
also
you
know,
and
that
the
DNS
table
co-chairs
would
be
happy
to
discuss
which
items
belong
where.
But
there
is
nothing
wrong
in
under
terms
of
DNS,
aw,
history
or
charter
with
saying
there's
a
specific
set
of
work
items
here,
they're
related
to
each
other.
Z
AA
You
want
to
go
to
the
back:
ok,
ELISA,
Cooper
I
just
wanted
to
respond
to
a
couple
of
things
that
have
been
said
if
my
response
to
Brian,
actually
both
of
these
were
designed
by
committee,
so
take
that
for
what
it's
worth
and
just
piling
on
to
what
sue
said
someone
had
asked
like
if
there's
a
working
group
that's
overloaded
is.
Is
that
reason
enough
to
create
another
working
group
I?
Think
there's
there's
a
lot
of
precedent
in
the
art
area
for
splitting
off
related
topics
just
so
that
you
can
have.
AA
AA
Think,
given
the
nature
of
of
this
set
of
topics.
Well,
I
I
respect
the
the
impetus
to
attempt
some
process.
Innovation
is
actually
like
the
worst
kind
of
of
topic
to
try
that
we
have
a
process
it
has.
You
know
it
has
its
faults
and
strengths,
but
we
kind
of
know
how
it
works
and
for
something
that's
as
messy
as
this
people
might
want
to
think
about.
AA
AB
AB
For
one
I'm,
consulting
just
building
on
that
last
set
of
comments,
I
think
it's
self-evident,
there's
a
need
for
a
working
group,
there's
stuff
here.
That
needs
to
be
done.
That
doesn't
sit
well
anywhere
else.
The
two
slides
there's
far
too
much
for
a
working
group,
I
think
the
second
slide
there's
nothing
there
of
merit
that
fits
in
a
working
group
it
nor
looks
like
policy.
The
first
slide.
AB
If
you
took
the
first
four
bullet
points
on
the
right
hand,
side
that
looks
sufficient
for
a
working
group,
so
I'd
make
it
much
more
focused
as
I
say,
just
agree
with
what
was
just
said.
Take
those
top
four
bullets
on
the
right
hand,
side
jettison
the
rest
there's
more
than
enough
to
be
done.
It
needs
to
be
done
working
group.
Thank
you.
U
Fahan
Baker,
could
you
go
back
to
the
slide
with
the
bits
that
the
next
one
I
think
yeah
I'm,
very
supportive
of
the
idea
of
alternative
ways
of
doing
DNS
resolution
I
proposed
a
few
over?
You
know
the
past
ten
years,
whatever
I'm
quite
worried
about
this
whole
thing
and
the
way
it's
been
presented
here,
I'm
really
worried
about
this
idea
of
full
consensus,
because,
basically,
what
you
end
up
doing
is
by
you
give
a
pre-emptive
veto
on
certain
approaches.
U
U
The
question,
though
you
know
we
tend
to
focus
on
who
are
you
taking
the
power
away
from
and
what
we
don't
focus
on
enough
is
who
you're
giving
it
to
and
I
think
that
this
is
one
of
the
problems
with
doe?
Was
that
it
wasn't?
You
know
people
thought
oh
we're
taking
it
away
from
the
people
who
are
intercepting
and
doing
these
bad
stuff,
and
you
didn't
think
closely
enough
as
to
who
you
were
giving
the
power
to
instead
and
how
they
were
going
to
be
accountable.
U
R
A
rebel
si
si
I
think
there's.
Definitely
some
very
interesting
work
to
be
done.
I,
don't
think
AR
T
is
the
place
to
do
it.
I
view
DNS
as
fundamentally
it's
a
system
service,
not
an
application
service
and
the
bulk
of
those
items
that
I
see
there
on
that
list.
I
think
a
perfect
fit
for
int
area
scope
and
it
should
not
be
part
of
AR
T.
Q
So
I
think
we
should
form
this
working
group
I
mean
we've
talked
a
couple
of
light
years
now
about
the
problems
and
we
haven't
got
any
closer
to
resolution
and
I.
Think
one
of
the
reasons
is
that
we
have
don't
have
a
structured
discussion,
isn't
and
that's
what
I
was
hoping
we'll
get
when
we
have
that
working
group
to
actually
get
the
stuff
done,
and
when
you
look
at
the
to
the
left
and
right
side,
I
mean
if
you
think
the
left
side
through
a
lot
of
the
stuff
on
the
right
side.
AC
Okay,
Paul
machine
I
have
just
gone
through
the
draft.
The
draft
charter
and
the
latest
changes
mention
about
dealing
with
topics
such
as
smaller
detection,
privacy
and
pervasive
surveillance,
and
also
policy
controls.
Don't
you
think
that
you
are
handling
more
than
you
can
chew,
given
that
you
also
mentioned
you
need
full
consensus
and
that's
not
easy
to
get.
Thank
you.
Oh.
R
Yeah
Chris
box
bTW,
so
I
support
the
creation
of
awakened
group
to
solve
this.
If
you
go
to
the
previous
slide,
please
so
I'd
like
that
working
group
to
have
a
specific,
narrow,
achievable
focus,
which
a
lot
of
people
have
said.
I
totally
agree
with
that.
So
the
list
on
the
left
there
is
a
little
short
the
one
on
the
right.
You
could
trim
a
couple
of
items
from
that,
but
yeah.
R
C
Plan
D
and
Comcast
NBC
Universal
couple
comments.
First
of
all,
I
do
support
the
creation
of
the
working
group,
I
think
it's
going,
we
eat
with
either
lists
left
or
right.
It
has
some
very
valuable
topics
on
there,
which
the
community
of
both
users
and
I
CFR
is
really
good
benefit
from
people
getting
together
and
working
on
so
I
think
it's
important,
there's
material
in
the
Charter
and
other
discussions
here,
though,
about
creating
a
sort
of
an
adjunct
or
a
modified
ITF
process
for
getting
through
the
contentious
parts
of
this
I.
C
C
We
don't
have
to
always
drive
to
an
answer,
but
I
think
there's
work.
We
can
get
to
an
answer,
I.
Think
there's,
especially
if
we
eliminate
discussions
which
are
very
policy
centric
that
gets
into
territory
that
is
sort
of
outside
the
scope
of
the
traditional
ITF
and
I.
Think.
Maybe
that
would
remove
some
of
the
crazier
contentious
feelings
that
go
on
and
limit
and
focus
the
work
to
something
that
could
produce
results.
So
exactly
what
I
said:
Mady
delist
I'm
just
up
here
at
the
microphone
repeating
it
so
I
support
creation.
AD
Change
I
support
education
about
working
group,
specifically
a
new
working
group
with
it,
because
I
think
we
need
a
community
which
is
broader
than
the
dinosaur
pond,
and
this
is
because
there
is
actual
technical
work
that
is
to
be
done.
I
mean
there
are
three
different
deployment
models
that
are
emerging
and
rather
than
arguing-
and
you
see
which
of
the
three
is
better
I-
think
put
three
all
three
of
them
need.
AD
AB
AD
People
that
want
to
do
H
to
their
own
is
order
or
multiple
solvers
now
realize
that
they
still
need
to
discover
whether
there
is
any
local
policy
so
that
all
the
Kennelly
domain
is
coming
up,
and
that
is
also
something
that
needs
to
be
standardized,
because
I
mean
seen
from
the
view
of
from
the
viewpoint
of
a
DNS
operator.
I
hope
I
will
not
have
to
support
the
ten
different
cannily
domain
mechanisms
to
be
compatible
with
all
ten
different
clients
that
might
want
to
go
that
way.
AD
So
I
think
that
there
is
some
pretty
urgent,
I'd
say
technical
work
that
needs
to
be
done
to
actually
make
deployment
of
entropy
DNS
more
quicker
and
more
broadly
adopted.
I
will
also
point
out
that
I
mean
I
I
love
discussing
that
the
second
slide,
not
the
police
part
of
the
hardest
issues,
but
I
also
think
that
this
is
not
the
right
place,
maybe
possibly
to
to
have
that
discussion.
AD
First
of
all,
because
there
are
other
people
as
a
non-technical
stakeholders
that
want
to
be
involved
in
those
discussions
and
that
are
already
discussing
this
I
mean
so
I
think,
especially
they
people
that
are
going
for.
Third,
more
than
we'll
hear
from
governments
from
the
protection
authorities
from
law
enforcement,
people
about
all
the
problems
that
they're
deploying
model
is
causing
and
then
I
don't
want
to
enter
in.
That's
right,
that's
wrong
and
how
the
discussion
will
in
that.
But
they
think
this
is
a
discussion
that
is
much
broader
than.
AB
AD
A
AE
Given
the
newcomers
tutorial
for
about
three
years
now
and
two
points
that
we
make
our
rough
consensus,
not
everybody
has
to
get
all
their
answers
solved
and
a
we
succeeded
making
a
standard
if,
if
it
gets
deployed,
and
so
if
somebody
can
veto
discussion
or
a
thread
that
might
be
prevent
them
from
participating,
then
this
thing
is
not
gonna
get
universally
deployed,
so
it'll
fail
well,
I'd
really
hate
for
us
to
do
something
also,
that
is
against
our
history.
No
actual
real
point
of
pride
right,
the
slide
rough
consensus
and
running
code.
AE
Oh
accepted
this
one
group,
where
it's
only
running
code
that
counts
also
I,
want
to
point
out.
We
had
an
example
in
the
TLS
group:
I'll
use
the
phrase,
Enterprise
TLS
right
with
static
RSA
and
the
way
we
got
around
it.
The
way
we
addressed
it
is
we
got
consensus
within
the
group
to
stop
discussing
it,
and
that's
that's
what
you
should
do
here.
If,
when
you
find
problems
that
are
gonna
prevent
forward
progress,
the
group
can
say:
oh
yeah,
it's
more
important
for
us
to
do
progress.
AE
AF
Someone
Thompson
I'm
gonna,
go
back
to
what
Patrick
the
Menace
said
here
and
I'm
hearing
from
a
lot
of
people
that
they
want
to
do
this
in
a
working
group
without
specifying
what
this
is
and
from
this
set
of
things
that
you
have
AB
on
screen
here.
I,
don't
know
that
we're
talking
about
the
same
thing
and
I
suspect
that
the
problem
here
could
be
addressed
simply
by
saying,
oh
well.
We
had
a
great
discussion
about
sorts
of
things
that
people
might
want
want
to
do
in
this
room
here.
AF
But
if
we
want
to
continue,
we
need
to
have
more
concrete
and
focused
discussions
about
specific
things,
probably
backed
by
as
rich
pointed
out,
some
sort
of
running
code,
or
at
least
specific
proposals
and
I
I
saw
one
on
the
screen
today.
That
was
working
group
sized
almost
you
know
from
Tommy,
which
I
thought
was.
G
G
If
maybe
we
can
so
you
know
back
in
the
day
when
used
to
actually
try
to
edit
these
charters
in
the
screen,
and
that
was
except
for
cool,
so
I'm
gonna
like
make
a
save
one
of
those
things
like
a
charter
that
basically
has
the
first
three
items
on
this
list
on
the
right.
Do
people
want
to
do
and
nothing
else
and
a
recharter
for
later
than
that
now
something
could
actually
home
on
a
lot
shirt.
This
is
exactly
the
thing.
G
A
lot
perfect,
yes,
like
I,
mean
I,
think
there's
no
sense,
there's
no
sense
in
which
we
could
do
hung
on
a
this.
That
was
like
any
any
any
you
like
did
with
the
discussion.
We've
had
so
far
that
wasn't
like
that,
like
hyper
concrete,
like
I
just
described
so
like
now,
maybe
we
can
do
nothing
and
say
like
there's
no
consensus,
but
if
you
want,
if
you
want
to
get
consensus
on
something,
it's
gonna
have
to
be
something
like
that.
AG
Hi
cursed,
EP,
&
CSC,
so
I
just
wanted
to
note
some
of
their
changes
and
the
topics
that
were
suggested
to
be
contentious,
so
one
of
them
is
about
the
detection
and
suppression
of
malware,
which
I'd
like
to
think.
At
least.
The
aim
is
not
contentious
whether
you
disagree
on
the
method.
Fine,
but
I'd
like
to
hope
their
least.
Everyone
can
agree
roughly
on
the
aim
that
it's
not
a
good
thing
in
2019
to
not
at
least
discuss
it
and
currently
with
DNS.
We
see
a
lot
of
benefit
from
various
malware
filtering
solutions.
AG
It's
all
evidence.
We
have
the
protective
DNS
service
in
the
UK,
which
has
been
shown
to
provide
great
malware.
Defense
actually-
and
we've
got
quite
a
lot
statistics
to
back
that
up
and
what
I
would
like
to
see
is
some
discussion
about
a
users,
security
experience
not
being
degraded
without
their
knowledge
and
I.
Think
to
suppress
any
discussion
around.
That
is
really
quite
a
dangerous
thing
and
I'm
for
forming
a
working
group.
I
think
these
are
very
important
issues
that
need
to
be
discussed.
Thank,
You.
J
Ezra
Barnes
I'll
be
real
brief
I
there
I
feel
like
there.
There
is
probably
a
working
group
in
somewhere
in
this
that
I
could
support.
I,
do
not
support
the
formation
of
a
working
group
with
any
of
the
Charter
versions,
heretofore
produced
I,
think
Elissa,
Cooper
and
Patrick
McManus
kind
of
broadly
got
the
the
the
right
approach
here,
which
is
that
we
need
to
have
some
tight
focus
with
clear
deliverables
that
we
can
produce
some
value
on
which
may
be
among
the
set
here.
J
I
think
yeah,
as
was
mentioned,
Tommy's
draft
to
capture
some
of
them
as
well.
Probably
this
kind
of
local
network
capability
discovery,
local
resolver
capability
discovery
is,
is
the
right
zone,
but
I
think
we
need
a
charter
that
is
much
more
tightly
focused
on
that
before
we
can
make
any
progress.
AH
So
I'm
gonna
be
brief,
so
I
support
but
reached
mention,
so
the
consensus
should
not
provide
the
right
to
veto.
There's
a
first
thing
and
the
other
thing
it's
it's
not
because
we
were
trying
to
address
hard
question
that
we
should
not
try
to
address
those.
So
I
don't
want
to
remove
those
question
from
the
Charter.
AI
Elliot
leer
two
points.
First
of
all,
we've
heard
a
lot
about
how
we
shouldn't
innovate
process.
We
shouldn't
we,
we
need
tight
charters
to
to
accomplish
work.
We've
identified
some
work
that
that
can
be
accomplished.
Of
course,
a
working
group
is
not
the
only
vehicle
that
this
organization
has
and
it
seems
to
me
the
items
on
the
right.
At
least
most
of
them
are
worth
discussing,
it
doesn't
mean
they
have
to
be
discussed
in
a
working
group.
They
can
be
discussed
in
an
IAB
program.
They
can
be
discussed
at
a
workshop.
AI
They
can
be
discussed
in
the
IRT
F
I.
Think.
The
point
is
that
when
we
make
changes
to
the
architecture-
and
there
are
ramification
for
those
changes,
there
needs
to
be
a
vehicle
to
discuss.
Those
changes
doesn't
have
to
be
a
working
group,
but
I
would
ask
the
IETF
leadership
to
consider
the
list
on
the
right
and
figure
out
what
vehicle
the
people
should
use
for
that
for
discussion
and
actually
documentation
of
those
issues
we
got
here
in
in
part,
because
Jim
and
others
wrote
a
draft,
it
was
controversial.
AI
It
doesn't
mean
that
we
have
to
have
consensus
on
everything
that
he
wrote
and
there
are
vehicles
for
producing
work
where
there's
no
consensus.
I
want
to
actually
compliment
Aubrey
who
was
in
the
back
I
think
she's.
Over
there
we
had
a
very
controversial
document,
come
up
in
HR
PC
and
she
she
actually
discussed,
for
instance,
the
meaning
of
consensus,
and
she
wanted
to
get
even
further,
but
we
ran
out
of
time.
It
was
a
really
good.
AI
A
Really
quickly,
we
are
down
to
just
over
a
minute
left
and
I
want
to
actually
defer
to
Barry
and
Alyssa,
as
as
whether
they
are
interested
in
any
sort
of,
even
on
the
general
question
of
our
people
generally
in
favor,
let's
put
the
specific
Charter
aside
right
now,
but
generally
in
favor
of
focusing
in
a
new
working
group
or
passing
would
be
like
one
hum.
We
could
have
I'm
curious.
Is
there
anything
barrier?
Elisa
would
really
like
to
hear
from
the
end
of
this
session.
W
Listening
to
the
mic
discussion,
this
is
Barry.
After
listening
after
listening
to
the
mic
discussions
that
better
I
don't
see
anything
right
now
that
we
could
make
a
hum
on
in
the
time
that
we
don't
have.
So,
let's
defer
that
to
the
list,
I
hear
people
wanting
to
work
on
something
I
hear
people
thinking.
We
can't
come
up
with
an
agreement
on
what
we
can
work
on
and
I
hear
pretty
much
universal
agreement
that
the
list
on
the
right
is
too
much.
So
we
need
to
refine
that
on
the
mailing
list,
I.
AA
A
AJ
Go
up,
I'll
be
short,
name
is
Sanjay,
Mishra,
Verizon,
so
I
think
applications
are
doing
DNS.
So
that's
already
the
fact
so
I
think
keeping
that
fact
in
mind.
I
support
a
working
group
that
is
specifically
focused
on
so
now.
The
issue
is
actually
that
are
listed
in
the
latest
chap
in
the
right
hand,
side
and
I.