►
From YouTube: IETF109-DNSOP-20201120-0730
Description
DNSOP meeting session at IETF109
2020/11/20 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
All
right
everyone-
this
is
tim,
I
think
we'll
be
starting
here
in
about
a
minute
or
so
I
just
wanted
to
make
sure
warren
was
here.
Oh
great
warren
is
here
now
we
can
begin
actually
so
so
we
we
don't
have
much
to
say
and
we'll
just
kick
in
right
away
with
stuff.
So
suzanne,
if
you
want
to
kick
to
the
next
slide,
benno
is
getting
better
he's
on
the
mend.
So
that's
good
he's
recovering
from
this.
B
Thing:
yeah:
okay:
we
can
go
ahead
and
get
into
it.
Now
that
I
have
figured
out
the
unmute
button
yeah,
so
we're
gonna
show
all
right.
We
can
go
ahead
and
swing
right
into
it.
Then.
A
There's
that
one
of
course,
and
then
one
more
the
note
well
with
our
policy
procedures,
you
should
have
probably
seen
this
a
whole
bunch
by
now
give
it
give
it
a
look
through,
let's
jump
to
the
next
one.
This
is
just
for
one
person
warren.
This
is
your
reminder.
A
C
Yes,
yes,
when
was
the
new
version
submitted
just
a
couple
hours
ago.
A
Yep,
okay,
thank
you,
sir.
This
is
how
we
communicate
with
our
area
director.
So
thanks
and
our
agenda
is
william's.
Gonna
talk
he's
got
some
hackathon
results
he
wants
to
to
give
out,
and
then
we've
got
three
three
new
new
pieces
of
work
sort
of
thing.
So
there
you
go
and
we'll
just
kick
right
into
that
willem.
If
you're
ready.
E
Oh,
can
I
present
myself
just
give
it
a
shot?
Okay,.
B
E
E
E
So
I
thought
it
would
be
good
to
ask
there
if
people
wanted
to
participate
in
the
hackathon
there's,
also
a
public
channel,
so
I've
put
it
on
the
hackathon
wiki
page
as
well,
so
people
that
were
not
already
on
this
chat
surface
could
join
as
well
and
14
signed
up,
which
is
maybe
not
as
as
much
as
a
in-person
hackathon,
but
still
a
good
number,
though
you
have
to
unlike
the
in-person
hackathon,
people
were
also
still
just
working
and
having
meetings,
and
you
know
so.
It
was
a
bit
of
in.
F
E
A
fierce
thing:
well,
the
first
hack
we
worked
on
was
the
dns
air
reporting
roy
will
present
on
the
draft
later,
but
it's
basically
like
extended
dns
errors,
but
instead
of
reporting
to
the
querier,
the
errors
are
reporting
to
the
authoritative
where
the
broken
thing
is
so
here
you
see
how
that
chat.
Surface
worked
in
practice.
E
E
So,
if
you
send
the
option,
or
at
least
the
option
with
id
51281,
which
will
act
like
the
option,
it
reports
a
server
to
which
you
can
submit
the
error
and
also
which,
in
this
case
is
reported
in
labs.now
and
on
that
server.
I
so
the
errors
will
normally
be
reported
with
the
dns
query,
so
this
server
will
show
the
log
of
the
dns
queries
it
sees.
So
it
can
help
with
the
development
of
this
option
in
resolvers.
E
So
resolver
implementations
should
be
not
that
hard,
given
that
not
parodinus
inbound
all
have
extended
dna's
arrow
branches
already
so,
but
also
during
the
hackathon.
There's
a
lot
of
discussion
about
this
focused
discussion
about
those
standards,
and
so
we
wondered
how
authoritative
would
respond
if
resolvers
would
just
use
that
option
and
how
we
could
measure
what
the
impact
will
be.
If
that
would
be
done.
So
that's
a
good
result
as
well.
I
think
future
research
into
what
the
impact
will
be
for
this
option.
E
There
was
already
an
excellent
proof
of
concept
implementation
written
by
duane
in
with
ldns,
but
it
was
a
bit
cumbersome
and
at
the
hackathon
we
made
the
implementation
integrated
with
ldns
cyanzone
and
ldns
ferris
phi
zone,
and
then
it
was
already
friday
and
the
hackathon
was
over,
but
before
the
hackathon,
some
of
the
participants
wanted
to
work
on
interoperability
testing
for
the
catalog
challenge,
so
we
decided
we
would
continue
over
the
weekend
with
the
hackathon
and
also
last
week
with
interoperability
testing
for
catalog
zones.
E
Yeah,
so
here's
the
text
saying
well,
we
could
still
continue
trying
to
do
this
next
week
because
not
has
the
draft
implemented
at
least
the
interpretation
of
catalog
zones
since
version
3,
which
is
released
last
september
and
powerdns
already
had
a
proof
of
concept.
Hack
called
powercats,
based
on
mukund's
original
draft,
which
was
created
four
years
ago.
E
E
E
E
E
I
think-
and
there
was
also
interesting
discussion
on
if
it
would
be
a
good
idea
to
convey
the
serial
number
of
the
zones
in
the
catalog
with
the
catalog
zones,
but
I
think
we
have
to
post
a
message
to
the
dns
op
list
so
that
you
can-
or
we
can
all
discuss
this
amongst
each
other.
E
E
People
are
not
working
or
on
other
things
at
the
same
time,
but
I
think
it
was
still
worth
it
because
we
had
some
implementers
focus
on
the
standards
and
yeah.
I
think
we
gave
good
input
to
the
work
group.
So
that's
basically
it
here.
You
see
the
list
of
people
that
participated,
and
that
ends
my.
B
Yeah
yeah
any
questions
comments,
ideas
for
what
to
do
next
time
for
the
hackathon.
B
G
Right,
yes,
can
you
hear
me
yep
great
so
good
morning,
good
evening,
good
afternoon,
good
night
for
some
of
you,
this
is
a
presentation
about
the
draft
that
I've
written
with
matt
larson
about
dns
error
reporting
and
the
idea
is
based
on
extended.
Dns
are
also
reporting,
instead
of
not
instead
next
next
to
reporting
to
the
stop
resolver.
Maybe
this
information
can
go
to
an
authoritative
server,
so
next
slide.
Please.
G
So
what
is
what
is
the
problem?
So
this
is
a
bit
of
a
story,
and
you
all
know
this,
but
I'm
going
to
tell
you
anyway,
and
the
dns
is
loosely
connected
fault,
tolerant
configuring
go
and
any
warnings
and
errors
are
buried
in
logs
of
recursive
resolvers,
and
we
we
all
know
this
and
then
came
dnsec
next
slide.
G
Please
and
with
dnsec
dns,
still
loosely
connected
a
little
bit
more
error
prone
and
you
don't
need
to
stay
as
you
configure
it,
because
things
might
go
badly
and
still
any
warnings
and
errors
are
buried
in
the
lack
of
recursive
resolvers
and
because
of
all
this,
the
dns
is
slightly
more
next,
slightly
slightly
more
fragile.
G
So
what
is
it
that
we
can
do
about
this
next
slide?
Please,
and
with
this
I
mean
this-
is
the
real
issue
that
these
things,
these
warning
and
errors
are
still
buried
in
lots
of
recursive
results.
We
want
to
get
it,
we
really
get
fixed,
not
very
so.
What
is
the
real
problem
statement
that
I'm
trying
to
fix
next
slide?
G
The
problem
is
when
a
resolver
encounters
an
error
and
does
nothing
right
it
it.
It's
not
that
it
does
nothing.
It
can
now
report
to
the
to
the
end
user
using
extended
dns
errors,
it's
not
that
it
does
not.
It
should
do
nothing
in
terms
of
resolving
more
because
if
it's
broken,
a
resolver
can't
fix
it.
So,
in
a
sense,
that's
good,
but
we
want
to
sorry
I
I
thought
I
was
interrupted
villain.
Can
you
take
your
mic
off?
Please!
G
Thank
you,
okay!
So
next
slide,
please
there
you
go!
Thank
you!
What
if
the
resolver
can
notify
the
operator
slash
domain
owner
now?
That's
that's
an
interesting
thought,
of
course.
At
least
I
think
so,
but
before
we
do
that,
sorry
next
slide,
please,
before
we
do
that
there
are
some
requirements
that
we
need
to
keep
in
mind.
Since
the
channel
is
already
hurting
and
the
reporting
should
be
very
lightweight,
we
shouldn't
have
any
additional
complexities.
We
don't
want
to
send
email
for
every
error.
We
don't
want
to
create
pdfs.
G
No,
who
is
lookups,
no
shaming,
no
sending
to
mailing
lists,
etc,
cetera.
We
don't
want
to
have
any
guesswork.
We
because
we
basically
don't
know
who
owns
what
domain,
no
guessing,
what
the
cost
of
the
failure
actually
may
be,
so
no
heuristics,
no
trial
and
error,
cetera
et
cetera
next
slide,
please!
G
So
how
are
we
going
to
do
this?
Well,
we'll
set
an
error
report
and
all
right
where
you
want
to
send
this,
but
we
can
send
it
to
the
authority
server
of
the
broker
domain
because
it's
broken
right
and
we
also
can't
send
it
to
the
owner
of
the
domain,
because
we
have
no
clue
who
that
is
remember
we
don't
want
to
burden
the
poor
resolver
with
securities
rdap
et
cetera,
et
cetera,
rich
emo
clients
all
but
nonsense,
so
we're
going
to
introduce
a
new
concept
here
next
slide.
Please.
G
And
that's
the
reporting
agent
and
sorry
next
slide.
Please.
G
I
I
just
saw,
I
just
started
the
term
idiots
before
my
name.
Sorry,
it
was
not
that
funny
anyway,
especially
not
early
morning.
So
how
are
we
going
to
send
this
well
we're
going
to
send
an
error
report
to
a
reporting
agent,
and
this
error
report
is
just
another
dns
query.
G
G
G
G
Well,
then
what
happens?
Well,
if
the,
if
the,
if
the
response
can't
be
computed
or
can
be
dealt
with
or
is
it
basically
presents
an
error,
then
the
resolver
can
send
a
query.
That's
set
up
as
follows:
it
basically
has
a
bad
q
name,
the
q,
the
q
name.
It
asks
for
where
it
got
a
broken
response
to
and
then
an
underscore
error
as
a
separator
and
then
the
agent
domain,
which
is
in
this
case
a01.error.com
that
a1.error.com
basically
learned
for
you
an
edna,
zero
option.
I
apologize,
I
should
have
used
example.com.
G
I
will
change
that
for
the
next
presentation
and
it
can
also
prepend
the
queue
type
and
error,
but
but
you
can
you
get
the
idea.
So
all
of
these
responses.
G
Error
reports
that
are
sent
out
the
responses
that
can
be
cached
and
that
caching
then
helps
again
sending
too
many
reports,
and
I
don't
want
to.
I
don't
want
to
specify
too
deeply
how
resolve
should
I
do
this
because
that's
up
to
the
resolver
itself,
but
the
the
reporting
agent
is
basically
an
intermediary
and
there's
an
analogy
to
that
and
that's
intermediaries
for
for
dmarc,
and
I
I
assume
some
of
you
know
how
dmarc
works,
and
so
I'm
not
going
to
go
into
that.
G
G
So
does
that
really
work
in
the
real
world?
Well,
on
the
reporting
part,
we
and
I
say
we
as
me
and
a
few
colleagues
when
we
did
the
trust
tanker
rollover
with
with
the
community.
We
had
reports
going
to
root
servers.
G
About
which
truss
anchor
uses
that
configure,
and
so
the
reporting
part
actually
works,
and
what
these
root
servers
then
subsequently
did.
These
authoritative,
subsequently
did
is
sent
a
sent,
a
report
to
a
dedicated
nameserver
by
appending
rc8145.vsiken.org
to
a
trust,
anchor
report
so
that
that
that
kind
of
reporting
does
work
in
in
at
least
for
the
trust
center
part
on
the
indiana
zero
part.
Well,
indian
zero
options
do
work,
so
there's
really
nothing
new
here.
G
Of
course,
there
are
many
little
caveats
that
I
in
theory,
theory
I
could
go
into
that
now,
but
I
don't
have
time
for
that.
So
there
are
many
little
caveats
documented
in
the
draft.
I've
talked
to
a
few
friends
and
colleagues
about
about
this
idea,
and
many
of
you
have
come
with
interesting
security.
Privacy
related
things.
I
hope
I've
included
that
now
all
in
the
in
the
draft
and
it
will
the
next
version
will
come
out
soon.
G
We,
oh
sorry,
next
slide,
please.
So
what
else
is
there?
So,
what's
with
the
underscore
error
label,
we
need
to
have
separated
between
the
reporting
agent
and
the
reported
query,
and
what
else
is
in
that
report,
while
the
queue
type
in
the
error
and
which
errors
are
we
talking
about
those
that
are
in
extended
dns
errors?
Now
to
be
fair?
Those
are
not
exactly
the
same
thing,
because
a
what
you
send
to
a
client
is
basically
sorry
what
you
send
to
a
stop
resolver.
G
Those
are
basically
the
errors
that
you
find
out
after
the
whole.
Resolving
has
been
done,
but
that
might
not
necessarily
be
the
same
that
you
sent
to
an
authority
server
when
a
query
resulted
in
a
broken
response
or
a
response
that
can't
be
computed
et
cetera,
et
cetera
so
and
there's
a
whole
lot
in
them
in
extended
dns
errors
that
we
can
recycle
here
so
much
so
that
I
don't
think
I
don't
think
it's
necessary
to
open
yet
another
registry
with
new
types
of
errors.
G
So
we
already
had
last
week
during
the
hackathon
a
bit
of
progress
on
them
on
this
draft
with
regards
to
implementations.
So
william
has
talked
about
that.
So,
thank
you
all
who
participated
and
well
with
that.
I
don't
have
anything
more
to
to
talk
about
with
this
draft.
So
I'll
guess
I'll
give
the
mic
back
to
you
thanks.
D
Yep,
thank
it's
an
interesting
draft.
I
I
have
some
questions
wondering
if
there's
any
data
around
how
often
there's
a
failure
such
that
the
authoritative
is
able
to
respond
well
enough
to
give
a
reporting
domain,
but
not
able
to
actually
give
the
answer
to
the
question.
So
the
example
is
one
I'd
be
interested
in
data
around
the
frequency
of
other
cases.
D
You
know
my
experience.
The
failure
modes
we
see
are
either
the
authoritative
is
just
plain
offline
or
it's
perhaps
you
know,
dropping
packets
based
on
you
know,
looking
at
the
query
type
that
it
doesn't
like
or
something
like
that.
So
I'd
be
yeah.
I'm
curious
about
the
applicability
of
things
other
than
you
know.
Examples.
G
Yeah
well
yeah
other
than
dns.
Well,
I
think
is
is
of
course
one
of
one
of
one
of
the
failure
modes
as
long
as
your
sd.
As
long
as
the
reporting
resolver
receives
a
response
and,
of
course,
the
authoritative
server
that
sends
the
response.
Has
this
agent
domain
in
it,
then
even
even
lame
delegations
can
be
reported.
This
way
that
this
server
is
now
reporting
that
it's.
G
This
server
is
now
reporting
that
it's
not
responsible
for
this
domain,
even
though
it
was
delegated
to
it,
and
so
it
basically,
it
is
only-
and
I
think
only
only
in
the
case
where,
where
an
authoritative
response,
authoritative
server
doesn't
respond
at
all,
and
that's
the
that's
the
case
when
a
reporting
resolver
can't
report
anything
right,
because
it
doesn't
get
this
reporting
agent
domain
in
in
almost
all
other
cases,
it
has
something
to
report.
G
There
are
a
few
things
where
there's
a
discussion
if,
for
instance,
with
the
land
delegation
which
side
is
really
broken,
is
the
parent
or
the
child?
I
think
I
think
that's
something
we
can.
We
can
figure
out
or
even
configure
eventually
so,
but
we're
very
much
in
the
early
stages
of
developing
this
and
get
some
experience
with
this.
But
thank
you
for
the
question.
H
I
Right
this
is
a
very
neat
draft.
I
like
it
a
lot.
I've
got
one
or
two
concerns
about
this
issue
of
the
reporting
agents
and
what
its
role
is
going
to
be,
and
maybe
this
is
something
needs
to
be
clarified.
I
I
would
imagine
something
like
this,
for
example,
we've
been
very,
very
youthful
if
we
had
it
in
place
around
about
the
time
of
the
run
the
last
route
zone
key
rolled
over.
So
I
wonder
if
there's
an
idea
to
maybe
put
some
more
text
on
what
the
expectations
are
about,
the
role
of
this
reporting
agent
and,
if
that's
worth,
considering
for
the
future
rest
of
the
draft.
G
Thanks
jim
for
the
question
yeah,
I
don't
know,
that's,
that's
that's
a
good
idea.
You
can
use
it,
of
course,
for
telemetry,
let's
say
a
large,
a
large
and
resolver
constellation,
and
if
they
don't
want
to
send
immediately
all
reports
to
all
authoritative
domain
servers
that
it
sees
as
broken.
It
can
actually
collect
all
the
data
first
and
then
and
and
then
send
it
on,
and
the
idea
is
not
to
be
the
protocol
police
at
all.
G
So
I
remember
when
I,
when
I
was
at
nominees-
and
we
had
this
broken
one
one
one
broken:
how
do
you
call
that
we
we
issued
a
we
reinstated,
the
previous
dns
key
and
and
and
that
broke
a
whole
lot
of
things
and
and
we
only
found
out
using
using
twitter
at
the
time
that
we
had
a
pro
that
we
had
a
problem,
so
we
we
could
have
used
this
at
the
time
if
that
makes
any
sense,
even
though
we
had
all
checks
and
balances
there,
and
we
still
missed
this
one
error.
J
Hard,
hopefully
it
works
now,
so
in
dns,
in
a
resolver,
the
name
servers
are
usually
identified
by
ip
address,
so
you
get
and
from
your
draft
you
get
a
reporting
agent
per
ip
address,
say
yeah,
but
nobody
prevents
you
to
kind
of.
You
use
the
domain
to
create
a
domain
that
points
to
that
name
server
and
is
deliberately
false
or
is
deliberately
broken.
G
No
there's
there's
nothing
that
prevents
that,
but
I
use
the
autodadium.
You
can't
stop
anyone
from
sending
anything
to
anyone
on
the
internet
anyway.
So
that's.
Of
course
you
can
set
up
to
break
things.
Keep
in
mind
that
the
reporting
agent,
the
offer
the
server
where
all
the
reports
come
in.
J
J
I
I
don't
understand
sorry.
Well
I
mean
you
should
just
I
mean
if
someone
deliberately
makes
a
bad
domain
that
that
generates
lots
of
queries
to
the
reporting
agent,
then
this
could
be
abused.
So
if
you
are
doing
this
for
your
domains,
it
would
be
good
to
maybe
have
a
suggestion.
Giraffe
that
keep
it
separate
from
your
regular,
authoritative
name
service,
because
it
is
easier,
abused.
G
Oh
sorry,
yes,
that's
actually
in
the
that's
actually
in
the
draft.
The
the
the
authoritative
name,
server
that
serves
a
domain
should
not
be
with
with
the
with
the
agent
edna
zero
option.
Right
should
not
be
the
same
server
as
where
the
reverse,
as
where
the
error
reports
come
in.
So
that's
definitely
part
of
it,
and
the
whole
idea
is
that
this.
That
is
basically
a
completely
separate
entity
that
can
handle
the
errors
and
figure
out
eventually
using
some
some
kind
of
I
don't
know,
grab
set
arc.
G
H
G
Yeah,
I
think
network
blocking
is
quite
orthogonal
to
this
issue.
You
first
need
to
get
a
response
anyway,
from
from
from
an
authoritative
server,
with
the
edna
zero
option
that
has
the
agent
domain
before
you
can
send
a
report.
So
after
you've
sent
a
report
that
basically
meant
you
nothing
got
blocked.
If
that
makes
any
sense.
L
I
I
think
it's
drive
if
you
drive
the
presentation
suzanne
if
you're
moving
parts
and
all
that
that'd
be
great
yeah.
Thank
you.
I
really
want
to
just
start
off
by
setting
the
scene
here.
I
This
idea
is
a
revival
of
a
document
that
was
submitted
to
itf
104
in
prague
to
the
dual
working
group,
where
it
generated
a
lot
of
discussion.
Not
all
of
it
was
particularly
helpful
in
my
view,
and
we
were
left
at
that
point.
We
being
the
authors
of
the
document
were
left
of
quandary,
because
at
that
stage
the
dual
working
group
was
being
wound
down.
I
There
were
talks
about
potentially
boss
for
a
new
working
group
being
set
up,
so
we
decided
that
that
stasis
of
wait
until
the
dust
settled
into
all
that
kind
of
itf
machinery
had
actually
done
its
thing
and
we
saw
how
things
were
progressing,
but
there
was
definitely
and
still
is
a
lot
of
enthusiasm
for
documenting
this
stuff
and
getting
this
eventually
published
somehow,
ideally
as
an
itf
document,
there
are
some
gaps
in
the
document
as
there
were
in
the
previous
version,
and
particularly
things
like
tls
session
parameters
and
how
these
might
influence
the
behavior
of
dual
resolver
services
and
that's
something
that
could
still
be
worked
on.
I
If
there's
enough
enthusiasm
to
progress
the
document
in
some
way
and
of
course
the
landscape
has
moved
on
considerably
since
itf
104,
there's
a
lot
more
experience
and
insights
into
what
browsers,
in
particular
doing
with
their
do
settings
and
behavior
next
slide.
Please
sort
of
step
on
elementary
zone.
I
There
we
go
yeah
yeah.
So,
as
I
said
here,
the
objective
here
is
purely
to
document
the
problem
space
for
the
deployment
from
the
perspective
network
operators
primarily,
but
there
may
be
some
other
considerations
here
that
could
apply
to
other
use
cases.
I'm
thinking
say,
enterprise
networks
that
may
have
some
concerns
around
deployment
with
respect
to
things
like
nat,
setups
and
split
dns,
setups
and
stuff
of
that
nature.
But
the
main
thrust
of
this
is
to
do
with
isps.
I
That
applies
to
the
operation
of
these
networks
and,
of
course,
in
these
situations
and
all
of
an
impact
on
the
asus
infrastructure,
how
things
are
provisioned
operating
procedures,
customer
support
and
all
these
other
kind
of
stuff,
and
as
I
mentioned
earlier,
I
think
it's
best
if
this
gets
documented
in
an
its
setting
and
obviously
an
rsc
is
the
end
game.
For
this,
probably,
I
think
an
informational
might
be
the
best
way
to
get
this
thing
done
and
dusted
next
slide,
please.
I
So
the
question
is:
why
does
it?
Why
is
this
draft
being
submitted,
and
why
are
we
having
a
discussion
about
it
now?
Well,
this
is
about
operator
networks
and
operational
considerations
in
some
of
these
operator
networks,
and
it
involves
dns,
albeit
primarily,
dns
over
http,
rather
than
port
53.,
can't
bring
this
stuff
to
the
working
group.
That's
gone,
it's
obviously
a
scope
for
deprive
and
the
ad
working
groups,
so
dns
up
seems
to
be
the
best
place
to
start,
and
it
does
have
some
overlap
with
it
there.
I
In
my
view,
it
doesn't
have
to
become
a
working
group
document.
It
will
need,
I
think,
some
degree
of
oversight
review
by
dns
experts
who
are
some
stage
removed
from
the
office
of
the
document
and
the
others
are
interested
in
contributing
to
the
document.
I
So
I
think
it
potentially
could
become
an
individual
submission
on
any
sponsored
document
or
something
of
that
nature,
I'm
fairly
agnostic
as
to
what
the
best
solution
is
here
and
really
I'm
asking
the
working
group
what
they
think
might
be
the
best
next
steps,
and
that
takes
me
to
my
final
slide,
which
is
where
I
shut
up,
and
it
gives
time
for
everyone
else
to
give
the
comments
and
suggestions
through
rotten
fruit.
Send
money
send
coffee
over
to
you.
M
I
I
I
don't.
I
don't
think
this
document
is
a
good
fit
for
dns
up.
I
think
it's
its
contents
are
very
broad
and
a
lot
of
it
is
considering
regulatory
issues
that
are
and
and
speculating
on
legal
questions
that
are
not
in
scope
for
dns
up
and
a
lot
of
the
technical
content.
I
don't
think
is
really
accurate,
so
I
wouldn't
want
to
use
it
as
a
starting.
A
A
N
Yeah
I'm
much
more
enthusiastic
than
benjamin.
I
guess
I
I
do
think
that
this
is
an
important
document
to
have
somewhere
as
documenting
operational
experience,
and
in
my
my
past
bias
is
that
documenting
dns
operational
experience
is
something
that
is
a
good
fit
for
dns
op.
But
if
the
chairs
don't
feel
that
way
and
if
the
working
group
doesn't
feel
that
way
and
I
I
still
think
that
documenting
this
needs
to
be
pursued,
and
so
I
would
be
enthusiastic
about
seeing
this
go
forward.
A
Okay,
thanks
yeah,
and
I
have
some
comments
I'll
make
at
the
end,
but
we'll
we'll
cut
the
line
after
andrew.
But
mr
ferrell.
O
Hi,
I
I
I
admire
the
bravery
of
taking
on
all
the
things
that
were
too
controversial
for
add,
but
it's
I
don't
understand
how
you
could
possibly
finish.
This
document
until
add
has
done
its
work,
so
I'd
be
puzzled.
If
this
was
something
that
could
be
adopted
right
now,.
P
It's
hard
to
speak.
I
I'm
sort
of
expanding
on
stephen's
comment
in
that,
although
I
think
that
it
is,
it
is
both
brave
of
jim
and
co
to
to
take
this
on
and
possibly
very
important
that
the
landscape
is
changing
pretty
fast,
not
just
an
add
in
other
places,
and
that
this
is
probably
not
the
time
to
write
down
what
we
actually
think
the
dns
operations
will
look
like.
P
I,
I
think
the
most
that
you
could
do
at
this
time
is
ask
a
whole
bunch
of
questions
which
you
have
in
sort
of
like
six
and
seven
and
and
other
parts
of
the
draft
that
are
more
about
you
know
here
are
the
considerations,
but
we're
not
telling
you
what
the
best
practice
is
yet.
So
I
I
think,
maybe
keep
those
around
and,
as
the
best
practices
emerge,
write
down
what
those
are
and
then,
when
you
have
that,
that
would
be
a
great
thing
to
document.
P
Q
Yeah,
thanks
tim,
I
think
I
I
agree
with,
I
think
was
mark
who
came
in
first.
I
I
think
the
document
does
serve
a
useful
purpose.
I
don't
see
the
dependency
on
the
add
working
group
work
needing
to
complete.
First,
I
think
it's
entirely
valid
to
document
the
sort
of
considerations
for
operating
networks.
Q
The
add
working
group
is
just
looking
at
resolver
discovery
and
selection,
so
I
think
they
can
quite
reasonably
run
in
parallel
and
if,
as
ben
suggested,
there
are
some
inaccuracies
in
the
current
draft,
then,
in
my
humble
opinion
those
need
to
be
fixed
and
and
again,
that's
not
a
reason
not
to
proceed
with
the
document.
So
I
think
it's
a
good
document.
It's
a
good
starting
point.
Let's
work
on
it,
I'm
happy
to
help
with
that.
R
Going
back
to
the
original
question
of,
should
it
be
done
here
as
in
dns
off,
I
would
say,
probably
not,
even
though
it's
about
operations,
it's
not
the
kind
of
operations
or
or
much
of
what's
in
this
document
and
probably
will
end
up
in
the
end,
is
not
the
kind
of
operations
that
this
working
group
typically
deals
with,
such
as
regulatory
and
interactions
with
with
other
parts
of
the
system
that
are
not
technical
interactions
and
such
like
that,
it's
certainly
as
it
progresses
should
people
like
like
it
would
make
a
lot
of
sense
for
the
document
authors
to
tell
dns
off,
hey,
we've
done
a
new
draft
or
whatever,
but
it
should
have
its
own
mailing
list
and
I'll
agree
with
some
of
the
people
earlier
who
said
it's
premature?
R
That
doesn't
mean
it's
it
like,
like
ted
said
that
doesn't
mean
we
shouldn't
start
on
looking
at
the
questions,
but
it's
vastly
premature
to
think
that
we're
within
months
or
even
like
you
know,
seasons
away
from
it
being
ready.
So
I
would
propose
it
doesn't
happen
here
what,
but
still
that
it
should
happen.
Thank
you.
A
Okay
thanks,
so
a
few
comments
when
jim
came
to
me
came
to
us
about
this.
I
sat
down
and
read
it
and
I
understood
the
operational
point
of
views
but,
as
I
pointed
out
to
him,
the
reports
in
there
like
the
policy
stuff
which
it
just
did
just
it's
got.
A
You
know,
there's
just
no
place
sort
of
thing
and
we
just
that
will
just
be
a
minefield,
but
there
are
things
that
should
be
documented
and
I
think
you
know
ted
pointed
out
some
of
those
as
well
and
it
definitely
needed
to
be
reworked
if
we
were
gonna
take
it
on
which
I
wasn't
sure.
I
also
suggested
if
it
looks
like
it,
we
don't
take
it
on
which
you
know
working
group.
A
He
can
go
independent
stream,
but
then
it'll
always
kind
of
sort
of
pass
through
us
to
sort
of
get
vetted
at
some
level.
But
I
do
agree
that
some
of
this
needs
to
be
sort
of
fleshed
out.
I
think
what
they're
looking
at
is
as
you
deploy
dough.
What
do
you
have
to
worry
about
right
but
correct
the
policy
stuff
and
things
of
that
nature?
That
makes
me
really
nervous
from
a
sort
of
a
chair
point
of
view.
I
M
I'll
just
say
I
don't
know
so
I
I
take
the
point
that
the
draft
attempts
to
describe
the
existence
of
certain
policy
issues
without
getting
too
specific
about
what
those
exact
issues
are.
But
I
don't
think
that
this
is
really
our
place
and
I
don't
think
it's
really
useful.
M
That
is,
if
we
don't
have
anything
concrete
or
specific,
to
say
about
policy
and
compliance,
then
we're
not
doing
anyone
any
favors
by
noting
that
policy
issues
exist,
especially
because
when
we
make
mention
of
these
policy
issues
whatever
they
might
be,
we
implicitly
we
engage
a
problem
that
that
occurs
frequently
across
the
ietf,
where
by
documenting
anything
in
an
rfc,
it's
very
easy
to
accidentally
lend
it
the
impremature
of
the
iedf,
and
we
should
be
very
careful
not
to
imply
that
certain
policy
choices
are
correct
or
incorrect
or
that
the
interpretation
of
those
policies
as
binding
particular
parties
are
correct
or.
A
Incorrect
andrew
we'll,
let
you
wrap
it
up
and
then
we'll
get
on
to
the
next
presentation.
Q
Okay
thanks,
I
was
just
going
to
just
pick
up
on
that
last
point
from
from
ben.
I
I
think
it's
reasonable
to
note
that
the
policy
considerations
can
exist
in
certain
areas
not
to
make
recommendations
as
to
what
stance
to
take
on
those
considerations,
but
I
think
it's
entirely
right
to
highlight
that
they
exist
and
by
the
way,
most
of
the
them.
Q
As
I
read,
the
document
exist
for
all
reserve,
resolver
operators,
whether
they're
network
operators
or
not
so
it'll,
be
useful
to
have
them
captured
somewhere,
and
this
document's
a
good
place
to
capture
them.
Q
B
Yeah,
just
to
sort
of
I
thought
it
would
be
good
to
get
on
the
on
the
record.
The
conversation
that's
been
going
on
in
the
in
the
the
chat,
also
that
we
do
sort
of
at
some
point
need
to
figure
out
if
this
is.
If,
if
we're
going
to
say
this
is
not
in
scope
for
dinosaur
and
the
the
ise
does
include
a
conflict
review,
I
have
to
say
that
to
a
first
approximation.
B
I
don't
think
that's
a
problem,
because
the
conflict
review
is
about
whether
the
work
is
the
work
in
an
independent
submission
draft
is
in
conflict
or
contradiction
to
working
group
work
and
what
has
happened
before
with
conflict
review
situations.
B
Is
that
if
we
say
that
the
working
group
had
a
chance
to
discuss
the
draft
had
a
chance
to
consider
the
issues
and
there
there's
no
over
there's
no
specific
conflict
with
other
work
going
on
in
the
working
group.
Yeah,
that's
not
a
problem,
and
the
point
is
not
to
presuppose
the
outcome
of
the
discussion
about
the
fate
of
this
draft,
but
only
to
say
that
we
have
a
fair
amount
of
flexibility
as
the
working
group
to
determine
what
work
we
take
on
and
if
people
decide.
B
B
A
B
B
Yeah,
what
I
would
suggest
is
both
to
the
mailing
list.
If
you
know
people
want
to
consider
continue.
The
discussion
also
drop
a
note
to
the
authors.
B
You
know
private
discussion,
I'm
sure
that
that
feedback
would
also
be
welcome
and
there's
a
really
interesting
discussion
going
on
here.
So
please
do
feel
free
to
continue.
Thank
you.
B
K
K
These
are
my
motivations
genetic
specifications,
don't
protect
the
appearance,
side
nsl
and
will
record
in
the
delegation
information.
It
is
a
missing
piece
of
dns.
Why
here
inside
any
services
and
will
record
the
non-authoritative
data
of
parent
zone?
Parenthood
cannot
sign
no
authority
data.
Also
additive
servers
can
be
moved.
A
part
of
guru
records,
chrome
response
packet
records
are
not
well
or
exactly
defined.
K
K
K
To
oppose
that
guru
records
are
expected
to
be
returned
as
part
of
referrals
before
and
if
they
cannot
be
fixed
into
the
into
the
udp
response
teaching
equal
one
must
be
set
to
inform
the
grant
that
the
responses
response
is
incomplete
and
that
tcp
should
be
used
to
retrieve
the
full
exports
and
many
areas.
Software
developers
understand
that
referrals
will
record
non-authoritative
data.
K
K
K
These
are
responses
comments
from
the
submarine
list
who
signs
dsdis
is
a
part
of
the
srl
set.
It
is
signed
by
parent
zone
and
it
it
is
the
same
as
the
dsd
arrow
set
fields
and
pd
zone
would
become
big
because
current
ds,
registration
ratio
is
very
low
and
the
ice
adds
ps
and
seconds
and
rs6
to
all
delegations.
K
K
K
K
A
F
All
right
thanks,
thank
you
for
writing
this
draft.
I
effect
proposed
something
quite
like
it
in
deep
drive
a
few
months
ago.
People
did
not
like
it
at
the
time,
but
I
feel
that
something
like
this
might
be
the
key
to
making
authoritative
dlt
work
with
tlsa
records.
F
M
Ben,
I
think
this
draft
is
very
interesting
to
peter's
point.
It
definitely
overlaps
with
a
bunch
of
things
that
are
happening
in
deep
private.
I
would
definitely
move
it
from
dns
up
to
deprive
you
know,
I
think,
to
figure
out
if
it
makes
sense
we're
going
to
first
need
to
understand
the
bigger
picture
of
off
d.o.t
to
see
if
there's
a
place
for
it.
A
A
A
I
I
My
concern
here
is
that
we've
already
got
a
lot
of
complicated
stuff
around
zone
cuts
and
we'll
end
up
less
than
the
hard
way
with
dns
sec,
and
I
think
adding
more
complexity.
Here
could
make
things
even
worse,
and
it's
not
clear
to
me
at
least
at
the
moment
that
we're
actually
going
to
get
a
big
benefit
from
deploying
this.
I
think
this
needs
a
little
bit
more
of
a
cost
benefit
calculation
to
be
worked
out
thanks.
A
Okay
thanks
peter
and
olaf-
we've
got
a
few
more
minutes
before.
I
think
we
drop
so
go
ahead.
Peter.
A
A
A
Okay,
I'd
say:
let's,
let's
jump
to
olaf
and
then
peter
can
figure
out
the
mic
thing
we'll
go
back
to
that
how's.
That.
S
Suzanne,
can
you
raise
your
thump
if
you
hear
me
good
so
on
that
first
question,
why
did
we
design
sign
referral
information?
Not
to
sign
that?
S
I
was
you
know
the
dns
dsx
chair
at
the
time,
and
I
recall
that
we
were
very,
very
careful
to
not
muck
about
with
what
we
understand
of
the
dns
at
the
time
that
we
did
this
work
and
the
introduction
of
ds
record
as
an
authoritative
bit
of
information
about
the
child
was
something
that
we
that
was
a
little
bit
over
a
jump
into
uncertainty.
It
turned
out
to
work.
It
turned
out
to
not
have
all
kinds
of
side
effects,
but
we
were
pretty
afraid
to
do
that.
S
A
A
B
Only
that
we
should
we
should
be
saying.
Thank
you
very
much
to
everyone
who
participated
this
the
this
week.
Our
both
of
our
sessions
have
been
treating
everybody,
treating
a
lot
of
our
participants
to
jet
lag
without
the
travel,
which
has
been
awkward.
I
think
for
a
lot
of
folks.
So
thanks
everybody
for
showing
you
for
for
for
attending
and
discussing
and
participating.