►
From YouTube: IETF111-ADD-20210730-1900
Description
ADD meeting session at IETF111
2021/07/30 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Oh
well,
hazel.
We
appreciate
your
go
tuitiveness.
I
will
say
that
actually-
and
this
is
not
just
blowing
smoke,
but
this
actually
is
in
fact
one
of
the
ways
to
start
really
becoming
involved
with
the
itf
is
to
actually
jump
in
with
both
feet
and
and
take
on
a
minor
responsibility,
no
matter
how
small-
and
this
I
would
say,
is
not
so
small
because
it
is
actually
something
we
need
for
the
functioning
of
the
working
group.
A
So,
and
one
of
the
other
things
that
both
glenn
and
I
have
failed
to
mention
is
that
other
people
will
be
following
the
cody
and
will
be
happy
to
jump
in,
and
you
know
make
a
quick
correction
if
they
see
something
you
know
a
missing
name
or
you
know
a
word
that
was
gotten
wrong,
so
it
is
not
solely
on
your
shoulders.
B
A
That
sounds
like
a
good
plan
to
me.
Yes,
exactly
they
use
the.
Is
that
what
it's
called
these
days
note
taking
tool
yep
and
where
it
says
it's
gonna
open,
cody,
md,
it's
basically
just
markdown,
but
you
don't
have
to
worry
about
formatting.
Just
you
know
type
in
the
text
and
away
you.
B
Go
and
we've
already
pre-populated
with
the
whole
agenda,
so
really
you
just
have
to
in
each
section
of
the
agenda
as
we
go
down
through
it.
If
there's
anything
important
that
comes
out
of
there
make
note
of
it,
you
don't
need
to
say,
like
in
the
chair
section,
that
the
shares
talked
about
getting
a
a
person,
but
you
can
note
that
hazel
and
tim
have
volunteered
to
help
take
notes.
That
would
be
a
great
start
to
those
notes
you
can
mention
how
pathetic.
A
C
B
Yeah,
so
all
right,
then
I
think
we
can
get
started.
I'm
glad
dean,
hello,
I'm
one
of
the
co-chairs
of
the
application,
adaptive
dns
discovery
working
group
add
my
other
co-chair
is
david
lawrence
and
our
area
director
is
eric.
Vinke
david.
Would
you
like.
D
B
B
And
here's
our
agenda
for
today,
so
this
is
we're
in
the
first
section.
Here's
the
first
five
minutes:
we've
got
our
scribes,
we've
done
no
well!
This
is
the
agenda.
So
we'll
do
a
quick
agenda
bash
we're
going
to
cover
for
a
10-minute
presentation
and
10
minutes
of
discussion.
That's
what
those
10
and
10
mean
the
first
of
our
working
group
drafts
ddr.
B
It's
gonna,
be
an
update
from
the
editors
followed
by
the
analysis
of
the
dns
forwarder,
as
done
by
barbara,
stark
and
and
and
chris
box,
and
you
can
read
the
rest
of
those
agenda
items
we'll
go
through
them
each
as
we
work
through
the
agenda.
Is
there
any
material
that
people
want
to
strike
off
or
add
in
it's
a
pretty
agenda
of
warm
people.
B
Okay,
hearing
them
will
accept
the
agenda,
so,
let's
get
to
it,
who
tommy
paulie,
I
think
you're,
the
one
talking
to
the
first
agenda
item
ddr
is
that
correct.
E
Yeah
should
be
going
now,
it's
good
now
all
right
and
if
you
could
maybe
start
one
of
the
timers
too,
so
we
could
tell
how
we're
doing
on
time
here.
I
want
to
make
sure
we're
respecting
the
time.
E
All
right
perfect:
I'm
going
to
give
a
quick
update
on
ddr
the
discovery
of
designated
resolvers,
not
dance,
dance
revolution,
and
I'm
doing
this
on
behalf
of
our
co-editors
on
this
document.
E
So
where
are
we
in
right
before
the
cut-off
we
published
a
draft
o2
version
of
this
document?
E
As
a
summary
of
some
of
the
recent
changes
in
the
o2
version,
there
are
a
couple
things
that
we
modified
based
on
the
feedback
from
the
working
group,
and
I
think
these
are
all
very,
very
good
improvements.
And
so
thank
you
to
everyone
who
provided
comments
and
issues
on
github
or
the
list.
E
F
E
One
I
think
that
daniel
mcgohan
raised
is
around
the
use
of
resolver.arpa
instead
of
he
was
suggesting
kind
of
using
the
reverse
address
form
of
it
in
editor.arpa.
E
The
current
behavior,
I
think
the
editors
think
is
correct,
but
we'd
love
to
hear
more
people's
thoughts
and
comments
on
this.
Our
current
rationale
is
to
mimic
something
more
like
ipv4
only.arpa,
which
is
you
know
again
a
query.
That's
really
to
the
local
resolver,
to
figure
out
information
about
what
it's
doing,
that
one
is
used
for
nat
64
bindings.
E
Designated
resolvers,
but
we
believe
that
sets
a
precedent
for
using
this
type
of
query
and
understanding
that
it
is
not
meant
to
go
up
to
the
root
and
we
believe
this
is
also
kind
of
the
right
thing
to
do,
because
it
is
a
address
agnostic
queries.
Just
saying:
hey,
resolver,
I
don't
care
how
I'm
accessing
your
thinking
of
you.
Do
you
have
a
designated
resolver
that
you're
pointing
to
anyway,
so
I
can
move
on
from
this.
E
D
I'm
in
favor
of
the
change,
so
I
I
think
that
using
any
inner
arbor
space
would
be
very
confusing,
because
people
would
expect
that
that
would
be
in
the
public
dns,
and
I
think
it's
actually
interesting
to
have
that
in
the
public.
Dns
and
people
would
start
putting
it
there.
Yeah.
E
D
G
Comments
now
you
hear
me,
I
guess
now
I
can
okay,
so
the
rationale
for
changing
it
is
more
to
understand
who
we
are
actually
asking
who
we
are
communicating
with.
So
this
is
why
I
think
that
a
generic
term
is
is
not
preferred.
The
preferred
way
to
do
and
the
other
one
is
that
it.
It
clearly
breaks
the
nsa
because
we
cannot
have
dns.
Second,
with
the
generic
terms
that
has
a
local
specification,
so
sure.
E
G
So
I
don't
know
ipv4
only
those
alpha,
but
so
the
the
the
one
I
I
I
think
we
we
have
this
home..
Now
we
have
a
not
a
homenet.opera
but
something
similar
and
it's
it
comes
with
some
some
issues.
G
At
least
the
thing
is
that
the
thing
that
is,
it
is
breaking
the
security
model
of
dns
sec
of
dns
seems
to
me
a
sufficiently
large
problem
and
the
other
one
is
also
that
you
don't
really
know
who
is
answering
to
you
sending
a
like
a
bottle
to
the
ocean.
G
That's
my
my
other
point,
but
the
question
I
had
to
the
previous
person
that
was
coming
was:
what
kind
of
arm
do
we
expect
if
it's
in
the
public
dns.
A
Okay,
okay,
so
I
appreciate
tommy
just
calling
people
into
the
queue
for
a
moment,
but
let's
still
handle
the
cue
and
we
can
come
back
to
that
then
address
that
point
cool.
So
all
right.
H
A
H
Hello,
ben
schwartz,
google
yeah,
I
support
resolver.arpa
as
the
name
here.
I
want
to
point
out
that
ddr
does
not
break
the
use
of
dns
sec
for
for
identification
and
validation
of
these
records.
What
ddr
says,
if
you
want
to
use
dns
sec,
then
dnsec
validates
data
associated
with
a
dns
name,
so
your
resolver
has
to
be
identified
by
a
dns
name.
If
your
resolver
is
identified
by
an
ip
address
in
ddr,
that's
not
a
domain
name
and
so
dns
sec
is
not
applied.
F
D
You
alexander,
to
respond
to
the
question
from
before.
I
think
that
I
can
see
two
risks.
The
one
is
that
an
unsuspecting
dns
administrator
could
put
it
deliberately
in
the
public
dns
because
they
don't
understand
between
the
fact
that
the
domain
should
resolve
only
for
the
local
resolver
and
and
the
the
public
reverse
zone
of
their
network
in
a
sense
and
the
other
thing
is,
I
I
think
that
people
would
desperately
start
trying
to
get
delegations
for
private
ip
addresses.
D
E
Perfect,
thank
you
all
right,
yeah.
We
have
pretty
clear
direction
in
the
group
and
I'd
like
to
move
on
from
this
issue
mark.
Can
it
be
very
quick?
Let's
come
in
real.
E
E
If
you
could
maybe
just
drop
drop
your
comment
into
the
chat.
K
Private,
the
in
indred.
B
Okay,
so
hey
tommy,
I'd
like
to
jump
in
here
as
chair
and
point
out.
This
is
captured
inside
github
as
a
resolver
issue,
number
21
in
the
git.
So
if
you
want
to
go
in
and
make
some
additional
comments
either
on
list
or
directly
into
the
github
repository
they'll
get
captured
as
well
and
and
carried
forward.
A
Yeah
and
and
also
that
was
the
10
minute
mark.
So
yes,.
C
C
B
E
So,
let's
move
on
to
that,
and
so
I
have
a
little
couple
more
slides
on
this
just
to
talk
about
it
so
issue
here
and
it's
really
a
couple
issues
in
a
family.
E
Talking
about
you
know
what
is
authenticated
versus
opportunistic
and
so
there's
some
things
we
just
wanted
to
clarify
from
the
editors
so
authenticated
discovery,
as
defined
in
the
document
is
saying
that
this
redirection,
this
designation
of
another
resolver,
is
kind
of
a
trusted
redirection
and
that
trust
is
based
on
either
matching
a
known
name
that
you
have
for
the
resolver
or
a
pre-known
ip
address
and
that's
being
validated
in
the
certificate
and
the
use
case
here
just
to
clarify
for
people
again.
Is
you
know?
E
Maybe
you
have
an
ip
address,
such
as
quad,
one
or
quad,
eight.
That's
a
public
ip
address
that
you
know
about,
and
you
want
to
be
able
to
find
other
things
that
this
resolver
may
support.
So
you
know,
for
example,
you
may
have
you
may
know
quad
one,
because
someone
typed
in
quad
one
to
a
configuration
on
a
device,
but
this
is
a
server,
that's
actually
accessible
from
many
different
addresses.
You
can
access
it
over
v6.
You
can
have
a
hostname
validation
for
it,
and
this
allows
us
to
bootstrap
into
that
world.
E
The
opportunistic
case
is,
on
the
other
hand,
something
where
you're
only
currently
allowed
to
stick
to
the
same
ip
address,
because
we're
not
able
to
validate
anything
else
about
it
in
the
cert,
because
it's
probably
a
private
ip
address
space,
and
so
again
this
is
meant
to
address
the
cases
where
someone
is
running
encrypted.
E
Dns
on
the
same
private
address,
resolver
that
they
already
had,
and
this
is
useful
as
a
mechanism
to
allow
encrypted
dns
to
prevent
dns
observation
when
you're
on
networking
you're
trying
to
prevent
an
attacker
snooping
on
your
network
when
you're
on
a
public
wi-fi
or
someone
on
the
home
network.
E
There
was
a
list
discussion
about
you
know.
Is
this
valuable?
I
you
know
I
believe,
given
this
use
case,
we
believe
it
is
still
a
valuable
thing
to
have
and
ben
do
you
want
to
comment.
H
Hi,
I
just
want
to
say
we're
going
to
have
a
very
detailed
discussion
of
this
at
the
end.
So
I'd
prefer
not
to
have
the
comments
about
this
at
this
time.
E
E
But
I
wanted
to
give
the
perspective
that
the
current
document
has
on
it.
So
for
the
case
where
you
have
a
complete
mismatch
between
your
provisioned
ip
address,
which
may
be
your
private
local
network
address
and
what
the
designated
resolver
is
that
is
currently
disallowed
in
the
document.
So
that's
the
case
where
I
have
the
device
only
knows
about
a
private
ip
address,
but
really
that's
forwarding
on
to
some
isp
resolver
that
has
an
encrypted
dns,
but
there's
no
way
to
prove
that
designation
or
that
delegation
there.
E
E
So
the
pr11
that
we'll
discuss
later
is
an
attempt
to
try
to
solve
for
this
problem
with
a
security
model.
That
is
just
trying
to
retry
a
lot
and
tries
to
get
you
into
an
authenticated
world,
and
I
would
suggest
that
kind
of
given
the
way
that
ddr
currently
is
thinking
of
things.
E
You
know.
Another
approach
here
is
to
soften
the
language
of
ddr.
To
say
it's
not
that
you
can't
use
this
hint,
but
the
hint
cannot
really
be
used
to
automatically
assume
that
there
is
an
authenticated
way
to
use
this.
That
doesn't
mean
that
there
can't
be
a
system,
policy
or
user
approval
way
to
allow
this.
E
You
know
there
are
many
different
use
cases
here,
for
example,
my
cpe
resolver
may
be
something
that
I
don't
want
to
circumvent,
because
maybe
it's
running
a
pie,
hole
and
it's
doing
ad
blocking
or
other
you
know,
fancy
things
automatically
circumventing
that,
I
believe,
would
be
incorrect
because
those
are
not
designated.
Those
are
not
equivalent,
however,
letting
a
user
choose
they're
like
hey.
We
see
that
you,
your
dns,
is
behind
something
that
offers
encrypted
dns
on
comcast.
E
Do
you
want
to
use
that
and
then
the
user
can
make
a
choice
or
something
else
can
make
a
more
informed
choice
about.
Is
it
appropriate
to
skip
the
actual
cpe
resolver,
which
may
be
just
a
blind
forwarder,
but
it
may
be
running
something
that
the
user
really
wants
like
a
pie
hole
anyway,
that's
kind
of
our
editor's
thoughts
on
these
issues
and
we
have
a
couple
minutes
left.
I
see
ecker
in
the
queue.
L
I
mean
so
like.
What's
your
approach
here
sounds
terrifying.
You
know:
hey
user,
goggle,
dns
tech,
tech,
tech.
Would
you
like
to
tech,
tech
tech
I
mean
like.
I
just
cannot
see
how
any
user
could
possibly
simulate
that
information,
so
so.
E
I
mean
again
like
I'm
not.
This
could
be
up
to
system
policy,
for
example
in
firefox
you
guys
have
a
list
of
trusted.
You
know
encrypted
resolvers,
so
you
could
say
hey.
This
is
one
of
the
ones
we
know
about.
We've
approved
this
one.
Do
you
want
to
use
it?
It
doesn't
necessarily
have
to
be
something.
L
Oh,
I
mean
I
mean
I
mean
sure,
but
let
me
be
clear:
we
intend
to
use
ddr
as
a
person
that
exists
for
this
purpose
right.
So
I
think,
like
I
mean
I
think,
yeah
I
mean,
which
I
mean.
I
think
you
know
I
guess
well.
We
are
following,
but
I
think
you
know
yes.
So
what.
L
Sure,
but
I
guess
I'm
just
saying
like
fair
enough,
I'm
just
saying
I
agree
with
that
part.
I'm
just
saying
like
that.
You
know
like.
If
so,
if
we
were
to
do
this,
it
would
most
likely
be.
You
know
we
would
just
look
at
the
domain
name
that
you
were
claiming
and
nor
the
ip
addresses
entirely
right,
because
we
already
have.
We
already
know
exactly
where
we
want
to
go.
We
don't
need
this
information
learning
function.
C
L
So
I
guess
like
so
I
mean,
if
that's
we
have
mine
sure,
but
I
guess
I'm
just
saying
like
you
know
what
we
have
in
mind
is
like
stuff,
probably
stuffing
you
know,
I
haven't,
bought
it
through
too
much,
but
it's
just
stuffing.
You
know
whatever's
convenient
in
these
records
in
a
way
that
kind
of
works
out
right.
B
If,
if
I
can
jump
in
here
guys,
this
is
a
good
discussion,
but
I'll
point
out
that
it's
sort
of
like
ddr
is,
as
we
are
chartered
it's
a
discovery
mechanism.
It's
a
means
to
discover
it's
not
the
whole
solution,
and
while
I
echo
you
have
good
points,
I
think
we're
drifting
off
a
little
bit
into
the
the
decision
and
the
usability
framework
portions.
That
would
make
use
of
this
yes
down
the
road,
but
this
is
technical
gorp,
because
it
is
low-level
technical
gorp
that
other
things
will
then
tap
into
and
build
on
top
of.
A
E
Yeah
right
so
essentially
just
glenn
to
your
point.
I
think
what
I'm
trying
to
say
for
the
purpose
of
ddr,
given
this
in
the
ddr
section,
is
that
I
believe
that
you
know
the
ddr,
like
you
say,
is
a
mechanism
and
that
at
some
point
the
the
mechanism
kind
of
runs
out
of
what
it
can
tell
you,
and
it
says
you
know
here's
what
I
can
do
certain
things,
but
all
of
the
discussion
about
how
we
end
up
using
these
hints
in
this
local
cpe
to
isp
resolver.
E
L
So
I
want
to
see
like
right
leslie,
so
I
largely
agree
that,
but
I
guess
what
I'm
saying
is
what
I'm
not
going
to
want
us
to
do
is
go
down
the
road
of
designing
mechanism
which
is
not
used
to
conceivable
use
to
anybody
and
so
like.
So
though
I
mean
so
the
way
time
described,
it
seems
useful,
but,
like
I
can
imagine
things
we
could
say
which
nobody
would
conceivably
actually
consume
and
they
should
not
say
those
things.
L
E
Yep
exactly
and
so
just
to
wrap
up.
I
I
believe
what
we
are
saying
is
that
currently,
ddr
gives
you
a
hint
and
it
can
give
you
an
authenticated
version,
a
way
to
learn
about
the
private
address
version
and
then
a
hint
that
can't
tell
you
anything
more,
but
you
can
make
a
decision
with.
We
think
all
three
of
these
use
cases
are
valid
and
useful
to
different
people,
but
I
think
that
we
think
that's
where
the
mechanism
in
ddr
ends
and
is
providing
this
and
handing
off
the
work
to
other
solutions.
A
A
Oh
eric
reach,
okay,
did
he
rejoin
he
had
if
you
have
a
quick
comment,
go
ahead
and
and
make
it
there
eric
before
we
move
on
to
the
next
photos
are
kind
of
confusing.
A
B
That,
oh,
it
goes
back
to
the
first
slide
that
I
mean
not
where
we
were
at
the
next
item
on
the
agenda
is
barbara
stark
is
going
to
talk
about
the
analysis
of
a
dns
forwarder
scenario
relative
to
ddr
and
dnr,
and
this
we've
allotted
10
minutes
for
barbara
to
sort
of
pitch
it
out
and
explain
their
thinking
and
then
an
extended
20
minutes
of
discussion.
B
A
M
A
We
I
understand,
we'll
keep
an
eye
on
that.
Okay,
you
have
control
barbara.
M
Okay-
let's
see
I
haven't
done
this.
B
M
Okay,
so
I
had
the
the
slides
request,
but
that
didn't
seem
to
do
anything.
I
didn't
see
any
other
pre-ordered
slides.
I
don't
want
to
take
too
much
something.
M
Oh
there,
it
comes
okay.
M
B
M
That
works
sorry
for
the
problems.
Okay,
so
this
was
just
an
analysis
of
sort
of
the
the
dns
forwarder
scenario
where
you've
got
this
common
scenario
with
the
residential
gateway
cpe.
Some
people
like
to
call
it
ce
router
that
has
a
dns
proxy
dns,
forwarder
type
functionality
in
it
and
just
kind
of
seeing
you
know,
given
the
current
state
of
ddr
and
dnr.
How
does
this
scenario
play
out?
The
the
this
was
a
use
case
specifically
listed
in
the
requirements.
M
M
So
this
particular
draft
is
only
trying
to
analyze
this
specific
use
case.
You
know
not
enterprise
use
cases
not
case.
You
know,
of
the
coffee
shop
owner.
Other
cases
like
this.
This
is
specifically
you
know
this
residential
end
user
use
case,
and
what
would
they
experience
under
the
current
state
of
where
these
drafts
are?
M
Any
of
those
are
possible
so
yeah,
I'm
just
trying
to
analyze
it.
Let's
move
on.
If
we
could
so
the
you
know,
why
do
operators
put
this
proxy
in
this
device?
There
are
a
variety
of
reasons:
local
name
resolution.
M
You
know
oftentimes
these
devices
have
their
own
little
domain,
that
you
know,
and
they
can
tell
people.
You
know
if
you
ever
need
to
access
your
router
just
type
in
this
domain
name
and
there
you
are-
and
this
especially
of
course,
gets
useful
with
ipv6.
We
know
domain
names,
we
don't
want
people
typing
in
ipv6
addresses
so
having
local
name
resolution
as
we
slowly
move
towards
v6.
M
Only
perhaps
in
some
few
decades
in
the
future
really
does
become
important,
and
so
you
know
local
name.
Resolution
at
some
point
is
something
that
has
to
get
solved
captive
portals.
We
had
some
discussion
around
captive
portals.
I'll
just
mention
some
ways
captive
portals
are
used
are
to
provide
initial
configuration.
M
M
That
says,
this
device
is
indeed
associated
with
this
user
and
this
user's
connection,
and
then
it's
given
full
access
to
the
network.
You
know
some
other
uses.
I've
seen
of
captive
portal
are
when
the
user
plugs
a
a
secondary
router
in
because
they
want
that
other
router
to
actually
be
the
main
router
for
their
home
network
and
the
isp
router
simply
becomes
the
mechanism
that
knows
how
to
connect
to
the
isp
network.
M
Sometimes
you
can
have
a
functionality
that
the
isp
router
can
pop
up
and
say:
oh,
I
see
you've
put
in
another
router.
Would
you
like
me
to
eliminate
my
nat
so
that
that
router
then
gets
the
public
ip
address,
and
you
can
have
this
as
a
way
to
eliminate
the
double
net?
These
are
just
some
uses
of
captive
portal.
Now
I
don't
know
if
the
current
discovery
mechanisms
or
would
break
the
the
captive
portal
usage,
but
it's
certainly
something
to
consider.
M
So
you
know
I
I
kind
of
went
through
a
few
scenarios.
There
are
some
assumptions
common
to
all
the
scenarios.
You
know
an
assumption
that
maybe,
if
these,
if
we
are
successful,
that
common
operating
systems
would
support
both
dnr
and
ddr
and
that
some
applications
might
choose
to
support
ddr
now.
One
thing
we
know
pretty
much
for
certain
is
that
there's
no
certificate
authority
in
the
world
that
is
going
to
sign
a
certificate
with
a
private
ip
address
in
the
sand
field.
M
Okay,
so
moving
right
along
the
first
scenario
looked
at
was
the
the
router
is
not
updated
at
all.
We
know
this
is
going
to
be
a
very
common
scenario,
because
we
know
how
you
know
either
routers
don't
get
updated
or
perhaps
the
ability
to
support
anything
around
doe
or
ddr
dnr.
Those
sorts
of
things
may
not
be
a
priority.
M
You
know
it's
not
necessarily.
A
security
flaw,
many
routers
vendors.
These
are
oftentimes,
not
the
very
high-end
routers
and
so
oftentimes.
The
companies
that
offer
them
really
are
very
careful
around
their
development
resources
and
what
features
they
put
in.
So
we
need
to
assume
that
they're
going
to
be
many
that
are
not
updated
or
and
oftentimes
cannot
be
updated.
M
So
in
this
case
the
the
operating
system
or
the
app
simply
will
not
discover
a
local
encrypted
resolver,
you
know
if
they,
you
know
they,
they
may
use
some
non-standard
mechanism,
like
we
see
currently
with
a
number
of
browsers
where
they
maintain
lists,
and
you
know
they
simply
default,
maybe
to
their
preferred
doe
provider
things
like
that,
but
from
a
dnr
ddr
perspective,
we
can't
expect
anything
happening
around
that
local
with
the
ce
router.
M
So
basically,
in
their
current
form,
it's
pretty
clear
that
ddr
and
dnr
do
not
satisfy
the
the
requirement
that
is
in
the
requirements
draft.
That
of
should
not
require
any
changes
to
dns
forwarders
and-
and
you
know
that
is
what
it
is,
I'm
not
saying
that's
bad
or
good,
I'm
simply
saying
it
is,
and
we
should
acknowledge
that
it
is
hopefully
and
also
you
know,
non-upgraded
legacy.
Routers
are
also
not
going
to
satisfy
the
requirement
that
a
dns
forwarder
should
not
forward
queries
for
resolver.arpa
upstream.
M
That,
too,
is
what
it
is.
You
can't
change
them,
that's
by
definition,
and
you
know
the
testing
we've
done
suggests
they
will
be
forwarding
the
resolver.arpa
or
whatever
this
url
is
upstream,
if
they
get
the
request.
So
hopefully
these
are
not
controversial,
notes
or
assumptions
or
result
suggestions.
Oh
look,
tommy
wants
to
say
something.
M
E
Hello
yeah,
just
I
was
wanting
to
comment
on
some
of
the
stuff
that
was
going
on
in
the
chat
as
just
clarifications
to
this
so
first
for
that
second
part
about
the
forwarding
you're
correct
that
the
ddr
says
that
you
shouldn't
forward
these
upstream.
However,
it
does
explain
that
for
like
the
blind
forwarder
case,
which
is
very
common
on
the
router,
that
it
may
do
that
when
it
essentially
knows
that
it's
not
kind
of
the
end
resolver
that
is
going
to
be
offering
encrypted
dns.
E
M
E
M
We
need
to
acknowledge
that
these
not
not
updated
routers
are
simply
going
to
forward
these
requests
so
moving
along,
I
think
scenario
two.
This
is
updated
to
provide
dnr.
So
this
is,
you
know
in
the
dhcp
replies,
and
you
could
also
you
know,
decide
to
do
something
about
resolver
dot,
arpa
locally
or
not,
but
not
trying
to
offer
dough
natively
within
the
router.
M
So
in
this
case
you
know,
if,
if
you
get
the
the
dope
the
encrypted
resolver
information
by
the
dhcp,
you
know
some
operating
systems
might
use
it
if
they
feel
like
it,
but
then
again
they
might
not
applications
that
try.
The
resolver.r
would
not
use
the
encrypted
resolver
and
just
in
looking
at
some
of
the
reasons,
you
know
why
we
have
this
forwarder
proxy
here
that
in
the
first
place
our
local
name
resolution
is
now
broken.
M
We
you
know
legacy
captive
portal
is
something
we're
still
exploring
and
going
to
be
doing
some
testing
on
and
actually
the
initial
testing
suggests
it
may
be
okay,
but
that
also
may
depend
on
the
implementation.
You
know
part
of
the
reason
for
that
is
you
know
that
maybe
the
first
dns
query
that
gets
launched
is
to
resolve
the
domain
of
the
doe
server,
in
which
case
the
captive
portal
may
be
hit.
M
M
H
Hi,
so
I
find
that
scenario
too
confusing,
because
the
resolver
is
deliberately
breaking
itself.
That
is
all
the
advertising.
Dnr
is
a
statement
to
the
network
of
the
form.
I
would
suggest
that
you
use
this
resolver
instead
and
that
is
provide
that
that
statement
is
made
by
the
cpe
device.
So
if
the
device
is
telling
the
network
don't
use
me,
then
it
of
course
is
no
surprise
that
services
it
provides
are,
are
no
longer
no
longer
present
in
in
the
dns
service
that
it
has
pointed
to.
H
But
that
is
its
own
decision
and
it
you
know
none
of
this
has
you
know
it
can
also,
as
I
think
you're
about
to
note
it
can
point
dnr
to
itself,
in
which
case
there's
no
problem
so
anyway,
I
think
this
is
you're
describing
essentially
a
buggy
deployment.
M
I
would
agree,
but
you
know
part
of
the
the
usefulness
of
analysis
like
this
is
to
be
able
to
come
to
a
conclusion
like
that.
You
know
using
paper
rather
than
code
to
to
come
to
the
conclusion
of
you
know.
This
probably
is
not
a
good
idea,
so
I
agree
but
yeah
I
wanted
to
step
through
it
and
and
I'm
glad
we
agree
on
that,
and
so
the
last
scenario
was
to
look
at
you
know
if
we
update
the
ce
router
with.
M
So
if
we
move
on
to
scenario
three
yeah,
I
think
I
went
through
all
that
this
would
be
the
the
fully
upgraded
ce
router.
In
this
case
you
know
the
operating
systems
and
applications
that
feel
like
supporting
discovery
will
support
it
and
those
that
don't
won't.
That
is
what
it
is.
M
We
are
going
to
see
inconsistent
behavior
and
honestly
in
talking
with
my
friends
who
do
router
development.
This
isn't
really
a
very
likely
thing
to
happen
in
the
context
of
such
uncertainty.
M
So
while
this
could
certainly
provide
you
know,
it
is
a
a
possibility.
It's
actually
appearing
to
be
also
an
unlikely
possibility,
but
let's
also
go
to
the
next
slide
and
yeah,
which
is
the
question
of.
Is
the
analysis
correct?
So
you
know
the
what
what
I'm
seeing
is
that
the
most
likely
scenarios
of
what
we're
going
to
see
from
behaviors
in
ce
routers
are
that
either
the
proxy
is
on
or
the
proxy
is
off.
M
You
know
if,
if
we
assume
that
even
advertising
the
dhcp
address
of
the
upstream
doesn't
make
sense,
then
those
really
are
the
options
and
if
those
are
the
options-
and
we
were
serious
about
wanting
to
support
this
use
case
and
maybe
not
breaking
some
things-
that
users
can
currently
do
in
the
process,
what
is
the
path
that
we
should
take,
and
so
I
think
the
last
slide
is
about
what
do
you
think?
M
Do
we
take
no
action?
Do
we
make
any
changes
to
ddr
dnr?
Do
we
create
implementation
best
practices
which
you
know
glenn
has
said,
is
out
of
scope,
but
you
know
recharters
can
happen,
and
maybe
it
would
be
useful
for
us
to
see
if
we
could
consider
some
best
practices
you
know
with
just
like.
We
can't
necessarily
expect
applications
or
operating
systems
to
do
ddr
or
dnr.
B
Barbara
one
clarification
so
for
the
documents
that
are
being
developed,
ddr
and
dnr,
and
anything
that
comes
after
them.
It
is
appropriate
and
in
scope
to
provide
guidance
in
those
documents
to
say:
look,
do
not
do
these
things
with
these.
These
protocols,
we've
developed
right
out
of
scope,
of
course,
is
the
ui
and
decision
making
all
that
other
kind
of
stuff,
which
is
the
client
side
functionality.
That's
not
a
scope,
but
guidance
on
avoiding
stupid
stuff,
totally
in
scope.
M
I
I'll
so
I
I
am-
I
think,
that's
in
in
that
case,
if,
if
we
are
not
allowed
to
ever
consider
recommending
that
users
be
given
options,
which
I
heard
you
say
is
out
of
scope,
then
I
think
this
is
dead
in
the
water.
I
don't
think
it's
really
possible
to
say
you
know
that
users
have
control,
but
we're
not
going
to
allow
users
to
have
control.
M
B
Well,
let
me
clarify
that
again,
so
what
we
are
not
chartered
to
do
was
to
work
on
the
ui
or
the
browser
or
the
logic
portion
of
this
discovery
decision
making.
We
are
charted
to
convey
the
information
and
and
develop
the
means
to
do
that.
So,
if
so,
as
I
look
through
the
presentation
you
just
did,
several
things
are
touched
on
router,
implementations
and
architectural
decisions
of
how
you
would
do
things
in
cpu
devices.
M
Sure,
but
it
also
says
we're
except
I
mean
yes,
yes,
those
are
the
rules
that
were
decided
and
what
I'm
saying
is
that
that
is
going
to
result
in
we're
giving
up
on
supporting
this
use
case.
We're
simply
saying
this
use
case
is
not
supported.
It's
going
to
be
broken
because
we
refuse
to
even
consider
making
recommendations
around
how
users
are
treated
or
yeah
anyway,.
A
Okay,
if
we
can
yeah.
M
A
N
Microsoft,
two
questions.
First,
though,
to
address
what
was
just
being
discussed,
I
don't
think
that
saying
that
we
can't
standardize
protocol
support
for
scenario
is
the
same
as
saying
we're
going
to
abandon
it.
Speaking,
at
least
for
my
area,
I
can
say
that
they're
different
from
the
discussion
in
the
first
set
of
slides
I'd
actually
point
out
what
was
happening
there.
At
the
end,
the
kerfuffle
around
client
policy
discussion
as
tommy
points
out
ddr
stops
at
saying.
N
Oh,
we
cannot
validate
this
record
this
hint,
but
it's
still
there,
and
so
just
because
ddr
doesn't
tell
you
you
have
to
use,
it
doesn't
mean
a
client
can't
decide
to
use
it
under
certain
circumstances.
It's
just
as
a
working
group.
We've
decided
that
we
can't
go
standardizing
that
behavior,
because
every
client's
going
to
want
to
make
different
decisions
and
I'll
leave
that
at
that,
in
terms
of
my
commentary
there.
My
other
question
was
just
a
question.
N
It
seems
to
me
that
most
of
the
things
discussed
here
are
time
bound,
meaning
that
eventually
ddr
dnr
capport
work
would
address
the
concerns.
Am
I
missing
something
where
there's
some
subset
that
those
solutions
will
never
work.
M
You
know
the
dns
caching
hit
could
probably
be
accepted
as
let's
just
take
you
know
the
latency
isn't
that
bad
and
things
are
doing
pre.
You
know
fetches,
and
things
like
that.
I
think
the
captive
portal
is
solvable.
I
think
it
really
comes
to
sort
of
the
local
domain
names,
in
which
case
you
really
need
some
sort
of
split
horizon,
because
I
don't
think
the
the
ce
router
can
reasonably
be
expected
to
support
doe,
and
I
think
you
need
some
sort
of
split
horizon
allowance.
A
O
Thank
you
eric,
please
thing
that
might
be
worth
calling
out
for
some
of
these
is
what
is
and
isn't
possible
on
the
boundaries
of
these,
like,
especially
on
the
parental
controls
topic,
which
I,
which
is
a
very
important
and
hot
button
topic
here,
being
able
clarifying
that
that
there
are
some
types
of
parental
controls
that
are
possible,
for
example,
you
can
with
dnr
and
ddr
you
can.
O
You
could
have
a
a
two
different
resolver
ips,
you
could
hand
out,
one
of
which
had
parental
controls
enabled,
in
the
other
that
doesn't
have
parental
controls
enabled
or
you
could
have
a
if
you're,
using
doe.
You
could
have
a
doe
uri
that
embeds
some
of
the
policy
information
into
that.
So
you
could
do
so,
there's
some
degree
of
parental
controls
that
are
that
are
possible.
O
It
just
becomes
harder
and
doesn't
necessarily
make
it
as
easy
to
do
the
the
level
of
fine-grained
parental
controls,
as
as
you
can
do
on
the
on
the
router
itself.
M
You
know
it
might
be
curious
if
with
ipv6,
something
might
be
done,
but
you
know,
maybe
not
so
yeah
parental
controls
is
another
issue,
and
I
know
it's.
You
know
it's.
It's
a
bit
more
of
a
concern
to
my
co-author
across
the
pond.
M
E
Yeah
there
was
so
first
I
mean
I
do
want
to
reiterate
for
the
group
that
you
know
there
are
a
number
of
cases
that
do
work
well
for
both
gdr
and
dnr.
You
know
mobile
network
scenarios
they're
going
to
do
the
right
thing,
a
lot
of
home,
wi-fi
networks
like
I'm
on
comcast.
Here
I
get
quad
75,
that's
gonna
work,
just
fine
with
ddr
or
dnr
as
they
are,
but
I
think
you
know
for
the
case
you're
bringing
up
here.
E
I
definitely
don't
think
we
want
to
accept
the
breakage
or
give
up
on
them
like,
and
I
don't
think
people
are
suggesting
that,
but
the
problem
with
automatically
trying
to
encrypt
things
for
these
scenarios
is
exactly
what
you
were
bringing
up
on
slide.
Two.
I
think
you
know
those
are
the
scenario
two
you're
skipping,
the
local
filtering
rules,
skipping
local
name
resolution
like
these
are
more
complex
problems
and
these
two
things
to
use
our
earlier
terminology
terminology
they're,
not
equivalent
they're,
not
designating
each
other.
E
Like
it's
a
more
complex
scenario-
and
I
think
you
know
the
mechanisms
again
that
we
have
in
ddr
are
necessary
to
allow
clients
to
solve
this,
but
they
are
not
sufficient
on
their
own.
For
this
particular
scenario-
and
I
think
you
know
what
you
were
mentioning
about
user
control-
I
think
that's
exactly
what
we
need
for
this
scenario,
because
a
device
cannot
make
the
decision
for
someone
about
whether
or
not
they
want
to
use
their
filtering
on
on
their
local
ce
and
long
term.
M
L
So
it
seems
to
me
this
presentation,
implicitly
after
something
impossible,
which
is
at
least
in
the
context
of
we're
trying
to
do
a
ddr,
because
the
point
of
ddr
is
to
allow
you
to
upgrade
to
in
to
encrypted
connection
regardless
of
the
state
of
the
local
router
and
without
touching
the
local
router,
and
what
you're
asking
for
is
you're,
not
upgrading
to
an
encrypted
connection
or
not
touching
the
local
router
and
the
problem
is
those
things
look
identical
to
to
the
client,
and
so
you
know
now
there
are
things
one
can
imagine
doing
you
know.
L
So,
for
instance,
as
ben
was
mentioning
firefox
attempts
to
detect
when
it
thinks
the
local
router
is
filtering,
and
if
it
does,
it
turns
off,
though,
and
and
and
contrary
wise,
if
it
can't
resolve
something,
it
falls
back,
which
sort
of
half
works
with
these
local
name
name
things
but
like
as
a
practical
matter
like
if
you're
not
willing
to
touch
the
local
rider
either
case.
You
will
not
be
able
to
distinguish
these
cases
generically
unless
there's
a
uniform
thing.
L
So
I
mean
it
seems
to
me
that,
like
is
that
second
required,
it's
the
second
requirement.
It's
the
one,
that's
broken,
because
you
should
be
favoring
encryption
and
if
and
if
a
local
router
wishes
to
stay
in
the
game,
it
should
have
some
positive
action.
Now
we
could
discuss
the
positive
actions
will
be
very
easy,
such
as
says
updating
your
block
list
to
block
resolve
around
arpa.
L
But
if
but
but
I
mean,
the
premise
of
this
group
I
think
is-
we
should
be
biasing
towards
more
encryption
and
so
having
a
situation
which
the
local
writer
has
to
upgrade
to
a
lot
of
encryption
seems
like
antithetical
that
so
so
I
think
like
like.
L
Obviously,
as
I
said,
I,
I
don't
think
it's
ideal
to
break
those
to
break
those
use
cases
and
we
make
some
attempt
not
to
but
like
we
know,
we
don't
get
it
right
all
the
time
and
you
know,
and
we
and
we
expect
that
the
local
router
says
at
the
basement
change
occasionally.
M
Yeah,
I'm
just
kind
of
concerned,
you
know,
after
the
you
know,
people
kind
of
were
hoping
home
net
would
be
able
to
cause
the
local
routers
to
do
some
changes
as
well,
but
I'm
a
bit
of
a
realist
since
I've
kind
of
worked
with
them
for
about
20
years-
and
you
know
my
my
sense
of
things
is:
if
local
routers
do
change,
it's
going
to
be
a
long
long
time
and-
and
you
know
like
I
said
part
of
it-
was
just.
M
B
Hey
there
glenn
here
jump
in
so
we
are
out
of
time
for
this
particular
topic.
So
if
there's.
P
It
will
be
very
short
anyway.
It's
simply
to
know
what
you
said
five
ten
minutes
ago.
I
think
it's
in
within
the
charter,
basically
to
put
usability
statement
or
even
some
recommendation
on
the
protocol,
but,
of
course
not
about
deciding
a
policy
whether
you
need
to
do
this,
and
this
in
this
case
right.
So
that's
all
I
had
to
say
thank
you
again.
P
C
I
can
be
real
quick.
Firstly,
I
want
to
say
thank
you
to
barbara
and
chris
for
writing
this
up.
I
think
it's
really
important.
We
document
the
real
world
and
deal
with
that,
not
what
we'd
like
the
world
to
be,
and
I
think
it's
imperative
we
find
solutions
for
for
one
and
three,
but
particularly
one
when
we
acknowledge
that
the
sort
of
shelf
life
for
for
routers
or
routers,
if
you
prefer,
is
potentially
ten
years
plus
for
many
people.
C
So
we
can't
just
wish
this
away
by
saying
they
need
to
upgrade
them,
because
that
isn't
going
to
happen
for
the
vast
majority
of
users,
irrespective
of
what
we
might
prefer
great.
Thank
you,
andrew.
B
And
thank
you
barbara
great
minds,
okay,
so
our
next
topic
is
going
to
be.
Let
me
take
this
off
and
let's
go
back
to
our
agenda.
It's
gonna
be
presented
by
dan
wing
and
I
see
dan's
queued
up.
It's
going
to
be
see.
This
is
item
number
three,
which
is
dhcp
and
router
advertisement,
options
for
discovery
of
network
designated
resolvers
or
as
we
like
to
call
it
around
here,
dnr,
it's
a
heck
of
a
moment.
Q
Would
you
like
to
do
be
easier
if
you
drove,
because
I
haven't
done
this,
meet
you
driving
thing
so
happy.
B
Next
time,
yeah,
this
is
the
short
ones
we
have.
I'm
gonna
set
the
timer
for
10
minutes,
so
we
have
five
for
pres
and
five
for
questions.
Q
So
from
from
there
we
changed
how
we're
doing
the
sv
cbs
and
got
review
from
dhc
working
group
on
on
the
approach
that
we're
using
it's
more
text
on
design
rationale
and
incorporated
michael's
suggestion
in
section
three,
then
in
version
two
we've
split
off
the
deployment
considerations
into
a
separate
document
which
will
be
the
next
to
next
presentation
that
I
do
here
and
clarified
the
v4
v6
hints
for
the
fcc
params,
and
we
currently
have
no
pending
comments
against
zero
two.
So
next
slide.
Q
A
C
H
All
right,
I
think,
yeah.
I
think
this
draft
is
good.
I
think
it's
you
know
in
the
sense
it's
ready
for
last
call,
but
I
also
kind
of
worry
that
I,
if
we
move
forward
with
it
now,
we
we
preempt
some
important
discussions
because
it
it
should
be.
It
should
remain
in
line
with
ddr
and.
C
H
Having
moving
this
forward
now
before,
we've
really
pinned
down
some
of
the
details
of
ddr
worries
me,
for
example,
we
need
to
be
really
clear
on
on
what
the
authentication
rules
are,
what
names
you
have
to
have
in
your
certificate
when
you,
when
you
use
the
the
different
modes-
and
I
think
that's
still
a
topic
of
debate,
you
know
we
should
try
to
reach
similar
or
matching
solutions
for
dnr
and
ddr.
I
Hello,
so
I
agree
with
ben
that
there's
it's
a
little
early
to
do
working
group,
that's
cool
and
in
terms
of
the
content
of
the
draft.
I
know
in
this
revision
that
the
idea
was
to
incorporate
what
service
b
says
and
so
therefore
simplify
what
people
have
to
do.
I
You
know
it's
the
same
mechanism
that
is
used
with
ddr,
except
that
it's
not
quite
the
same,
because
in
dnr
service
b
is
incorporated,
but
you
should
not
include
the
address
hints,
so
you
have
to
take
them
out
because
the
addresses
are
listed
separately.
I
Q
Okay,
I
think
that
goes
kind
of
back
to
ben's
comment
that
there's
value
in
holding
them
both
up
to
align
them,
and
that's
just
one
of
the
misalignments.
H
B
Q
B
Q
That's
fine,
so
enterprise
split
horizon
dns
next
slide,
please.
Q
So
we
got
some
comments
from
the
working
group
that
have
been
incorporated
next
slide
and
a
quick
recap
of
of
what
this
is
doing.
So
this
is
similar
to
what
ip2
has
has
done
for
a
while
and
got
standardized
in
an
rfc
so
that
there's
private,
only
dns,
resolvers
and
there's
public
that
can
potentially
have
different
information
in
them.
Q
You
know
resolve
the
different
prices
next
slide,
so
we
updated
the
scope
with
with
those
changes
that
this
can
apply
to
enterprise
isp
mobile
networks
and
using
the
provisioning
domains
and
a
key
that
we're
adding
to
indicate
where,
where
those
resolvers
are
located
next
slide,
please
so
one
of
the
one
of
the
changes
was
clarifying:
how
to
do
the
proof
of
authority.
Q
Q
Alternatively,
querying
a
local
dns
server,
where
the
answer
is
protected
by
dns
sec.
The
the
nuance
here
is
just
asking
locally
to
a
non-dns
sec
with
and
getting
back
a
non-dns
protected
answer
doesn't
tell
us
if
this
is
really.
You
know
true
for
the
public
dns
and
we're
trying
to
prevent
that
from
you
know,
someone
pretending
to
be
apple.com
microsoft.com
when
they're
in
a
when
you're
visiting
a
coffee
shop
or
a
hotel,
or
something
like
that,
need
to
ask
a
greater
authority
to
find
that
out.
Q
The
second
bullet
is
if
the
rosette
matches,
or
is
the
sub-domain
of
the
adn,
we
use
that
to
establish
a
secure
connection.
If
those,
if
that
fails,
the
network
is
not
authoritative
and
we
don't
use
that
claim
of
authority.
That
claim
of
ownership
of
this
private
domain,
then
kind
of
to
handle
some
of
the
situations
that
barbara
was
bringing
up.
The
client
doesn't
need
to
perform
those
for
some
special
purpose
domains
such
as
home.arpa,
I'm
thinking
we
may
need
to.
I
I
I
don't
know
how
to
best.
Q
I
was
talking
with
some
of
my
authors
on
this
and
we
may
need
to
deal
with
how
we
have
a
registry
of
what
these
are
supposed
to
be
and
and
how
to
handle
this
going
forward,
because
we
seem
to
have
a
you
know,
both
a
itf,
sanctioned
and
then
non
non-sanctioned
things
like
dot
local
that
seem
to
be
might
need
to
be
handled
in
the
same
way.
Next
slide,
please,
and
then
this.
Q
This
is
one
where
I
expect
to
get
some
comments
back
so
the
discovery,
the
network
block
policy,
so
we
have
a
two
two
pvd
keys,
only
one
of
them
the
network
dns
only
is
interesting.
The
other
one
is,
is
the
text
that
the
human
is
supposed
to
read.
That
explains
why
it's
dns
only
true,
so
the
purpose
of
this
is
that
is
to
allow
the
network
to
say.
I
would
really
prefer
you
to
only
use
my
dns
servers.
Q
The
network
might
do
all
kinds
of
interesting
and
curious
blocking
the
client
might
do
all
sorts
of
interesting
and
curious
routing
around
those
blockings.
But
the
purpose
of
this
is
to
provide
a
shortcut
that
what
the
network
is
trying
to
do
is
block
things
and
is
trying
to
keep
the
user.
Keep
that
keep
that
device
to
only
use
those
local
dns,
because
it
wants
to
do
filtering
because
it
wants
to
do
whatever
it
wants
to
do.
Q
It
doesn't
enforce
it.
Doesn't
it
doesn't
require
that
the
client
honor
this
the
client
can
go
ahead
and
ignore
this
and
do
whatever
it
wants?
The
purpose
is
to
provide
information
to
the
user,
so
they
can
join.
That
network,
see
this
information
and
decide.
Oh,
this
is
bad
or-
and
this
can
be
done
automatically-
that
they
join
this
network.
They
see,
I
can
only
use
the
local
dns
for
what
this
network
policy
is
and
and
just
say,
okay,
I
don't
want
to
use
this
network
and
connect
to
a
different
one.
Q
Let's,
let's
drain
the
queue,
because
that's
really
the
last
slide,
and
then
we
have
a
comments
and
questions
slide
after
this.
L
Dan,
yes,
I
don't
think
this
is
necessarily
a
bad
idea.
I
I
guess
so
so
you
think
that
the
way
I
would
say
so,
I
think
again
I
guess
like
like
in
the
context
of
dnr.
What
I
would
say
is,
I
would
say,
like
here's
the
thing
I
want
you
to
use
and
then
don't
use
anything
else
for
the
two
messages
I
want
to
send
is
that,
like
basically
the
the
concept,
that's
basically
the
idea,
you
know
I
mean
I
think
one
one.
L
I
guess
one
thing
that
I
think
you
know
I
don't
know
I
think
dkg.
Maybe
that
may
be
about
them
for
the
mic.
But
when
I
say
this,
but
I
mean
I
know,
dixie
had
sort
of
talked
about
like
I.
I
don't
know
what
like
the
signal
would
be
but,
like
you
know,
like
they're,
maybe
this
is
a
tri-state
which
is
like
you
know.
I
really
wish
you
would
you
know.
I
have
no
opinion.
L
I
really
wish
you
would
and
if
you
do
I'll
try
to
block
you,
you
know
I
I
don't
know.
Maybe
that
just
goes.
Maybe
that's
like
mayor's
getting
too
fancy
and
she
goes
to
him
in
the
description.
I
don't
know.
I
don't
even
know
if
we
could
consume
this,
but
but
but
I
just
try
to
think
about.
What's
what's
like
what
the
useful
characteristics
are,
I
mean,
like,
I
guess,
yeah,
so
I
don't
know
tommy.
You
might
have
some
thoughts.
E
Yeah
so
yeah
thanks
dan
for
presenting
this,
I
want
to
split
up
the
split
dns
from
the
filtering
policy.
Part
or
like.
Can
you
use
this
another
one?
So
I
think
this
dns
stuff.
I
think
it
makes
a
lot
of
sense
as
it's
there.
I
think
you
should
adopt
it
and
work
on
that,
because
I
think
to
barbara's
earlier
point.
You
know
it's
a
useful
piece
of
this
puzzle
and
something
that
local
networks
often
are
missing
when
compared
to
a
vpn,
for
example.
So
let's
do
that.
E
I
agree
generally
with
ecker's
sentiment
on
this.
Like
it's
an
interesting
area,
I
would
prefer
to
see
it
not
be
in
this
document
but
be
split
out,
because
I
think
I
I
think
there
can
be
more
done
here,
and
this
is
an
area
that
we've
been
thinking
about
a
lot
and
I
think
there
are
different
scenarios.
There's
some
scenarios
where
you
want
to
say,
like
okay,
do
not
use
anything
other
than
me.
We
need
to
see
everything
for
policy
reasons
and
yes,
you're
right,
you
can
just
choose
to
join
the
network
or
not.
E
I
think
there
are
other
things
that
we've
looked
at
for
putting
in
a
pvd
json
file
or
a
captive
json
file.
That
maybe
are
like
you
know,
hey
here's
other
resolver
information.
You
can
access,
maybe
in
a
private
way,
like
what
we're
doing
for
oblivious
dough.
That
still
can
get
the
filtering
you
want,
but
we
don't
track
your
ip
or
maybe
here's
a
like
a
safe
browsing
type
server
that
can
make
sure
it
does
the
right
filtering
on
you.
So
I
think
there's
we
could
kind
of
explore
more
options
in
here.
E
H
Yeah
ben
schwartz.
I
also
think
these
topics
have
to
be
split,
they
seem
pretty
unrelated
and
they
seem
each
one
of
them
seems
very
meaty.
I
think
it's
just
confusing
to
have
them
in
the
same
place.
O
H
I
I
I
do
have
some
some
real
concerns
here.
You
know.
Fundamentally,
there
are
a
lot
of
people
in
the
world
who
join
networks
and
who
have
very
little
choice
in
what
networks
they
join.
H
I
think
we
need
to
be
very
careful
about
how
we,
how
we
enable
networks
to
impose
impose
these
kinds
of
restrictions
on
users
there.
Those
restrictions
are
going
to
be
used
in
ways
that
you
don't
like
if
they
can
be
so
I'm
really
interested
in
how
the
scope
is
restricted
to
enterprise
networks.
You
know,
if
is
that,
really
such
a
firm
restriction
that
we
can
rely
on.
C
Yeah,
I
think,
split
horizon
is
really
important,
that
it
is
supported.
So
so
we
get
this
in
this
two
parts
of
the
last
two
sets
of
comments.
So
I
think
the
first
of
the
dot
com
is
incredibly
important.
I
think
specifically
for
split
horizon
being
able
to
have
this
policy.
Expression
is
important
as
well,
so,
whether
it's
included
in
here
or
referenced
in
here
but
but
the
details
are
covered
in
a
separate
document.
C
I
don't
think
it
matters
either
way,
but
it,
I
think
it's
it's
a
necessary
adjunct
to
split
horizon,
so
we
are
that
either
needs
to
be
developed
separately
and
referenced
from
here
or
it
has
to
be
in
here,
absent
it
being
developed
somewhere
else.
So
I
think
both
parts
are
equally
important
for
the
split
horizon
use
case.
Thank
you.
Okay,.
A
B
Q
All
right,
another
short
one
next
slide
please.
So
this
is
text
that
was
pulled
out
based
on
working
group
comments
pulled
out
of
dnr
and
into
its
its
own
spec,
because
it
was
thought
to
be
better
next
slide.
Q
So
the
current
most
of
the
text
is
the
same
there.
There
have
been
a
couple
of
tune-ups
that
we've
done
here,
but
this
is
managed
and
unmanaged
home
routers.
So
what
we?
What
we
really
mean
there-
and
this
is
in
the
document-
is
managed
by
the
isp
versus
managed
by
the
home
by
the
consumer,
and
it
covers
both
fixed
and
cellular
networks
as
well.
Q
So
the
and
legacy
cpe
are
discussed
in
here,
as
well
as
managing
unmanaged,
dv
provisioned
certificates
for
those
devices
and
how
to
get
those.
So
this
is
taking
us
down
the
steps
of
how
to
solve
again
some
of
the
issues
that
barbara
highlighted
in
her
presentation,
but
again
splitting
this
out
in
a
way
that
we
hope
will
be
more
applicable
to
both
ddr
and
dnr.
Q
That's
about
it.
The
next
slide
is,
is
you're
interested
in
maintaining
this,
and
it
feels
like
it's
going
to
be
some
informational
document
with
the
direction
that
us
authors
are
currently
taking
it,
and
I
I
haven't
seen
a
lot
of
discussion
on
this
other
than
you
know,
pull
it
out
of
our
our
dnr
document.
Q
If
this
has
a
lot
of
standing
power
by
itself
or
if
we
just
need
to
turn
the
crank
on
this,
so
we
need
some
need
some
encouragement
to
keep
doing
that
or
just
a
plus
one
on
the
mailing
list,
or
here
or
whatever.
But
that's
that's
about
it.
What
I
have
for
this
document.
B
So
let
me
jump
in
this
chair
and
and
say
this
within
this,
the
charter
of
the
group.
We
do
in
fact
have
a
line
item
to
develop
informational
documents
that
cover
this
kind
of
territory,
so
it
would
fit
very
well
within
the
charter
if
we
wanted
to
carry
that
forward,
as
you
suggest.
O
H
Ben
schwartz,
I
I
think
this
kind
of
document
could
be
useful,
but
it
seems
awfully
early
to
be
providing
effectively
implement.
You
know
operational
guidance
for
a
standard
that
has
not
yet
been
implemented
or
deployed.
Okay,
I
think
you
know
we're
we'll
be
much
better,
we'll
do
a
much
better
job
with
this.
If
we
have
some
actual
deployment
experience
to
base
our
recommendations
on.
R
S
Hey
good
morning,
good
afternoon,
just
in
response
to
ben
that's
an
argument
to
not
push
the
document
through
to
a
last
call,
not
an
argument
to
to
avoid
to
to
not
adopt,
and
in
fact
arguably
would
be
sort
of
cool
for
this
group
to
have
some
operational
documents
like
that.
Where
you
track
deployment
as
as
you're
developing
implementations
and
getting
a
little
bit
of
experience
and
then
just
documenting
it
where
what
dan's
done
were
similar.
A
D
I
think
there's
it's
always
worthwhile
to
have
a
spot
where
we
can
actually
collect
operational
experience
so
technically
that
that
also
means
that
if
we
adopt
it
would
probably
be
the
last
one
that
we
actually
finished
and
I
wouldn't
be
sure
if
it
would
actually
become
an
rc
in
the
first
place,
then
so
so.
But
but
I
think
we
do
need
a
spot
where
we
kept
operating
considerations
for
future
discussions
because
it
it's
easily
lost
on
the
mailing
list
and
that
all
the
things
that
barbara
talked
before
could
have
characters.
B
So,
just
just
close
us
from
the
chair's
perspective.
What
I'm
hearing
potentially
is,
we
might
consider
doing
a
adoption
call
for
the
group,
for
the
document
is
that
sort
of
what
I'm
picking
up.
B
Okay,
it's
good
to
know
all
right
moving
on
to
our
next
presenter,
so
we're
moving
to
our
last
topic,
which
is
number
six
which
is
ben.
Are
you
or
tommy
going
to
talk
to
this
one
or
both?
Are
you
going
to
talk
to
this
one.
H
Well,
I
am
happy
to
I'm
happy
to
do
it,
but
I
think
you
have
to.
B
H
Okay,
well,
forgive
me
if
I
click
the
wrong
button
at
some
point.
B
H
Okay
thanks
so
we're
back
to
the
first
topic,
we're
talking
about
this
scenario,
where
there's
a
forwarder
between
a
client
and
a
recursive
resolver.
The
forwarder
is
just
sitting
on
some
private
ip
address.
It
doesn't
have
any
other
known
identity,
the
recursive
resolver
it's
pointing
at
actually
does
support
an
encrypted
transport
like
dot,
and
so
we're
trying
to
figure
out.
H
Can
the
client
get
dot
in
this
scenario,
and
as
as
tommy
and
barbara
have
both
mentioned,
this
is
actually
in
our
adopted
requirements
that
that
the
client
can
learn
about
this
forwarder
and
presumably
upgrade
otherwise.
Why
do
they
want
this
information?
So
what
are
we
talking
about?
We
are
talking
about
legacy,
forwarders,
forwarders
that
do
not
implement
any
of
this
stuff.
H
L
I
don't
think
I
read
that
text
the
same
way
you
do
like.
I
read
that
text
as
doing
something
the
ddr
already
does,
which
is
saying
that
you,
if
a
local
resolver
afford
that,
does
our
frequency
death
service,
then
you
show
the
same
queries
that
forward
and
let
you
learn
about
the
external
encrypted
dns
servers,
not
that
I
have
to
end
up
talking
to
the
forwarder.
H
Sure
so,
there's
there's
an
a
way
to
read
ddr
that
says:
yes,
we've
satisfied
these
requirements
because
we've
gotten
you
this
information,
but
ddr
says
you
cannot
use
this
information.
You
will
never.
There
is
no
use
for
this
information
and
therefore,
if
you
are
at
all
able,
you
should
prevent
the
client
from
getting
this
information,
because
it's
useless
and
will
just
waste
their
time.
H
H
H
Okay,
let's
talk
about
that
in
a
minute
or
two,
so
just
to
be
clear:
we're
talking
about
legacy,
forwarders,
forwarders
that
have
not
been
updated
in
any
way
based
on
any
of
the
stuff
that
we're
writing
here.
H
So
this
is
the
question
your
client,
you
got
a
you
were
told
a
dns
server
address
it's
in
the
private
space.
You
sent
a
query
for
this
special
name
and
the
server
forwarded
it
to
an
upstream
resolver,
which
actually
has
something
to
say
the
forwarder
sent
it
back
to
the
client.
So
you
got
this
response.
What
do
you
do?
H
H
Okay,
that's
a
little
unusual.
We
don't
normally
have
security
requirements
that
are
phrased
in
this
way.
H
Why
are
we
talking
about
this?
So
this
changes
the
security
posture
of
the
the
client
in
ddr02
when
you're.
In
this
scenario,
the
connection
remains
totally
unencrypted,
you're
vulnerable
to
a
passive
attack
and
with
this
change,
you're
no
longer
vulnerable
to
passive
monitoring,
because
you
can
upgrade
to
the
encrypted
connection.
H
But
one
interesting
change
here
is
that
the
vulnerability
to
active
adversaries
is
very
slightly
different.
So
if
there
is
an
active
adversary
on
the
local
network,
that
adversary
can
prevent
you
from
doing
ddr.
So
they
can
continue
to
monitor
your
your
dns
queries
with
this
change.
It's
not
that
the
active
adversary
has
to
be
present
right
now.
H
H
H
So
the
my
my
conclusory
point
here
is
pr
number.
11
is
essentially
what
you
have
to
do
as
a
client.
If
you
want
to
get
essentially
a
ddr
like
auto,
upgrade
in
a
forwarder
scenario-
and
you
know
there
are
some
details
that
we
could
certainly
tweak,
but
it's
it's
fundamentally
a
question
of
what
do
what
we
want,
whether
we
want
to
include
that
in
scope
for
the
working
group
or
not
and
I'll,
let
tommy
give
his
thoughts
on
on
how
we
ought
to
proceed.
N
Ben
did
a
good
job
walking
through
the
pr.
We
spoke
ahead
of
time
to
talk
through
the
trade-offs
as
seen
on
the
list.
I
I
don't
think
this
pr
belongs
in
ddr,
not
because
the
scenario
is
not
worthy
of
address,
but
actually
because
I
think
it
it
needs
to
be
addressed
separately.
N
The
trade-offs
that
ben
just
walked
us
through
show
that
there
are
trade-offs
that
aren't
just
a
subset.
It's
not
like
one
is
the
more
correct
answer
for
all
clients
as
a
result
in
ddr.
If
the
validation
fails,
then
at
that
point
it
could
be
an
active
attacker
that
we're
connecting
to
a
client
deciding
whether
to
continue
to
act
on
that
information
or
not,
is
making
a
security
versus
versus
a
functionality
kind
of
trade-off
because,
as
ben
said,
there's
a
nuance
there,
you
are
adding
some
security
against
passive
observation.
N
If
we
keep
it
in
ddr
it,
it
doesn't
make
sense
to
add
more
requirements
and
say,
if
you,
if
it
fails
the
upgrade,
then
you
should
do
this,
where
you
do
the
waiting
period.
If
the
client
is
unwilling
to
take
that
step,
not
all
clients
will,
and
so,
if
we
separate
them
as
two
mechanisms,
where
ddr
stops
there
and
says,
if
that
doesn't
work,
ddr
ends,
you
can
do
mechanism
x,
follow
this
draft's
guidance
where
it
can
have
its
own
must
and
shoulds,
because
some
clients
want
to
do
both.
N
Some
clients
may
only
want
to
do
the
one
that
may
not
even
be
interested
in
ddr,
because
they're
entirely
focused
on
this
case.
Some
will
want
to
always
guarantee
the
identity
of
the
resolver.
So
I
do
think
this
is
good.
Work
and
ben
has
put
a
lot
of
work
into
revving
this
pr.
I
just
think
it
deserves
its
own
document.
H
Space,
okay,
I
guess
I'll
I'll
run
the
queue
eric
yeah.
I
just
want
to
express
strong
support
for
this
mechanism.
I
think
it
solves
one
of
the
most
important
things
for
the
80d
working
group
to
solve,
which
is
we've
previously
just
informally
called
this
85
percent
problem,
and
I
don't
really
have
a
strong
policy
over
whether
it
should
be
in
ddr
or
should
be
its
own
separate
draft
either
way.
H
But
yeah
I
mean
the
the
reason
I'm
strong
is
for
this
because
it
solves
every
every.
The
important
problem
is.
I
think
this
mechanism
does
a
sufficient
job
solving
the
security
issue
that
there
would
have
been
this
upgrade
to
the
attacker
vulnerability.
Having
turned
a
transient
attack
into
a
persistent
attack.
The
repeater
request
solves
that
issue.
The
one
thing
this
doesn't
completely
solve.
That
was
why
I
was
originally
against
this
proposal.
Is
the
the
user
intent
scenario?
This
is
essentially
all
everything
that
barbara
stark
was
talking
about
earlier
in
this
session.
H
I
don't
think
this
completely
solves
that
if
a
client
just
uses
this
willy-nilly,
but
that's
a
policy
matter
up
for
clients,
and
so
as
long
as
we
make
the
client
aware
that
the
user
might
want
this,
then
it's
up
to
the
client
to
make
good
decisions
around
that,
and
I
can
foresee
certainly
good
decisions
client
can
make
around.
Maybe
the
client
only
uses
this
information
in
a
configuration
ui
where
the
user
is
specifically
saying?
H
Yes,
I
want
to
do
this
upgrade,
and
the
client
has
just
used
this
information
to
make
one
of
the
options
there
or
maybe
it's
a
matter
of.
We
only
do
that
for
a
couple
years
and
then
a
couple
years
from
now
down
the
line
when
all
the
resolvers
have
gotten
useless
and
most
resolvers
just
have
automatic
support
for
filtering
out.
Resolver.Arpa
and
just
a
few
remaining
ones
can
manually
go
and
add
a
filter
option
for
that,
then
it
then
becomes
more
more.
H
It
becomes
more
realistic
for
clients
who
then
starts
doing
an
automatic
upgrade
because
the
ecosystem
is
adapted
and
is
capable
of
preventing
the
user
intended
behavior
from
being
bypassed
so
all
around.
I
think
this
is
a
great
mechanism
we
should
be
putting
it
in
and
we
should
be
fully
supporting
it
so
either
within
ddr
or
its
own
standalone
dock
either
way
sounds
like
a
great
way
to
go.
E
Yeah,
so
I
think
that
earlier
point
about
you
know,
you
don't
really
know
if
this
is
a
blindfold
or
or
it
has
a
special
filtering
that
you
added,
because
you
put
a
pie,
hole
on
your
network
or
something
because
you
don't
know
that
this
is
not
safe
to
do
automatically
full
stop.
E
If
you
want
to
do
something
like
this,
I
think
you
need
to
have
much
more
understanding
of
the
nature
of
the
forwarder
and
the
user
intent
and
until
you
have
that,
and
until
you
have
some
protocol
mechanism
to
do
that,
so
it's
not
actually
a
user
choice
or
a
policy
choice.
This
cannot
be
something
that
we.
E
Be
part
of
ddr,
so
I
I
don't
think
that's
appropriate
at
all.
If
you
could
go
back
to
slide
nine.
E
Here
I
I
want
to
clarify
a
couple
things.
You
know
first
yeah
on
the
passive
attack.
You
know
yeah,
it's
not
great
to
remain
unencrypted
both
I
I
I
don't
think
that
you
know
there
are
no
ways
if
we
keep
pinging
every
five
minutes
that
you
can
still
like,
you're
still
going
to
be
downgradeable
to
something
that's
unencrypted.
I
don't
think
that's
the
main
problem
here.
I
think
my
huge
concern
with
pr
11
is
that
in
the
active
adversary
case,
it's
a
different
sort
of
attack.
E
You
know
with
ddr,
you
can
downgrade
someone.
You
can
get
them
to
talk
to
the
resolver
they
would
have
talked
to
anyway,
but
with
pr11
within
a
five-minute
period.
You
can
redirect
someone
to
a
completely
different
resolver
without
user
intervention
and
have
no
one
else
be
able
to
tell
what's
going
on.
E
So
it's
it's
a
very
different
type
of
hijacking
attack
that
you're
opening
yourself
up
to
and
it's
unclear
if
it's
worth
that
regarding
some
of
the
points
around
frequent
lookups
to
kind
of
on
that
same
slide
of
slide
nine
to
not
have
an
attack,
you
know
every
five
minutes.
I
think
that
would
be
a
good
thing
to
maybe
add
into
the
ddr
security
considerations,
to
say
that
you
know
you
can
continue
to
do
lookups
periodically.
E
If
you
didn't
get
a
response
before
in
case
someone
was
intentionally
dropping
your
packets
or
putting
garbage
in
them
so
that
that's
something
that's
good
to
do,
but
that's
very
different
from
saying
you're
gonna
upgrade
to
something
that
you
cannot
trust.
H
Tommy
I
wanna.
I
am
curious
about
about
how
you
think
about
the
the
difference
in
the
active
attacker,
because
because
in
ddr
an
active
attacker
can
always.
E
E
H
An
active
attacker
has
to
have
active
control
of
that
address
in
both
cases
in
order
to
mount
the
attack.
That
is
the
address
that
the
active
attacker
must
control
in
pr
number
11.
The
attacker
needs
to
be
able
to
needs
to
be
able
to
intercept
and
and
respond
to
your
query,
which
is
going
to
that
address,
so
it
needs
to
be
able
to
both
read
traffic
going
to
that
address
and
write
traffic
coming
from
that
address.
So
it
owns
that
attacker
owns
that
ip
address.
E
E
Here
you
have
a
one-time,
udp
kind
of
reading
and
injection
attack,
yes
of
a
packet
to
then
redirect
you
to
a
ip
address
that
they
control
that
now
they
can
have
a
much
easier
time
for
the
next
five
minutes.
Yes
of
just
scooping
up
your
traffic
in
current
ddr,
you
have
to
essentially
control
all
tsp
communication.
H
E
H
Yes,
you
have
to
the
difference
is
that
you
have
to
maintain
continuous
control
of
the
ip
address
versus
having
control
at
the
moment
of
discovery.
That's
the
key
distinction.
H
N
Yes,
oh
camera
button
didn't
work,
so
one
thing
to
call
out
here
regarding
regarding
the
ddr
vulnerability
to
passive
attack.
That
assumes
that
the
client,
when
ddr
fails,
goes
back
to
plain
text
dns,
which
is
a
fair
assumption,
because
by
default,
that
probably
is
their
only
option
available.
However,
getting
back
into
that
scary
area,
where
we
say
we
leave
out
of
scope,
client
policy
and
the
reason
why
I
think
that
a
separate
draft
makes
sense
here
is
that
not
all
clients
may
do
that
there
may
be
clients
that
have
their
own
last
resort,
encrypted.
N
Dns
resolver,
that
they're,
aware
of
that
they
say
that
if
they
can't
find
a
user
preferred
one
they'll
use
their
own.
In
that
scenario,
ddr
would
actually
be
the
preferred
option,
because
if
that
fails,
we
they
want
to
stop
there
and
go
do
their
thing,
and
if
pr11
were
to
be
a
next
step
requirement,
I'm
not
saying
that
it
is,
but
if
it
were
that
would
it
would
be
hard
for
a
client
to
say
I
do
ddr
up
to
a
certain
point
and
then
I
deviate.
N
Whereas
if
it's
a
separate
mechanism,
some
clients
may
say
I
try
ddr.
If
that
doesn't
work,
I
try
pr11,
some
clients
will
say
if
ddr
doesn't
work.
I'll
fall
back
to
my
own
thing.
Some
clients
yeah.
H
Does
that
make
sense
yeah,
I
think
I
understand
you
know
to
to
generalize.
I
think
we
could
say
that
all
of
these
distinctions
are
entirely
within
the
realm
of
of
client
behavior,
yes,
and
what
we're
trying
to
figure
out
is
which
client?
What
are
the
consequences
of
some
different
client
behaviors?
H
Is
there
a
free
lunch
here
with
a
better
client
behavior,
and
you
know
what
client
behaviors
are
actually
out
of
bounds
that
they're
effectively
undeployable.
N
Sure
and
so
yeah
I
to
what
I've
said
before
I.
I
think
that
I
think
that
pr
11
isn't
always
the
better
answer
to
other
alternatives,
even
though
it
is
a
good
answer.
We
probably
should
provide
some
mechanism
for
because
it's
it's
been
made
clear,
that
the
ecosystem
is
interested
in
a
signal
if
it,
even
if
it
cannot
be
authenticated.
B
So
this
is
our
planning
wrap
up.
So
let
me
update
a
few
things
that
are
going
on
around
the
group.
Some
documents
are
in
influx
so
or
in
in
developing,
so
there
is
a
draft
that
ben
schwartz
submitted
earlier
to
and
it's
in
the
list
of
the
working
group
ids
around
service
b
for
the
purposes
here
ben
is
and
ben.
I
don't
mean
to
speak
for
you,
but
I'm
gonna
so
correct
me
where
I
get
it
wrong.
Ben's
gonna
make
an
update
to
service
b.
B
We've
been
waiting
on
the
service
b
document
to
go
through
the
main
document
to
go
through
the
process
that
it
was
going
through.
Now
that
I
guess
that's
done,
it's
ready
for
ben
is
going
to
do
an
update
and
then
I
see
you
just
jumped
in
the
queue.
So
if
you
want
to
speak
up,
but
our
intention
is
ultimately
to
bring
the
document
to
benzema,
to
talk
about
to
the
group
for
consideration
because
there's
dependencies
on
it
and
then
bring
it
forward
for
a
adoption
call
so
ben
go
ahead.
H
Yeah,
the
the
new
draft
provision
is,
is
out
as
of
july
26th.
So
so,
whenever
you're
ready.
B
B
The
other
thing
I
want
to
point
out
is
you
know:
we've
been
having
some
good
discussion
today,
the
there
we
can
continue
this
discussion
on
list.
We
also
have
these
things
like
that.
The
pull
request
11
are
available
as
issues
within
the
github.
So
if
you
want
to
make
comments
there,
you
know
tail,
and
I
myself
were
talking
the
other
day
about
what
what
to
do
next
and
whether
we
need
an
intern.
So
part
of
our
feeling
was.
B
If
these
issues
really
need
like
an
extended
discussion,
then
potentially
we
might
consider
something
for
after
labor
day
in
the
september
time
frame,
we
haven't
definitely
said
we
want
to
do
that
yet,
but
we'll
sort
of
look
at
the
list-
traffic
and
the
github
traffic
and
sort
of
try
to
get
a
sense
in
the
next
week
or
two
once
we
all
recover
from
111
if
there's
activity
and
after
warrant,
maybe
a
couple
special
issue,
discussions
in
a
interim
in
mid-september,
but
nothing's
set
as
of
yet
so
if
you
have
opinions
on
that
drop,
the
notes
of
the
chairs-
and
you
know,
make
suggestions
on
things
you
want
to
tackle
anyway.
B
P
A
You
this
is
where
we
keep
the
praises
on
our
note
takers.
Thank
you
for
ietf
newcomer
hazel
smith
for
being
a
very
copious
notetaker
and
to
long
time,
correspondent,
tim
wazinski
for
helping
out
there
too.
Thank
you
both
very
much.
N
With
this
off
list
sure
leading
question,
I
I
wasn't
watching
all
of
the
chat.
I
wasn't
sure
if
there
was
a
clear
working
group
signal
on
what
the
future
of
pr11
should
be.
B
A
Yes,
so
I
I
think
that
that
demonstrates
that
there
was
not
a
clear
consensus
and
that
we
should
ask
one
more
time:
tommy,
pauly,
okay,
I
think
it's
fine,
separate
doc
seems
reason.
The
chat
now
seems
to
be
coming
to
be
coming
to
a
clear
consensus,
so
sometimes.
B
That
all
it
takes
is
asking
that
question.
So
look
we'll
I'm
gonna,
you
know
as
we're
running
these
things,
it's
sometimes
impossible
to
follow
all
the
pieces.
I
know
I'll
go
back
over
and
review
the
comments
being
made
and
listen
to
the
recording,
I
think
and
then
my
co-chair
and
I
we
can
chat
and
we
can
see
what
our
recommendation
to
the
group
will
be
going
forward,
whether
we
do
one
way
or
do
the
other
way
and
whether
we
do
a
consensus
call
on
this
topic.
So.
A
A
G
B
Well,
I'm
gonna,
I'm
just
about
to
run
one
of
the
polls
so
show
of
hands
on,
should
it
be
we'll
do
a
separate
doc.
Raise
your
hand
if
you
do
agree
that
it
should
be
pulled
to
a
separate
dock.
P
A
The
in
the
past,
because
of
this
ambiguous
signaling
we've
taken
do
not
raise,
is
an
affirmative
rejection
of
the
proposal.
If
you
just
don't
care,
then
you
don't
register
an
opinion.
B
Well,
you
know
we
can
do
we
can
do.
We
can
do
a
back
to
back
whichever
eric
do
you
have
a
recommendation.
H
Hi,
this
is
ben
schwartz.
I
I
think
that
you
know.
As
author
of
pr11,
I
think
that
I
have
clear.
I
have
a
clear
signal
that
this
is
not
going
to
go
into
the
ddr
draft
itself.
I
think
the
interesting
question
for
the
working
group
is
do
we
want
to
do?
We
want
to
attempt
to
offer
some
some
guidance
in
a
new
draft
for
for
how
to
address
r,
4.1
and
r
4.2.
B
Okay,
I'm
just
adding
that
to
the
notes
here
then
all
right,
so
we
run
the
poll
and
then
we
can
do
raise
if
you
agree
don't
raise.
If
you
disagree.
A
Yeah,
okay:
well,
there's
going
to
be
a
remarkable
turning
of
the
tide.
So
so,
while
that's
while
we're
giving
it
those
couple
of
more
seconds
for
glenn
to
be
satisfied
that
enough
people
have
responded,
hazel
did
mention
in
the
chat
that
apparently
there
was
a
third
person
taking
notes.
If
you
would
just
please
add
yourself
up
in
the
top
of
the
dock,
so
we
can
credit
you
for
also
helping
out.
B
B
A
B
B
I
don't
know
either.
Maybe
somebody
can
throw
in
the
notes
the
the
the
the
question
just
copy
the
question
down
and
then.
A
A
Muffet
also
reports
that
it
did
get
captured.
So,
oh
okay,
so
I
think
we're
good.
I
think
this
is
where
you
can
all
start
bailing
out
a
jabber
and
thank
you
very
much
for
attending
add
at
ietf111.
A
We
will
keep
you
apprised
of
the
likely
chance
of
an
interim
in
september.
B
And
yeah
thank
you
for
attending.
We
got
done
early.
Thank
you
to
all
presenters
for
keeping
us
on
track
and
for
tale
for
managing
the
cube.
Take
care.
Everyone
bye.
F
A
I'm
I'm
happy
that
we've
gotten
to
this
point
with
fewer
bloodied
knuckles
than
I
imagined
seeing.
R
May
I
please
beg
a
favor.
I
haven't
yet
had
a
chance
to
test
my
presentations.
Oh
yeah
yeah
screen
share
and
I
was
wondering
if
I
could
use
this
opportunity
to
just
check
the
software
works.
You.
A
You
bet
just
add
it
to
the
queue
and
ask
to
share
a
screen.
R
A
And
hazel
again,
thank
you
very
much
for
your
very
brave
act
of
stepping
up
to
to
do
that.
T
Yeah,
I
was
meaning
to
ask
how
I
don't
know
whether
you've
been
looking
at
them.
How
were
my
notes.
B
I
I
glanced
a
few
times
and
they
were
fantastic.
So
thank
you
so
much.
Okay,
I'm
they
have
a
career
ahead
in
in
transcription.
T
I
I
was.
T
Myself
at
my
wrist
for
saying,
I
heard
her
towards
the
end
that
that,
if
only
if
only
stenography
keyboards
were
cheaper,
yeah.
A
A
Does
that,
as
you
may
well
know-
and
I
am
continually
amazed
by
their
oh
you,
I
thought
I
had
approved
your
screens
there
we
go
again.
C
T
A
T
Be
really
good
because
for
people
who
need
captions
live
sort
of
machine
generated,
auto
captioning
live
tends
to
be
pretty
rubbish.
A
Exactly
alec,
are
you
all
set,
or
I
I
am
all
set,
thank.
A
The
gathered
up
town-
I
don't
have
the
link
handy
glenn,
do
you
have
it
that
you
could
just
I.
A
It
handy
it's,
it's.
B
T
Okay
cool,
I
might
check
that
out.
Well,
this
was
my
first
ietf
event.
I've
ever
taken
part
in
it
was
good.
I
I
I'm
glad
I
was
able
to
do
something
helpful.
A
Yeah,
it's
very
helpful.
Thank
you
thanks,
okay,
I
don't
know
meet
echo
if
you're
listening
on
this,
I
think
you
can
close
our
room
down
and,
if
you're
not
well,
we'll
just
time
it
out
for
the
next
five
minutes.
I
guess.