►
From YouTube: IETF108-DPRIVE-20200731-1410
Description
DPRIVE meeting session at IETF108
2020/07/31 1410
https://datatracker.ietf.org/meeting/108/proceedings/
A
Hello,
everyone
we're
gonna,
give
everybody
another
minute
or
two
to
join
the
meeting.
We
we
do
have
a
little
bit
of
extra
time
in
our
agenda
because
clearly
tim
and
I
do
not
know
how
to
do
math
and
tell
the
difference
between
100
minutes
and
50
minutes.
A
A
Yes,
that's
that's
actually
what
we
were
thinking
with
that
extra
time
and
and
as
long
as
you're
good
with
that
we'll
just
do
specific
questions
after
your
presentation,
then
we'll
have
an
open
discussion
after
paul's,
perfect.
A
A
All
right,
everyone,
let's
go
ahead
and
get
started.
I
want
to
welcome
everybody
to
the
the
last
session
of
ietf
108..
So
hopefully
everybody
is
still
awake
and
sane.
From
from
a
week
of
of
online
meetings,
I'm
brian,
I
have
tim
flying
co-pilot
with
the
slides
I
go
to
the
next
one.
Tim.
A
The
there
we
go
just
to
make
sure
everybody's
aware
we're
still
operating
under
the
no
well
and
the,
although
the
various
rules
apply
for
for
declarations,
and
things
like
that
and
if
you
haven't
read
all
those
bcps
do
that
after
this
meeting
next
slide.
Please
all
right.
The
nice
thing
here
is
that
we're
not
passing
blue
sheets
around
we're
not
signing
in
via
webex
chat
rooms,
we're
not
doing
things
in
etherpad.
The
nice
folks
over
at
eat
echo
we're
going
to
harvest
the
attendees
from
the
from
the
roster
on
meat.
Echo.
A
Quick
run
through
what
we're
going
to
do
today.
First,
one
is
dealing
with
with
the
agenda
we're
going
to
do
a
quick
update
on
some
of
the
current
workgroup
documents
and
then
we'll
slide
into
a
discussion
of
some
of
the
current
work.
That's
going
on
and
then
we'll
get
to
discussions
of
a
couple
of
new
workgroup
items
that
are
that
have
been
proposed
and
either.
A
A
All
right
document
updates,
so
first
one
on
the
list
is
a
7626
biz.
I
know
a
couple
of
you
have
asked
at
least
me
in
in
private,
and
I
know,
there's
been
a
couple
of
queries
on
the
mailing
list
as
to
what's
going
on
it's
sitting
in
revised
id
state
and
right
now
what
we've
been
doing
is
having
discussions
between
tim
and
I
and
and
eric
and
the
and
the
authors.
A
There's
been
some
questions
about
some
of
the
changes
that
have
gone
into
the
document
and
we're
we're
trying
to
make
sure
that
what
the
document
is
actually
doing
is
reflecting
the
consensus
that
came
out
of
the
working
group
and
that
changes
that
go
in
after
that
have
consensus
for
support
within
the
document.
So
that's
going
to
be
a
a
a
piece
of
work
that
the
chairs
and
our
ad
are
going
to
have
to
deal
with.
A
One
thing
that
I
will
point
out:
we
are
going
to
have
a
change
in
authors.
I
want
to
thank
the
authors,
especially
sarah,
for
for
pushing
this
document,
as
as
far
as
they
have
right
now.
The
that
editing
that
I
just
mentioned
as
far
as
making
sure
that
we're
we're,
including
the
document
that
the
content
that
has
that
has
consensus,
is
actually
being
worked
on
by
tim.
So
I'm
going
to
remain
the
document
shepard
and
we'll
be
working
with
with
eric
to
make
sure
that
everything
is
is,
is
good
to
go.
A
And
tim
disappeared,
I
can.
I
can
talk
through
some
of
these
with
without
the
slides
the
other.
The
other
main
thing
that
was
on
the
document
status
is
the
bcp
that
is
now
in
the
rfc
editor's
queue,
some
of
the
that
we
had.
We
had
some
minor
edits
to
resolve
isg
comments
during
their
review,
and
so
that
all
has
been
approved,
and
we
now
have
that
in
in
the
rfc
editors
queue
for
processing.
A
So
the
next
thing
for
us
is
to
wait
for
them
to
come
back
with
any
any
issues
from
a
from
an
editorial
perspective,
and
the
other
active
document
is
our
face
to
requirements.
Document
tim
is
actually
working
with
the
authors
to
make
sure
that
we're
we're
making
progress
on
this
document,
but
we
don't
have
an
update
for
this
meeting.
A
A
Okay,
so
then
we
were
we'll
go
on
to
the
presentation
of
the
zone
transfer
over
over
tls.
I
sarah
are
you
presenting.
D
E
E
C
C
So
a
little
bit
of
background
to
start
with
today,
all
zone
transfers
take
place
in
clear
text,
so
it's
possible
to
collect
the
contents
of
a
zone
by
passively
monitoring
that
on
the
wire
transfer,
but
there
are
lots
of
scenarios
where
the
owner
of
a
zone
will
desire
privacy
for
the
contents,
and
this
could
be
because
it
might
contain
personal
information.
C
C
C
Firstly,
we
could
we
want
to
point
out
that
using
either
single
or
mutual
tls
can
provide
complementary
authentication
to
existing
techniques,
mainly
tcg
and
acls,
and
we
discuss
the
characteristics
of
each
of
the
types
of
mechanism
in
the
draft.
C
Secondly,
what
we've
noticed
is
that
many
of
the
existing
implementations
when
they
do
transfers
are
sub-optimal.
The
reasons
for
this
are
probably
historic,
partly
because
they
had
to
be
backwards
compatible
with
very
early
implementations,
but
we've
seen
in
a
number
of
cases
that
the
secondary
will
open
up
a
single
tcp
connection.
C
C
C
On
the
right
hand,
side
we
have
what
we're
proposing
for
zot
based
ixfr,
and
in
this
case,
what
we're
proposing
is
that
the
ixfr
requests
and
responses
are
guaranteed
to
happen
encrypted.
So
all
of
those
exchanges
must
happen
on
a
tls
session
optionally.
In
fact,
we
recommend
that
the
soa
is
also
sent
over
the
open
tls
session.
C
C
Probably
the
most
significant
one
is
that
in
this
latest
version
of
the
spec
we
introduced
the
use
of
alpn
for
transfer
specific
connections.
So
alpn
is
an
application
layer,
protocol
negotiation,
it's
a
parameter,
that's
sent
from
the
client
to
the
server
in
the
tls
handshake
so
that
the
client
can
indicate
which
protocol
that
connection
will
subsequently
be
used
for
and
in
the
ot
version
of
the
spec.
C
We
introduced
a
new
alpn
option
called
zot
and
we've
refer
to
connections
that
are
initiated
with
that
parameter
as
zop
connections,
and
the
important
thing
to
note
here
is
that
we
then
limit
which
queries
can
be
made
from
the
secondary
to
the
primary
on
such
a
connection,
and
we
limit
them
to
its
fr,
xfr
requests
and
soa.
Only
so,
what's
the
rationale
for
this
decision.
C
Well,
looking
back
at
some
of
the
earlier
specs,
we
noticed
that
in
rfc
5936,
which
is
the
draft
which
re-specifies
axfr,
that
it
has
a
statement
in
there,
that
a
tcp
connection
can
be
opened
for
axfr
traffic
and
that
afterwards
non-axfr
session
traffic
can
also
use
that
open
connection.
C
So
we
don't
have
a
specification.
There's
still
a
lot
of
work
to
do
on
that,
and
we
don't
know
when
and
if
we're
going
to
arrive
at
consensus
on
that.
So
what
we
chose
to
do
with
the
zot
specification
is
to
remove
any
assumption
or
dependency
on
what
the
solution
for
adopt
might
look
like
and
also
remove
a
dependency
that
an
authoritative
implements
that
solution
in
order
to
support
zot.
C
C
We
are
just
keeping
the
specification
in
this
document
tight
so
that
it's
it's
simple
and
self-contained
one
other
thing
we
noticed
in
working
on
this
draft
is
we
went
back
and
re-read
rsc
7766
and
that's
the
document
that
specifies
the
implementation
requirements
for
dns
over
tcp
and
there's
a
section
in
there
which
talks
about
issues
around
the
recommended
number
of
clients.
C
Now
I
was
an
author
on
776
and
I'm
afraid
remembering
the
rationale
for
that
distinction
escapes
me.
If
any
of
the
other
authors
know
it.
Please
do
make
a
comment
on
that,
but
what
we've
done
for
the
zot
specification
is
we've
gone
back
and
done
a
minor
update
to
7766
simply
to
say
that
all
transports
tcp
and
those
on
top
of
it
should
behave
the
same
and
should
use
one
connection
for
regular
queries
and
one
for
zone
transfers
so
that
the
other
protocols
are
not
limited
to
having
a
single
connection
to
do
everything.
C
So
the
other
thing
that
the
o2
version
does
is
it
minimally
updates
rfc
1995.?
When
you
go
back
and
read
1995
you
it's
easy
to
see.
It
was
produced
in
the
days
when
tcp
really
wasn't
considered
a
first-class
transport
for
dns.
C
It
was
actually
produced,
it
was
published
in
1996,
and
so
it's
very
basic
in
how
it
talks
about
connection
reuse.
So
we
have
a
simple
update,
saying
that
it
should
follow
77.66
in
terms
of
connection,
reuse,
pipelining
and
out
of
order
responses
and
all
those
things
which
are
now
the
recommended
options
on
session
based
tcp.
C
We
have
a
bit
more
detailed
discussion
about
rsc
5936,
but
we
currently
don't
update
it,
but
what
we
do
do
for
zot
specifically,
is
optimize
the
mechanisms
compared
to
the
specifications
on
tcp,
because
zot
doesn't
have
the
burden
of
backwards
compatibilities,
so
some
of
the
dustier
corners
we
can
optimize
away
when
we're
describing
the
purezop
case.
C
One
of
the
other
things
we
updated
in
o2
was
the
discussion
of
padding.
We've
limited
the
discussion
now
to
two
areas.
One
is
the
goals
of
padding,
in
other
words,
what
problems
is
padding
trying
to
solve,
and
secondly,
what
we
wanted
to
do
was
identify
any
minimum
requirements
that
need
to
go
into
a
base
protocol
in
order
to
support
to
flexibly
support
any
future
padding
policies
we
might
develop.
C
The
one
thing
that's
in
the
draft
that
we've
identified
is
that
for
some
corner
cases
there
might
be
a
need
to
support
the
exchange
of
empty
axfr
packets,
so
those
are
packets
that
will
have
no
rrs
in
them,
but
they
will
have
an
eds
zero
option
which
can
be
padded,
and
this
is
really
just
about
future
proofing.
The
options
around
padding
that
that's
why
it's
mentioned
in
this
draft.
C
We
have
initial
an
initial
version
of
that
draft,
but
I
would
say
if
there's
anybody
in
this
session,
who
is
interested
in
collaborating
on
understanding
the
analysis
and
developing
padding
policies,
please
do
get
in
touch
with
the
authors,
because
we'd
be
very
happy
to
work
together
on
that.
C
Okay,
since
we
published
the
o2
version,
we
have
had
one
very
in-depth
review
on
the
list.
Thank
you
very,
very
much
tony
finch,
for
that
it
raised
a
lot
of
excellent
questions
and
we've
had
a
number
of
quite
in-depth
off
list
discussions,
and
this
has
raised
some
more
questions
and
comments
which
we
intend
to
address
in
the
next
version
of
the
draft
and
I'll
skip
through
those
on
the
next
couple
of
slides.
C
One
of
the
things
we
need
to
do
is
to
go
back
and
slightly
rework
how
we
propose
the
updates
to
the
original
specifications
for
rxfr
and
and
in
particular,
although
it's
it's
there
in
in
a
implicit
sense.
We
just
want
to
add
some
clarifying
text
around
what
happens
when
those
two
mechanisms
are
sharing
a
connection,
and
you
may
need
to
intermingle
the
responses
so
that
that's
really
just
clarification
about
that
behavior.
C
Another
topic
that
came
up
was
around
the
discussion
of
transfer
rates
or
limits
on
concurrent
xfrs.
Now
neither
of
the
original
specifications
discussed
this
at
all
it.
It's
not
mentioned
in
1995
or
5936
bind
has
some
controls
already
that
let
you
limit
the
number
of
concurrent
xfrs,
I
believe,
one
for
the
total
and
one
for
the
transfers
per
ns.
C
Another
topic
that
came
up
and
needs
to
be
addressed
in
a
bit
more
detail
in
the
draft
is
around
what
I'm
going
to
call
usage
profiles
in
order
to
give
them
the
same
name
that
was
used
when
we
developed
a
stub
to
recursive
case.
So
this
is
the
question
of
doing
strict
zot,
which
is
where
both
parties
are
configured
to
only
allow
the
transfer
over
a
zop
connection.
C
And
then
the
question
is:
are
there
use
cases
for
other
scenarios
now?
Obviously,
if
you
don't
want
privacy,
you
could
choose
to
opportunistically
use
zot,
but
you
have
no
guarantees,
but
the
question
is:
is
there
a
use
case
for
allowing
fallback
to
tcp
and
and
what
we
that
the
place
we
see
that
use
case
appearing
is
really
during
testing
and
roll
out.
C
C
Something
else
that
will
will
probably
add
text
on
the
discussion
is
around
the
configuration
of
the
certificates
on
the
server
now,
because
we've
introduced
an
alpn.
It's
now
easy
to
see
that
configuring
certificates
can
be
split.
C
If
you
choose
to
so,
you
can
choose
to
configure
certificates
on
your
primary
that
are
used
only
for
zone
transfers
and
then
any
future
credential
management
around
other
encrypted
forms
of
transport
can
be
orthogonal
to
the
zot
certificates
and
there's
been
a
little
bit
of
discussion
around
whether
or
not
it's
useful
to
have
a
single
certificate
with
possibly
multiple
sans
or
are
there
cases
where
operators
might
want
a
certificate
zone.
C
Most
of
the
implementations
that
we've
looked
at
use
name
compression
on
transfers,
but
the
use
of
name
compression
limits
the
packet
size
to
16k,
because
that's
as
far
back
in
the
packet
as
a
compression
pointer
could
look.
So
we
have
an
action
to
investigate
whether
or
not
for
zot
suggesting
an
option
to
disable.
That
is
useful
in
order
to
have
maximum
size
packets
for
the
transfer.
So
that's
very
much
an
open
question
last
slide.
C
So
specification
is
maturing.
Please
if
you
have
the
opportunity,
please
provide
a
review
on
the
list,
because
we
would
very
much
like
input
on
this.
We
are
starting
to
think
about
implementations,
we're
starting
work
on
a
patch
for
nsd,
and
we've
also
had
some
very
early
and
constructive
discussions
with
isc
on
support
and
bind
for
this.
C
C
We
are
aware
of
a
demand
from
a
number
of
organizations
who
would
like
to
deploy
this.
So
there
is
a
real
world
need
for
this
and
we
are
hopeful.
We
intend
to
update
this
draft
regularly
and
incorporate
feedback
from
the
implementation
that
works,
and
we
would
like
to
think
we'd
be
in
a
position
by
round
itf
109
to
progress.
It's
a
working
group
last
call
we
don't
think
we're
there
quite
yet
with
a
few
open
questions
yet,
but
that
that's
what
we're
aiming
for.
C
So
with
that.
I
that
concludes
the
presentation
and
I
believe
we
have
people
in
the
queue
and
some
questions.
Thank
you
very
much.
A
We
do
have
some
questions.
First,
one
up
is.
A
F
This
is
daniel
van
gilmer
from
the
aclu.
Thanks
for
doing
this
work,
I
just
had
questions
about
using
alpn,
given
that
alpn
is
in
cleartext
part
of
the
tls
handshake,
it's
definitely
identifying
itself
in
a
different
as
a
specifically
as
a
zone
transfer
in
a
way
that
a
connection
that
could
appear
to
be
a
normal,
a
dot
for
you
know
I'm
hand
waving
over
here
yeah.
F
But
if
someone
so
I'm
wondering
whether
you
have
any
thoughts
about
the
risks
of
distinguishability
between
zot
and
other
potential,
authoritative
dns
over
tls,
and
also
if
you
think
that
we
will
get
to
defining
authoritative
dns
over
tls
in
the
future,
what
are
the
impacts
of
having
a
different
having
of
moving
the
the
the
zone
transfers
into
a
visibly
distinct
category?
From
that?
F
Does
that
make
sense?
It
looks
to
me
like
like,
if
we
imagine
a
world
where
we
have
authority,
you
know
you
know
that's
over
to
us
to
the
authoritative.
All
of
a
sudden.
Now
we've
leaked
that
one
connection
is
a
zone
transfer
and
another
connection
is
not.
C
So
that
is
a
disadvantage,
but
some
initial
work,
looking
at
the
nature
of
the
traffic
might
indicate
that
even
with
padding,
unless
we
do
additional
work,
it's
going
to
be
relatively
clear
that
one
of
them
is
being
used
for
zone
transfers.
So
I
I
think
we
wouldn't
have
to
worry
about
just
about
the
aopm.
We
would
have
to
worry
about
using
padding
and
timing
to
make
the
traffic
indistinguishable,
which
I'm
not.
I
guess,
I'm
not
sure,
there's
an
appetite
for
that.
C
Yeah
and
there's
also-
I
mean
you-
there's
also
the
possibility
that
it's
possible
to
determine
which
name
servers
host
zones
by
you
know
doing
an
active
query
on
the
dns,
so
hiding
this
distinguishing
as
to
whether
something
make
a
connection
is
a
recursive
and
or
a
primary.
That's
hosting
a
zone
is
again
there's
sort
of
a
question
as
to
how
useful
that
is.
So
we've
we've
considered
the
primary
threat
model
here.
Protecting
the
zone
contents,
not
necessarily
protecting
the
idea
that
two
entities
are
engaging
in
zone
transfers.
F
Okay
yeah,
so
just
as
a
just
a
highlight
for
folks
who
are
thinking
about
this,
you
know
one
of
the
reasons
you
might
want
to
hide.
The
fact
that
this
is
a
zone
transfer
is
because
you
don't
want
an
adversary
to
identify
where
the
secondaries
are
or
where
this
distribution
is
happening.
I'm
not
sure
that's
particularly
plausible,
but
the
other
reason
to
try
to
to
detect
a
zone
transfer
would
be
to
prevent
it.
F
C
Absolutely
not-
and
I
hope
I
I
thought
I
said
that
on
one
of
the
slides
it
it
doesn't.
What
we're
saying
is
this
will
be
one
mechanism
that
can
be
used
to
do
zone
transfer
standalone
and
that
there
could
be
a
future
development
of
mixed
mode.
So
yes,
you,
you
can
use
one
connection
to
do
whatever
exchanges
you
like
and
that
may
have
no
lpn.
It
may
have
a
different
alpn.
C
Our
goal
at
the
moment
is,
is
really
to
decouple
ourselves
from
any
dependency
there.
So
we
we
don't
believe
we're
precluding
it,
but
we
think
there's
a
solution
that
we
can
move
forward
quickly
to
here.
That
is
decoupled
from
any
any
other
implementation
or
deployment
of
encryption
on
authoritatives.
B
E
B
One
problem
I
see
with
it
is
that
you
limit
to
xfr,
except
for
soa
partinus,
for
example,
might
also
do
ns
queries
as
part
of
an
odd
provisioning
mechanism.
We
have
further,
if
you
don't
do
the
lpn,
then
any
name
server
today
that
has
decent
tcp
handling
becomes
compliant
with
the
drafts
by
just
adding
a
tls
proxy
in
front
with
the
alpn.
B
Suddenly
new
code
has
to
be
written
and
you
have
two
code
parts
that
handle
different
are
types
in
queries
differently,
and
I
imagine
that
eventually,
we'll
have
some
adt
thing
that
might
not
need
to
be
separate
from
zots.
C
So
you're
right
about
the
proxy
question
and
it's
something
we
don't
discuss
in
the
draft,
but
it
it
is
an
issue.
But
that's
that's
already
an
issue
today
in
a
sense
that
some
of
the
some
of
the
specs
for
tcp
and
tls
might
be
subtly
different,
even
when
we
have
encryption
to
authoritatives
what
we.
What
we
didn't
want
to
do
was
to
force
authoritatives
to
answer
queries
over
an
encrypted
connection
if
it
hadn't
been
implemented
or
supported.
C
So
it's
yeah
the
swings
and
roundabouts.
In
those
two
discussions,
we've
we've
gone
with
the
alpn
because
we
feel
it's
it's.
You
know
it's
a
narrower
spec
and
it's
slightly
cleaner
and
there
is
absolutely
nothing
to
stop
a
secondary
opening
any
other
connection
to
that
primary.
To
do
any
other
question
query
at
once
in
clear
text
like
that's,
not
prevented
we're
just
saying
that
we
want
to
guarantee
the
encryption
for
the
actual
zone
transfer
itself.
F
C
F
C
Take
your
point
and
we
we
did
debate
back
and
forth
about
this
and
we've
jumped
for
the
alpn,
but
there
should
probably
be
a
bit
more
discussion
in
the
draft
about
the
rationale.
That's
certainly
true.
Yeah.
C
I
mean
so
one
thing
that
struck
me
when
I
sat
down
to
do
this
is
I
I
don't
know
when
that
spec
is
going
to
appear.
I
don't
know
what
form
of
credentials
are
going
to
be
involved
in
authenticating
that
connection,
and
I
don't
even
want
to
count
on
it
being
over
tls
it
could.
It
could
be
that
we
take
long
enough
that
we
end
up
switching
to
quick
yeah
and
we
think
we
can
get
zap
implement.
You
know
we,
we
can
nail
down
spec
and
we
can
get
it
implemented
and
pushed
out.
C
You
know
we'd
like
to
be
thinking
the
end
of
this
year
and
removing
the
dependency
on
the
on
the
a
dot
discussion
is
attractive
when
you
look
at
it.
From
that
point
of
view,
reducing.
C
B
D
Hi
sana
nice
work
you're
talking
about
the
raft
a
little
bit
about
rate
limits
and
stuff,
like
that,
I
wonder
if
it's
worthwhile
considering
things
like
tls
session
ticketing
and
session
resumption
stuff,
and
maybe
that
has
to
wait
until
we've
got
some
interoperability
results
or
perhaps
you
have
to
wait
for
that.
We
have
the
edot
stuff
a
bit
more
mature.
C
I
I
think
it's
a
little
premature
and
I
guess
I'm
wondering
what
would
be
different
for
this,
as
opposed
to
any
more
general
guidance
we
developed
even
for
sub
to
recursive
or
recursive
to
authoritative
off
the
top
of
my
head.
I
can't
think
of
anything
specific
to
the
zone
transfer
that
we
would
need
to
discuss,
but
it's
certainly
something
we
should
think
about.
So.
D
C
Yep
yeah,
I
mean
we
talk
about
generally,
you
know,
reusing
persistent
connections
using
keeper
live
to
keep
them
open,
minimizing
the
number
of
handshakes
you
have
to
do
so,
but
but
I
think
that
that
that
sort
of
advice
is
becoming
quite
general
across
all
the
scenarios
for
dns.
E
Hi
john
reed
akamai,
I
just
wanna,
say
I
really
like
this
and
I'm
actually
gonna
come
out
in
favor
of
the
alpn,
because
I
see
this
and
I
think
you've
made
this
point.
I
see
this
as
both
an
extension
of
axfr
itself
and
moving
it
to
tls.
E
You
know
there's
a
lot
of
shortcomings
in
xfr
today
having
a
clear
indication
to
the
server
that
I
want
to
do
zot,
and
that
means
you
need
to
accept
all
these
queries
you
need
to
behave
in
this
way
goes
a
long
way
and
I
think
there's
some
value
there.
I
take.
E
You
know
dan
another's
concerns
about
signaling,
but
I'll
also
note
that
you
know
in
our
experience
as
a
large
operator,
a
lot
of
customers
have
what
they
call
hidden
masters
where
they
have
very
strict
ip
cycles,
so
any
traffic
to
them.
You
know,
there's
nothing
else
talking
to
them
except
zone
trans,
so
it's
pretty
clear
what's
going
on
there,
so
I
really
like
this.
Thank
you.
G
Hi,
so
what
happens
right
now,
if
I
do
just
kind
of
open
up
tcp
connection
and
do
a
zone
transfer
like
I
guess
the
purpose
of
lpn
is.
This
is
distinguished
two
protocols
which
cannot
be
otherwise
distinguished
on
the
wire
by
the
content
right
and
so
right
now
I
can
just
do.
I
can
open
a
tcp
connection
and
do
whatever
the
heck
I
want
right.
So
why
does
that
solution
need
to
change
now.
C
So
what
we,
what
we
didn't
want
to
do
was
have
a
requirement
that
if
an
authoritative
was
going
to
support
zot,
it
had
to
be
prepared
to
answer
any
of
the
query
over
the
same
connection
when.
C
Any
when,
if
you
it
might
not
have
any
declaration
or
published
intention
to
support
an
encrypted
track
protocol,
yet
because
what
that
might
mean
is
that
then
recursives
might
just
start
routinely
using
tls
to
ask
questions
of
authoritatives,
and
then
the
operator
of
the
authoritative
has
to
make
some
choices
about
whether
it
answers
them
it.
So
it
indirectly
forces
them
to
support
dot
and
we
don't
want
to
make
put
that
requirement
on
them
right
now,
because
there
is
no
spec.
That
says
this
is
how
you
do
dot
between
recursives
and
authorities.
C
G
Yeah,
I
guess
I
don't
understand
because
like
they
can
just
refuse
to
answer
those
queries
the
again.
This
is
detectable
the
application
layer.
So
I
mean
this
is
like
saying
I
mean
I
guess
like.
Let
me
give
you,
let
me
give
you
a.
Let
me
give
you
a
a
analogy
right
just
because
I
support
get
in
http
over
tls
doesn't
mean
that
what
doesn't
mean
I'm
required
to
support
random
new
new
method
types
that
were
invented
afterwards
and
the
same
thing
is
true
here.
G
There's
no
specification
for
for,
for
these
queries
so
not
required
to
support
them,
and
why
don't
you
want
to
use
this
name
which
the
two?
Why?
Why
is
what
has
to
happen?
Be
refuse
the
tls
layer.
C
So
we
I
mean,
we
think
it's
it's
clearer
and
also
there
are
other
restrictions
on,
for
example,
doing
zone
transfer
like
ip
based,
acls
or
tcg,
and
we
felt
that
have
operators
having
very
clear
mechanisms
to
choose
who
to
accept
requested
zone
transfers
on
the
earlier
they
can
in
the
interaction
is,
is
a
good
thing
in
terms
of
controlling
access
to
zones.
C
G
No,
I'm
sure
you
should
use
the
lpn
dot
and
that
you
should
refute
and
that
you
should
refuse
to
answer
those
queries
over
over
over
if
you're,
using
just
queries
the
dns
layer.
If
you
don't
want
to.
G
Any
queries
that
doesn't
want
to
answer
at
all.
I
mean
that's
what
you
do.
What
would
you
do
so
I
mean
say
you
say
you
only
accepted
zone
transfers
over
tcp,
nah
say
only
thing
you
sent
over
tcp
now
is
zone
transfers
right
and
you
didn't
want
to
take
arbitrary
queries.
What
would
you
do?
You
would
respond
with
some
sort
of
error,
and
so
I'm
saying
that
you
do
the
exact
same
thing,
I'm
saying
the
tls
just
places
tcp
in
this
case
I
mean
I
mean
like
like
imagine.
G
I
only
imagine
only
one
answer
for
a
record.
We
were
we
wouldn't
like
be
like
we
wouldn't
have
like
you
know.
We
wouldn't
have
dot
hyphen
a
so
I
mean
it's
not
just
it
isn't
a
general
purpose
policy.
I
mean
alpine,
isn't
a
general
purpose
policy
enforcement
mechanism.
It's
intended
to
distinguish
between
things
that
cannot
to
do
to
have
negotiation
at
the
handshake
layer
for
things
either
have
to
have
to
happen
prior
to
application,
transmission,
information,
one
reason
or
another,
or
to
tell
the
network
what's
going
on,
but
that
as
dkg
points
out.
G
The
second
is
undesirable
in
this
case,
and
the
first
seems
unnecessary.
I
mean,
I
don't
think
it's
a
crisis,
but
it
just
seems
like
it
seems
like
seems
that
it
seems
like
a
necessary
proliferation
of
the
rpms.
C
C
F
This
is
dkg
again,
so
I'm
just
trying
to
think
through
what
the
different
trade-offs
here
and
I
so
one
of
the
things
that
I'm
hearing
is.
We
don't
want
to
require
authoritative,
name
servers
to
handle
arbitrary
requests
from
recursors
over
dns
because
over
dot,
because
maybe
that's
too
expensive.
Maybe
they
don't
want
to
manage
that
state.
F
Maybe
there's
a
bunch
of
other
reasons
why
they
don't
want
to
have
to
do
that,
and
we
know
that
in
practice
a
lot
of
authoritatives
are
refusing
certain
types
of
requests
from
from
the
general
public
anyway
right.
So,
for
example,
in
today's
network,
many
of
the
limitations
on
axfr
are
ip
based
limitations.
Right
yeah
you
deploy
a
primary,
you
just
say
I'm
just
not.
You
know.
F
If
you
make
a
an
ax
far
requesting
that's,
not
the
it's
and
I
don't
think
you're
a
configured
secondary,
I'm
just
going
to
say
nope,
you
could
apply
those
same
limitations
like
ip
based
limitations
to
the
853
listener.
F
If
you
don't
want
to
answer,
you
know
to
anyone,
but
your
secondaries,
you
could
just
not
answer
on
tls
port
at
all,
so
in
some
sense
that
it
sounds
like
there
is
a
simpler
approach,
which
is,
which
is
to
keep
to
use
the
dot
and
then
sarah,
I
think
your
concerns
are
real,
that
you
know
the
the
refusals
or
rejections
themselves
are
gonna
look
are
gonna,
be
scattered
and
and
non-uniform
if
we
don't
give
good
guidance,
but
maybe
what
this
draft
can
do
is
to
say
if
the
intent
is
to
only
provide
zone
transfer
over
this
particular
interface.
F
Here
is
exactly
how
you
should
do
the
rejection
so
that
we
can
have
a
clear
signal
if
a
recurser
mistakenly
tries
to
use
you
know,
zone
transfer
over
tls
for
general
purpose,
dns
queries,
they
can
say.
Aha,
I
got
it.
This
is
I
I
was
trying
to
use
it
for
generic
dns
over
tls
from
recursive
to
authoritative,
but
that's
not
what
they're
doing.
F
If
we
could
define
how
the
failure
works
in
the
application
layer
inside
the
tls
connection,
then
we
don't
need
to
have
the
alpn
proliferation
or
public
visible
signaling,
that
this
is
zot.
Instead
of
that.
C
I
mean
that
certainly
is
an
option.
I
think
our
original
thinking
was.
It
was
that
then,
that
then
becomes.
C
More
but
potentially
more
algorithmically
heavy,
because
you're
rejecting
on
a
connection
on
a
per
message
basis.
Whereas
if
you
have
a
clear
signal
that
this
connection
can
only
be
used
for
this,
then
it's
very
clear
what
queries
are
allowed
and
what
queries
aren't.
So
that
was
kind
of
our
thinking
of
the
alpn
being
useful,
as
opposed
to
trying
to
develop
something
that
everybody's
going
to
implement
differently
about
managing
different
queries
on
different
connections.
C
H
For
from
my
perspective,
it
would
be
enough
if
the
author,
in
the
draft
for
the
set
you
have
to
handle
these
types
of
queries
over
the
tls,
so
let's
say
soa,
query:
notify
and
zone
transfer
itself
and
for
the
rest,
either
you
can
reply
or
if
you
want
to
support
like
unspecified
eot
queries
or
you
can
send
back
refused
with
whatever
you
know,
extended
error
code
or
something,
and
I
think
that
that's
perfectly
fine,
it
doesn't
require
any
a
lpn
and
any
other
server
which
decides
to
answer.
H
Also
any
other
queries
over
the
ot
can
do
that
without
breaking
the
standard.
Because,
honestly,
from
my
implemented
perspective,
there
is
no
additional
cost
of
handling
other
queries.
Once
you
have
the
tls
stack
inside,
I
don't
see
a
reason.
Why
not
to
answer
other
queries?
The
problem
is
the
discovery,
not
handling
the
queries
so.
C
So
I
mean
I
I
I'm
not
sure
all
operators
of
all
authoritatives
would
agree
that
they
would
be
happy
to
just
open
up
their
servers
to
tls
queries
so
and-
and
it.
C
H
Are
concerned
about
performance,
then
you
might,
you
know
close
or
limit
access
to
the
tls
to
some
subnets
or
something.
But
anyway,
if
you
are
concerned
about
performance,
you
have
to
limit
to
access
to
tls
on
the
ip
layer
anyway,
because
doing
lots
and
lots
of
tls
handshakes
is
perfect.
Attack
vector
from
the
performance
perspective,
so
well.
Yeah.
C
So
yeah,
that's
certain
consideration.
H
C
C
If
we
do
say,
any
connection
can
be
used
for
anything
and
traffic
is
all
mixed,
then
we're
slightly
going
against
that
model,
and
I
think
I
think
you
might
end
up
with
a
lot
of
configuration
options
needing
to
be
available
so
that
each
operator
could
tune
exactly
how
they
behave
on
a
tls
connection
to
exactly
how
they
wanted
to
do
it
and
that
that
was
what
seemed
actually
to
us
quite
an
overhead
and
likely
to
lead
to
inconsistencies
and
because
and
then
maybe
each
client
has
to
cater
for
a
whole
range
of
different
behaviors
from
a
primary
and,
and
that
was
why
we
kind
of
moved
towards
well
it's
simpler.
C
I
C
G
Yeah,
I
mean
so
I
think
you
know,
certainly
if
what
you
want
to
do
is
differentiate
service
endpoints
at
the
it
negotiates
the
client
what
service
services
is
allowed
to
do
then,
then
aopn
is
a
reasonable
time
to
do
that
I
mean
so
I
mean
if
your
hypothesis
is
the
client.
This
person
is
going
to
connect
with
you
know
with
with
aopn's.
G
You
know
zot
and
dot
and
then
based
on
what
the
server
says
it
will
either
only
issue
zone,
transfers
or
issue
all
queries.
Then
one
might
imagine
doing
that.
I
think
the
problem
there
is
going
to
be
that,
like
there's
a
very
narrow,
signaling
channel
and
so
like
you
know
that
only
supports
a
couple
profiles
and
and
and
so
like.
G
How
does
that
and
like
if
the
server
answers,
if
what
the
server
wants
is
like
them
in
separate
channels
and
the
client
offers
dot,
and
then
I
mean
the
server
says,
then
how
does
the
client
know
that
like
if
it
opened
up
a
new
connection
which
is
dot?
That
would
work
great
so
like?
I
think
that
that
you
know
like
if
we
want
that
kind
of
policy
we're
gonna
get
some
way.
G
We're
gonna
have
to
actually
express
that
policy,
whether
that's
out
of
band
or
whatever,
and
then
it
seems
like
like
s
and
I
might
be
a
wider
channel
books
that
doesn't
require
and
a
registration
for
every
new
ever
new
policy
endpoint.
Their
point,
I
think,
is
worth
making
is
what
would
you
do
in
this
circumstance?
What
happens
if,
if
I
offer
zot
and
this
and
the
server
says
zod
and
then
I
start
issuing
other
queries,
so
what
happens.
C
I
think
we
need
yes,
so
we'll
take
all
the
comments
from
today
on
board
and
go
back
to
think
about
it.
C
I
mean,
I
think,
if,
if
we
don't
use
alpn,
I
think
there's
a
tuning
problem
between
implementations
and
between
deployments,
because
we
could
have
inconsistent
behavior,
maybe
maybe
we
can
achieve
the
same
thing
with
s
and
I,
and
that
would
be
better,
we'll,
certainly
go
back
and
and
consider
that,
but
I
think
I
can
imagine
if
I'd
come
today
and
said
we're
gonna
say
if
you
support
zot,
you
have
to
answer
anything
over
dot
everybody.
Okay
with
that,
I
imagine
there
actually
would
have
been
a
reaction
against
that.
C
So
it's
really
great
to
hear
from
both
sides
of
the
argument
and
we
will
take
all
this
feedback
on
board.
Thank
you.
G
C
And
we
we
wanted,
we
thought
zot
is
a
constrained
enough
use
case
that
it's
straightforward
to
define
what
we
can
do
within
a
very
specific
context,
without
impacting
on
any
other
service
requirement
for
that
authoritative
server.
So
it
depends
whether
that's
more
useful
than
having
the
more
general
solution.
That's
the
decision
to
make
thanks.
Okay,
thank
you.
C
A
All
right,
thank
you.
Sarah
now
we'll
move
on
to
peter
and
his
signaling.
I
B
Oh,
I
did
not
permit
the
camera
all
right,
fine,
fine!
Let
me
grab
my
nose,
so
my
name
is
peter
van
dyke
with
powerdns,
my
co-authors
are
robin
rose
and
manu
brutel.
B
Before
I
present
this,
I
want
to
go
back
to
something
paul
hoffman
said
in
dns
op
about
there
being
two
or
three
current
drafts
for
dot
and
related
things,
no
coordination,
authors,
pushing
their
own
draft
forward,
etc,
and
why
don't
we
discuss
requirements?
First
drive
does
have
requirements
documents.
B
I
imagine
that
the
next
revision
of
that
will
take
some
great
input
from
all
the
discussion
we've
had
on
this
draft
and
perhaps
on
tim
april's
ns2
drafts,
and
I
don't
want
to
give
anybody
the
idea
that
I
am
trying
to
push
one
draft
through
at
the
cost
of
any
others.
In
fact,
when
I
told
tim
we
use
the
s
to
signal
against
downgrades,
I
meant.
Maybe
this
trick
will
work
for
you.
B
We
do
understand
that
our
draft
solves
the
problem
very
narrowly
and
comes
with
some
management
difficulties
that
can
be
a
problem
for
certain,
certainly
large
deployments,
all
right,
tim,
yes,
okay.
This
is
a
review
that
patricia
gave
on
the
list.
It
is
the
intro
that
we
should
have
written
for
our
drafts.
B
B
B
Records
and
cdnski
makes
management
from
the
child
side
easy,
some
more
positive
reviews
and
then
to
other
comments
that
I
will
address
people
say
this
is
product
protocol
abuse
and
I
agree
we
went
at
this
not
even
from
a
use
case,
but
from
these
are
the
tools
we
have.
The
only
authentic
data
from
a
child
in
the
parent
is
the
ds
records
and
as
such,
that
is
where
the
things
have
to
go
dim
the
slides,
keep
dropping
in
and
out
for
me
for
anybody
else.
J
B
All
right
well
I'll,
carry
on
then.
The
other
comment
we
got
is
you
should
be
using
tlsa
and
I
get
that
we
have
wedged
the
lsa
into
a
different
shaped
box
and
ns2
and
s2t
does
something
similar,
but
I
have
trouble
imagining
a
tlsa
based
solution
to
this
problem.
However,
we
define
this
problem.
B
B
We
do
not
want
to
change
this
draft
to
use
tlsa.
We
think
we
have
a
very
simple
proposal
and
anything
using
tlsa
would
be
a
different
proposal.
That
said,
I
don't
feel
any
drafts
should
be
competing.
It's
possible
that
our
there
are
multiple,
sensible
solutions
to
multiple
sensible
use
cases,
as
paul
vanessa
also
mentions
next
slide.
Please.
B
So
the
history
of
this,
about
a
year
ago,
manu
gritel,
presented
at
iit
of
103
in
prague,
he
imagined
a
dspi
record
type
that
would
sit
in
the
parent,
like
the
s
does
and
that
basically
takes
the
public
key
info
from
the
server
sticks
in
the
parents.
So
you
have
like,
with
our
proposal
no
round
trips,
no
downgrades.
It's
a
simple
protocol,
there's
no
extra
lookups,
which
I
thought
was
a
very
neat
idea,
but
of
course
this
not
being
ds.
You
can't
deploy
it
until
authoritative
developers
and
operators
and
register
registries
update
their
software.
B
To
do
this,
we
spent
a
lot
of
time
puzzling
how
to
fix
this,
and
this
draft
I'm
presenting
now
is
what
we
ended
up
with
next
slide.
Please.
B
Yeah
I'll
describe
the
protocol
from
the
perspective
of
the
resolver
and
presumably
then
it
should
be
clear
from
any
perspective
when
a
resolver
is
resolving
a
name,
it
might
go
to
the
tld
servers
to
the
dot
com
servers
and
get
the
delegation
for
example.com.
This
is
no
news.
Of
course.
This
delegation
has
some
ns
records
that
have
names
and
crucially,
these
names
are
not
authenticated.
B
B
The
resolver
takes
one
of
the
name
servers.
It
connects
to
it
port
853.
We
don't
currently
have
an
lpm.
I
hadn't
even
realized
that
it
was
an
option
until
I
read
the
xrt
draft
earlier
today,
resolver
connects
negotiates
tls
does
no
certificate;
checking
it
receives
the
public
key
from
the
authoritative.
B
Then
it
constructs
a
dns
key
record
in
memory.
This
is
not
a
record
that
appears
in
any
zone
in
this
dns
key.
It
sticks
the
subject.
Public
key
info
and
the
other
three
fill
fields
are
set
to
constants
flags
I'll
come
back
to
later.
The
protocol
is
three
because
this
is
dns
sec
and
the
algorithm
will
presumably
hopefully
be
assigned
by
ayanna
next
slide.
Please.
B
B
If
no
ds
is
matched,
we
can
try
another
server,
perhaps
there's
a
server
in
dns
set
that
is
not
in
the
ds
set.
If
we
run
out
of
servers
eventually,
then
we
cannot
resolve
names.
That
is
where
the
downgrade
resistance
is
next
slide.
Please.
B
So
we
are
safely
connected,
we
can
start
issuing
queries
and
this
slide
says
the
any
observer
will
only
know
the
name
and
ip
of
the
nameserver
we
connected
to
at
least
until
es,
and
I
becomes
a
thing,
but
I
spoke
to
ralph
doleman
when
I
left
lobs
early
this
morning,
and
he
pointed
out
two
things
one.
You
can't
do
esni
because
you
need
dns
to
do
that.
B
B
B
Obviously
these
are
not
zone
keys
and
obviously
these
are
not
secure
entry
points.
We
have
some
brief
discussion
about
whether
pinned
and
validated
dot
would
be
enough
for
an
ad
bit,
but
that
doesn't
make
sense,
because
you
cannot
check
if
you're
forward
used
tls
to
get
the
data
for
you,
so
we'll
leave
the
advantage
to
the
nsx
proper,
so
zero
makes
the
more
makes
the
most
sense.
B
B
So
this
is,
this:
comes
back
to
the
protocol
abuse
and
some
related
questions
below
you
see
the
template
for
the
ayanna
assignment,
as
we
put
it
in
the
draft,
and
this
would
be
the
first
dns
algorithm
that
has
some
signing
no
and
then
you
end
up
with
a
bunch
of
questions
that
come
down
to
what
do.
Non-Dns,
yes,
even
mean
one
registry
operator
pointed
out
that
in
who
is
they
mark
a
domain
as
being
signed?
B
B
We
haven't
figured
this
out
yet
we
need
to
look
at
the
cds
rfc,
some
more
to
figure
out
the
right
interactions
here.
Next
slide,
please
implementation
wise.
We
have
written
some
code
in
python
and
go
and
c
plus
plus
just
to
show
that
the
concept
can
work
and
also
to
show
that
if
you
have
a
decent
dns
handling
infrastructure,
so
you
already
know
how
to
generate
dns
keys,
digest
them
into
the
ss
etc
that
this
is
only
10
or
15
lines
of
code.
Assuming
your
resolver
can
already
do.
Tls.
B
Let's
see
next
slide,
please
right.
There
is
one
open
question
that
I
forgot
to
put
in
these
slides.
All
vouchers
suggested
that
the
dns
key
rds
that
pins
your
connection
should
always
be
visible
in
the
child,
so
that
it
can
prevent
so
that
you
can
prevent
certain
interception
attacks
by
the
parents.
B
A
Thank
you,
peter
anybody
have
questions
they
want
to
talk
about
now.
A
Right
yeah
paul
paul
had
to
drop
off
and
was
not
gonna
be
able
to
present
his
slides.
A
So
I
think
what
tim
and
I
want
to
do-
is
we
just
want
to
put
up
so
so
so
paul
slides
are
are
in
the
meeting
materials.
So
everybody
can
take
a
look
at
them
as
you
need
to,
but
I
think
that
the
the
bigger
thing
that
we
wanted
to
do
was
kind
of
point
out.
A
couple
of
points
that
that
paul
was
making
in
this
in
his
presentation
so
I'll
give
one
last
chance
for
anybody
to
ask
peter
questioned
about
about
his
draft.
A
Okay,
thank
you
peter
no
problem,
so
so,
rather
than
tim
and
I
trying
to
articulate
paul's
points
in
his
slides,
I
think
one
of
the
things
that
came
up
in
the
dns
op
session,
that
I
heard
and
and
I'll
let
you
know
maybe
tim
or
you
know
one
of
the
other
dns
top
chairs
chime
in
here.
But
there
are
questions
about
the
use
cases
and
and
how
they're
they
may
differ
across
the
the
spectrum
and
and
how
that
might
actually
affect
the
design.
A
A
K
H
K
Great
yeah,
so
one
thing
I
think
at
a
high
level.
I
would
want
us,
as
a
group
to
think
about
is
this
proposal
has
a
nice
property
that
it
prevents
downgraded.
K
A
L
L
Yeah,
so
this
is
our
favorite
from
akamai,
so
peter
said
that
he
would
see
kind
of
multiple
use
cases
leading
to
different
sort
of
proposals.
How
to
do
this
upgrade.
L
But
I
think
I'm
not
agreeing
with
this,
because
I
think
having
multiple
solutions
in
the
the
servers
on
how
to
discover
and
use
in
encrypted
services
is
just
adding
another
layer,
and
I
mean
we
currently
have
a
peter's
draft,
there's
ns2
and
then
there's
the
adaptive
dns
draft
and
they're
all
trying
to
do
different,
different
things
when
it
comes
to
the
actual
kind
of
how
do
they
achieve
things,
but
the
end
goal
of
them
is
kind
of
have
a
secure
connection
between
the
curse
from
the
authority
well
and
the
depth.
L
Yes,
maybe
a
bit
even
from
from
the
from
the
end,
the
client-
and
I
think
we
should
see
the
do
something
like
comparison.
What
are
the
pros
and
cons
of
the
drafts
and
then
pick
one
and
not
try
to
do
two
or
three
things?
At
the
same
time,.
L
L
I
I
mean
I
haven't:
read
the
requirements
this
time
around.
I've
read
it
around,
I
think,
with
the
last
meeting,
we
embedded
persons
and
I
don't
think
there
were
much
much
gaps
in
there.
There
is
a
I
mean
we
need
to
come
to
a
conclusion
where,
where
do
we
want
to
go,
but
I
think
the
requirements
and
all
the
drafts
that
are,
I
mean
out
there,
I
think,
fulfill
the
requirements,
but
we
need
to
pick
one.
A
Okay,
so
that
that's
a
useful
comment-
and
I
think
tim
was
going
to
chime
in
on
one
of
the
dns
or
the
add
drafts
that
might
be
relevant
here
as
well.
J
Yeah,
sorry
and
and
ralph's
right,
though,
I
think
before
you
pick
one,
you
want
to
try
a
bunch
of
stuff
to
see
which
one
works
seems
to
work
sort
of
thing
right,
but
no,
I'm
not
against
experimenting.
Yeah,
experiment's,
good
yeah,
brian
and
I
have
talked
about
this
with
eric.
It's
come
up
a
couple
times
and
it's
come
up
in
with
the
dynastop
chairs
as
well.
J
Penny
and
paul
have
a
resolver
info
draft
in
dynastop,
that's
kind
of
sitting
waiting
for
add
to
do
something
with
it,
but
they
also
have
a
off
server
info
draft
that
I
was
pushing
them.
I
felt
that
would
be
much
more
relevant
and
even
eric
pointed
out
that
there's
there
is
probably
some
interesting
stuff
there
in.
J
We
need
to
keep
poking
the
chairs
to
find
out
what's
happening
there.
I
think,
if,
if
not,
they
may
end
up.
I've
been
talking
to
paul
and
queen
about
moving
them
back
to
dynastop
and
sort
of
aggressively
coming
to
consensus
on
stuff
is
probably
the
best
way
to
say
it
and
it'd
be
interesting
to
get
feedback
on
some
of
that
stuff
too.
L
I'm
not
sure
if
us
server
info
will
help,
because
normally
we
discover
stuff
while
we
traverse
tree,
and
that
would
be
something
we
would
have
to
in
parallel.
But
I
mean
I
don't
know
the
draft
so.
A
Okay,
any
other
other
comments
that
that
people
want
to
throw
out
in
relation
to
getting
this
moving.
K
One
other
observation
I
have
after
reading
a
bunch
of
the
drafts
of
the
various
schools
is
that
I
think,
there's
a
requirement
or
basically,
we
are
evaluating
the
proposals
against.
Does
it
need
an
extra
query?
I
think-
and
please
correct
me
if
my
understanding.
K
So
if
that
becomes
rfc
and
resolvers
are
required
to
do
that,
extra
testing,
the
the
benefit
of
avoiding
extra
query,
goes
away.
In
my
mind,.
K
A
Right
tim,
do
you
have
a
status
on
where
schumann's
document
stands.
J
Got
some
changes
they
want
to
make,
but
it's
a
pretty
straightforward
document
in
terms
of
size
and
length
and
stuff
I
was
hoping
if
I
could
move
motivate
the
authors
enough
to
see
if
we
can
actually
move
that
along
much
like
the
mark,
andrews
draft
they're
they're
straight
to
the
point
kind
of
thing.
So
I
don't
see
why
not
it
it's
a
question
of
how
we
motivate
the
authors
to
do
updates
and
stuff.
H
I
would
like
to
react
to
pony's
remark,
because
the
delegation
revalidation
draft
says
that
the
resolver
is
supposed
to
do
a
query
to
the
child,
but
the
query
is
asynchronous.
The
original
query
it's
like
the
there
is
over
will
not
block
the
client
query
on
answer
from
the
child,
so
it
doesn't
introduce
any
more
latency
from
the
client
perspective.
H
H
A
So
what
I'll
do
is
I'll
ask
I'll
ask
two
questions
I'll
ask
for
a
hum
on
adopting
the
document
and
I'll
also
ask
for
a
hum
on
not
adopting
the
document.
A
A
A
A
So
not
a
whole
lot
of
difference
there
so
tim
and
I
will
formulate
these
questions
and
actually
put
them
out
on
the
mailing
list
so
that
we
can
get
further
input
on
it
and
and
and
please
do
keep
providing
feedback
to
to
the
document
authors
this
I
think,
they've
been
getting
a
lot
of
a
lot
of
good
comments
back
and-
and
I
want
to
see
that
keep
moving.
A
A
A
Okay,
well
thanks
everybody
for
for
participating,
tim
and
I
are
going
to
pull
the
minutes
together
and
get
those
uploaded
we'll
work
on
getting
out
a
question
to
the
working
group
about
the
adoption
of
ds,
dot,
signal
and
pin,
and
we
will
continue
working
with
the
authors
on
the
on
the
expert
over
tls
and
the
7626
biz
revisions.