►
From YouTube: IETF104-DNSOP-20190329-0900
Description
DNSOP meeting session at IETF104
2019/03/29 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
C
E
D
The
procedure
here-
I'm
Beto
Susanne
over
there
Timmy's
in
the
room.
These
are
the
chairs
Warren.
Our
ad,
then,
is
our
jabber
for
this
for
this
morning's
session
and
so
sorry
Paul
yeah
excellent.
Thank
you.
Paul
is
the
scribe
or
sodium
in
yeah.
The
minutes
make
minutes
taker.
Please
state
your
name
at
the
microphone.
Show
your
tag
to
Paul.
If
you
ask
for
get
the
note
well
take
care
of
that
everybody
notes
the
note.
Well
blue
sheets,
please
fill
in
the
blue
sheets.
It's
a
good
crowd.
D
We
didn't
want
to
have
this
kind
of
size
ball,
but
a
little
bit
we
could
do
with
half
of
the
size
of
the
room,
but
we
definitely
want
large
rooms
next
time
again
so
fill
in
the
blue
sheets
agenda
for
today,
normally
Tim
takes
care
of
the
nice
pictures.
I
was
not
that
inspired
to
I.
Do
the
towing
car.
D
So
we
one
thing
we
people
say:
well,
you
bring
too
much
work
into
the
working
group
so
going
into
the
working
group,
but
also
we
want
to
move
further
with
the
a
name
we
added
yesterday
actually
yeah
on
the
agenda
and
move
it
again
ahead.
So
this
is
the
team
towing
car,
New
York.
This
session
primarily
is
about
new
work,
so
there's
four
presentations,
two
presentations
on
new
work,
three
days
for
new
work,
one
presentation
by
Steven
about
other
working
group
activities
outside
the
Dean
is
up,
but
should
be
mentioned
over
here.
D
Our
work
is
on
data
tracker
and
on
github,
so
we
try
to
be
as
transparent
as
possible.
Please
talk
to
us
if
we
aren't
some
other
thing.
I
should
mention.
I
was
told
me,
but
actually
I
should
have
done
come
to
the
conclusion
myself
is.
There
was
yesterday
there
was
an
pump
award
and
some
of
our
colleagues
in
the
room,
and
it
was
the
best
data
set
award
on
cue
name.
Minimization,
collection
and
short
message
is
nothing
to
worry
all
good.
So
cue
name
is
great.
D
It's
good
for
the
working
group
to
know
that
we
are
doing
work
that
makes
sense
here.
I
think
this
is
the
agenda
so
long
data
tracker
I,
don't
have
to
go
through
the
different
items.
Here
we
end
with
the
a
name
discussion.
We
have
five
minutes
I
think
we
can
get
started
Giovanni.
Can
you
thank
you
any
other
questions
about
agenda?
Actually,
we
call
it
agenda
restructuring
No.
F
F
This
is
an
information
or
draft.
Oh
yeah,
here
I
had
put
here
the
list.
The
links
for
the
versions
I
had
sent
to
the
lace
over
there.
Responses
are
not.
We
are
doing
this
draft
on
a
github
and
also
that
the
NS
all
chairs
have
asked
us
to
try
to
get
feedback
from
other
sources
or
other
operators
and
I
did
that
and
there's
a
link
there
for
the
discussion,
or
at
least
alright.
So
this
dress.
It's
like
a
product
of
work
of
13
researchers
that
have
been
doing.
F
We
have
been
doing
a
bunch
of
research
breakers
on
DNS
over
the
last
three
four
years
and
what
we
have
done
is
get
those
papers.
Try
to
find
recommendations,
gather
recommendations
for
operators,
DNS
operators.
There
were
like
four
IMC
papers,
one
pem,
which
is
the
conference.
It
just
happened
by
the
way,
but
that
papers
are
here
the
problem
with
papers
for
operators
are,
they
tend
to
be
long?
F
It
take
a
lot
of
time
and
I
see
that
that
in
L
folks
at
the
side,
the
end
they
like
the
papers,
but
sometimes
they
don't
have
the
time
to
read
that
so
our
idea
is
to
get
this
papers,
put
it
on
a
list
iterate
through
the
list
and
apply
at
T
to
longer
to
read,
write
a
filter
on
that
and
just
bring
the
recommendations.
So
that's
exactly
what
the
ops
folks
ask
and
accompany
it.
Sida
knows
all
right:
let's
do
this
try
to
have
tangible
direct
recommendations
and
if
those
recommendations
are
backed
by
measurements.
F
So
if
you
want
to
know
why
we
pointed
to
the
papers
there,
so
the
target
group
here
is
large,
authoritative,
DNS
operators
with
global
traffic,
like
I,
have
my
own
personal
domain.
I,
don't
need
to
follow
the
recommendations
on
this
raft
for
my
domain
that
gets
no
traffic
at
all.
So
this
is
the
recommendations
in
a
nutshell,
we
have
six
of
those
here,
and
these
are
the
reference
papers
here.
You
know
be
going
through
each
of
them
now.
The
first
recommendation
states
that
you
should
use
equally
strong
IP
anycast
in
every
authoritative
server.
F
That
means
NS
record
by
the
way
to
achieve
the
like
start
over
even
loads
of
distribution.
So
the
recommendation
derives
from
the
fact
that
a
resolver
we
did
a
measurement
paper
on
that
and
if
you
have
for
a
certain
zone,
four
five,
whatever
authoritative,
nameservers
and
s
records
resource
you
get
to
choose
which
one
they're
going
to
send
the
queerest
you
but
they're
gonna,
send
queries
to
all
of
them
in
regardless
of
the
round-trip
time
between
the
resolver
and
l2
rotative,
closer
resolvers
would
get
more
traffic
so
for
ops.
F
That
means
that
all
right,
so
if
you
have
like
multiple
rotators,
you
have
taught
my
sort
all
of
them.
They
all
have
to
deliver
good
laters
for
a
global
clients
and
by
definition,
unicast
can't
do
that
a
site,
a
client
in
California.
We
always
have
longer
latency
to
alter
it,
a
unicast
server
located
in
Europe
or
Japan,
because
it's
a
graphical
distance.
So
this
original
paper
recommendation
number
one
recommended
using
any
casting
I
was
rated
nameservers.
F
All
your
NS
records
and
have
like
strongly
and
strongly
here
in
the
cast
means
like
in
terms
of
peering
and
capacity
and
phase
out
unicast,
and
we
have
that
lie
that
not
me,
my
colleagues
as
operations
team
that
I
know
they
have
deployed
that
we
used
to
have
seven
or
82
name
servers,
a
mix
of
any
cast
and
in
the
cast,
and
now
have
only
for
any
case,
recommendation
member
to
routing
can
matter
more
the
location.
F
So
this
is
the
case
when
folks
are
gonna,
hire
or
engineer,
alternative
name
servers,
and
if
there's
also
sort
of
assumption
that,
if
you
have
more
sites
more
instance,
more
locations,
you're
gonna
have
lower
latency,
so
paper
number
two
he
or
show
that's
not
always
the
case.
This
was
as
analysis
that
they
have
done
with
right
passes
and
they
measure
the
median
latency
to
different
route
server.
F
Ladders-
and
you
see
the
size
of
those
deployments
like
air
route,
has
144
sites
around
later
instances
around
the
time
and
see
Ruth
had
eight
and
they'll
deliver
similar
median
latest
values
between
30
and
32
milliseconds
for
all
this
right
headless
probes.
So,
in
other
words,
when
choosing
that
you
have
to
be
careful
not
only
considering
number
of
sites,
but
also
the
peering
in
location
where
they
actually
located
and
why
this
happens,
because
BGP
is
agnostic,
your
geographical
distance.
F
So
the
recommendation
on
virtual
here
suggests
that
you
should
consider
route
a
net
current
connectivity,
also
when
engineering
DNS
any
can't
services
they've
also
found
that
web
sites.
That
is
good,
an
offer
global
latency.
But
if
you
really
want
to
have
more
change
in
here
for
DDoS
attacks
recommendation
number
tree,
this
refers
to
fir,
filter
and
refers
to
collecting
any
cast.
The
tyranny
cast.
Catchment
Maps
ahead
of
actual
deployment
can
improve
engineering
designs.
So
let's
say
you
have
run
one
authoritative
nameserver
with
five
instances.
F
F
F
Sorry
I
don't
have
the
time
to
work
over
all
the
things
here,
but
you
can
ever
even
use
that
before
deployment
in
a
new
perfect
that
are
you,
gonna
deploy
any
caste
or
on
prefix
study
announced
for
the
same
locations,
but
not
in
your
production
network,
and
you
can
actually
predict
the
catchment
and
the
curio
distribution.
They
run
that
on
be
Route.
One
be
route,
went
from
unicast
to
any
cash
that
it
predict
very
precisely.
How
would
be
the
load
query?
Distribution
to
the
la
excite
it
can
see
that
were
on
a
1.6
was
predicted.
F
81.4
was
a
little
depth
of
the
surgeon
percentage
in
LAX,
and
this
tool
has
been
deployed
on
any
cast.
That's
bad,
there's
a
testbed
that
we
have
a
bunch
of
tests,
they're
a
bit
route
and
a
large
an
operator
as
well
I,
like
recommendation
over
for
when
under
stress
there
we
should
recommend,
is
to
employ
two
strategies.
So
let's
say
here
you
have
your
your
any
cat!
Your
any
cast
name
server
with
this
sides
here
those
locations
actually
and
there's
a
DDoS
attack.
So
what's
gonna
happen,
that
BGP
is
gonna
map.
F
F
Another
thing
you
can
do
is
do
a
bunch
of
manipulations
on
routing
you
can
like
prep
and
routes,
withdraw
routes,
inĂ¡cio
sites
which
be
black,
holding
in
an
attempt
to
chip
the
traffic
into
a
distribution
of
queries
that
matches
your
capacity,
your
sights
your
locations
and
Vegas.
The
best
option
depends
on
attack
itself
and
your
infrastructure
specifics
as
well.
So
so
that's
the
that's
the
summary
so
two
strategies
either
do
nothing,
allow
the
website
to
play
and
become
like
absorber
or
withdrawal
and
try
to
ship
the
traffic.
F
What
should
have
a
new
project
working
specifically
on
that
to
try
to
figure
out
how
we
can
actually
do
this
better
details?
We
recommendation
number
five
suggests
you
should
consider
using
longer
TTL
values
for
NS
record
for
DNS
records.
Whenever
possible
details.
They
said,
like
term
limits
or
how
long
queries
should
remain
in
resolvers
cache.
It's
a
sort
of
a
ephemeral
replication
for
those
on
file.
F
Anyway,
study
number
five
immolates
DDoS
attacks
with
various
different
packet
losses.
We
gotta
use
IP
tables
to
drop
packets
of
those
losses,
and
this
figure
here
shows
blue
here.
Our
clients
get
an
answer
and
the
arrow
going
down
around
ten
before
ten
seconds.
Ten
minutes
here
shows
when
the
immolated
DDoS
attack
started,
and
you
see
here
that
this
are
phased
at
all
the
cash
was
working.
F
It's
a
key
component
of
DNS
resilience
and
TTL
is
highly
correlated
to
that
you,
their
choices,
have
the
power
to
say
how
long
it's
gonna
be
in
the
cache
there
for
how
long
clients
can
resolve
the
domain
in
the
unlikely
event
or
the
event
of
unavailability
of
this
authoritative
servers.
So
caching
is
a
key
component.
Resolver
will
do
their
job
trying
to
resolve
the
domain.
They
gonna
try
to
switch
from
server
to
server,
even
if
that
means
like
hammer
doctor
tape
service,
even
under
those
effects.
F
So
recommendation
number
five
is
like
use
longer
details
whenever
possible,
but
of
course
there's
no
one-size-fits-all
solution
here,
we're
actually
working
on
a
new
measurement
paper
for
the
next
conference
and
measurement
conference
and
that
exactly
works
on
try
to
figure
out
a
better
way.
You
recommend
details
all
right.
Recommendation
number,
six
sure
infrastructure
risks,
collateral
damage
during
attacks,
so
you
gotta
be
careful
when
engineering
DNS
services
colocation
implies
you
share
some
parts
of
the
infrastructure
and
this
study
number
four.
F
We
found
that
when
the
routes
were
attacked
back
in
2015,
some
Danelle
sites
co-located
or
they
had
some
sort
of
a
share
infrastructure,
they
also
suffer
observe
higher
rates
of
packet
loss
under
NL,
even
though
that
I
know
was
not
attacked
and
the
dine
took.
All
the
16
attacks
show
similar
results.
Multiple
zones
were
partially
reachable
when
these
NS
were
attacked.
So
the
conclusion
the
recommendations
I
you
gotta,
be
aware
of:
share
infrastructure
risks
like
if
you
share
for
structure,
you're
gonna
be
running
at
risk.
F
G
8,000,
doubtless
Propst
is
basically
most
of
the
Atlas
network.
Isn't
it
yes
X
only
so
this
is
not.
This
is
not
a
distance.
Equalized
distribution
of
probes,
5,000
of
those
probes
are
in
Europe.
5,000
of
those
probes
are
one
hop
from
DC
D
kicks
or
m6,
or
links
where
there
will
be
any
caste
instances
of
these
routes.
So
in
the
statistical
distribution
of
the
average
latency,
the
rtt
most
of
the
european
nodes
are
low
RTT
from
a
route,
but
if
you
are
in
South,
America
or
Japan
or
Korea
or
Africa,
these
figures
would
not
happen.
G
F
G
H
Wes
so
sorry,
co-author,
Wes,
her
karai's
I
am
real,
quick
point
that
I
think
we
could
get
into
the
technical
details
of
each
of
the
studies
in
here
and
I.
Think
from
the
perspective
of
today,
it
would
be
best
to
decide
two
things,
one,
as
the
draft
worth
you
know,
pushing
forward
in
the
idea
and
right
which
academic
papers
are
worth.
You
know
like
keeping
in
the
draft
as
a
recommendation,
and
maybe
we
throw
some
out.
Maybe
somebody
has
some
more
that
we
can
add
in
this
was
an
academic
peer-reviewed
paper.
H
D
F
A
System
but
our
informational
is
the
goal,
not
BCP.
No,
no
I
I,
like
the
things
that
you
observe
in
this
document,
but
I
would
very
very
strongly
recommend
against
calling
them
recommendations,
observations,
fine
suggestions,
so
things
to
think
about
fine,
don't
make
them
recommendations,
because
there
are
so
many
different
things
going
on
out
there
on
the
network.
A
So
if
you,
if
you
change
the
entire
tone
of
the
document
into
these,
are
things
we
have
observed
observed-
and
these
are
things
you
need
to
think
about
when
you,
when
you
deal
with
in
the
relationship
with
any
cost
operators
and
so
on,
I
would
happily
support
it,
but
but
in
the
current
tone
that
you
have
I
will
not
support
this
document.
All
right
thanks.
F
A
F
A
F
A
H
J
J
One
concern
is
I
think
it
was
already
recorded
as
an
issue
on
your
draft,
it's
not
for
ulcerative
or
nameserver
operators.
It's
all
very
big.
Also.
It
is
named
several
operator,
so
people
may
not
exactly
the
title
on
the
introduction
of
the
draft
today.
It
does
not
reflect
this,
so
people
who
manage
a
small
zone
or
not
so
small,
actually
may
don't
see.
J
F
K
F
So
this
is
the
this
experiment.
You
had
a
TTL
of
one
hour
so
allow
all
the
probes
on
resolvers
to
run.
Send
the
first
queries
with
no
problems
at
all
and
then
at
time
equals
to
9.
We
start
to
drop
one
out
of
the
packets.
Ok,
so
you
started
to
draw
pretty
quickly
after
getting
yeah
yeah
get
into
the
cache.
There
are
many
more
expressing
a
paper.
We
vary
when
instructure
drop
in
about
the
details,
but
it
was
just
the
easiest
to
show
here
and
what
happens
is
like
here.
F
K
M
N
M
M
The
problem
that
I
have
with
this
draft
aside
from
the
topic
matter,
is
that
I
think
the
papers
I've
read
had
quite
nuanced
and
subtle
conclusions
that
worked
very
very
carefully
framed.
They
didn't
make
general
observations
across
the
entire
system,
because
there
are
some
good
papers
and
they
made
very
specific
observations
that
you
have
to
understand
in
the
context
of
the
measurement.
They
didn't
make
very
broad
claims.
However,
this
document
does
make
very
broad
claims
and
I
think
you're,
trying
you've
drawn
recommendations
that
are
overly
broad,
given
the
justification
of
the
measurement
and
I.
M
Don't
think
it's
it's
sensible
to
say
this
recommendation
advise
suggestion.
Whatever
is
justifiable
because
there
was
measurement.
If
you
look
at
the
measurement,
the
measurements,
actually
it
looking
at
something
very,
very
narrow,
I
think
you
have
to
be
very
careful
about
taking
and
I
say
this
is
somebody
used
to
play
Tony
cast
a
few
times
and
I
know.
F
Yeah,
thanks
for
your
feedback,
I
mean,
of
course,
there's
a
lot
of
details
in
here.
If.
M
This
was
more
like
a
literature
review
of
any
cars
related
stuff,
published
to
a
rounding
audience
about
academic
insights
into
into
any
class
routing.
I.
Think
that
would
be
a
lot.
It
would
be
a
lot
easier
to
understand
what
the
draft
was
for
because,
as
it
stands,
I
don't
it's
not
that
I
just
disagree
with
the
word
recommendation,
I
think
whatever
you
call
it.
These
are
too
broad
and
and
you're
presenting
them
as
something
that
is
true
across
the
board,
and
it's
other
than
that's
right.
B
O
It
turned
out
that
the
working
group
couldn't
agree
on
this,
because
there
are
multiple
considerations
that
kick
in
when
it
comes
to
to
TTLs
in
particular,
so
if
at
all,
I
I
recommend,
in
that
case,
to
drop
this
topic
from
from
the
list
of
issues
that
you
cover
in
the
document
because,
for
example,
in
the
previous
session,
we
had
someone
having
good
reasons,
maybe
to
argue
for
shorter
details.
In
certain
circumstances.
That
said,
TTLs
are
not
necessarily
consideration
for
authoritative
server
operators.
O
They
are
considerations
for
people,
designing
the
content
that
is
zone
maintenance,
then
that
might
be
a
different
audience.
However,
what
Lehmann
said
what
Joe
said:
I'm
all
in
favor,
of
making
these
economic
papers
accessible,
more
accessible
to
operators
by
way
of
literature?
Survey
like
like
Joe
said,
but
I
also
don't
fully
agree
that
the
papers
should
result
in
recommendations,
the
observations
and
that,
for
that
matter,
the
selection
of
papers
could
benefit
for
a
bit
more
diversity
in
contributors
compared
to
what
we
have
today.
D
D
R
S
So
Dina's
cookies
are
a
measurement
against
amplification
text.
The
the
current
we're
a
botnet
is
used
to
let
bot
sense,
a
small
query
to
a
name
server
which
would
result
in
a
large
answer,
because
there
are
source,
IP
addresses
are
spoofed
and
the
source
IP
address
is
the
IP
address
of
the
victim
victim.
You
look
at
other
large
answers,
so
the
cookies
are
there
to
sit,
have
a
relationship
between
a
query
sender
and
a
creative
II
player
and
to
make
it
work
both
so
I'll
part
everything
needs
to
do
the
Venus
cookies.
S
You
cannot
have
one
our
tortoise
sheriffing
in
a
set
of
authority
surface
not
doing
Dena's
cookies
and
also
the
solver
needs
to
do
Dena's
cookies
to
benefit
from
this,
and
so
not
even
the
cooperation
is
desirable,
so
this
is
I
just
described.
It
basically
client
a
query,
sending
name
server,
which
is
usually
a
resolver
since
creates
a
client
cookie
from
the
IP
address
of
itself,
and
the
IP
address
of
the
server
at
selling
to
the
name.
Serve
thee
out.
Dorsetshire
firm
actually
derives
from
the
client
cookie,
antique
light,
IP
address
and
some
secrets.
S
The
surfer
cookie
returns
that
to
the
client
and
then
next
time
the
client
sends
along
the
surfer
cookie
with
its
client
cookie,
and
the
server
can
recognize
its
own
cookie
because
it
can
recalculate
its
from
the
clients
and
then
when
it
receives
a
fellow
surfer
cookie
it.
It
knows.
I
had
interaction
with
this
client,
so
its
source
IP
address
is
not
spoofed,
so
I
can
serve
at
large
answers
or
not
do
response
rate
limiting.
S
S
Donat
is
like,
and
Mark
Andrews
also
created
a
draft
how
to
create
surfer
cookies
to
deal
with
this
problem
just
before
the
submission
deadline
didn't
make
it
yet,
so
he
had
a
meeting
with
them
yesterday
and
decided
to
merge
them
so
far.
What
came
out
of
this
for
us?
So
in
our
initial
draft
we
had
multiple
algorithms,
but
from
discussion
with
with
Donald,
we
decided
to
to
have
a
single
table
for
INR
separate
history
in
a
surfer,
cookies
versions
in
the
DNS
registry.
S
Thinks
that
we
still
need
to
do
is
to
think
about
a
write
down
how
to
do
surface
secrets
or
alpha,
though,
and
how
to
do
is
regularly
implementation
advice
on
how
to
do
that
smoothly
and
then
x8x
test
factors,
and
so
because
we
have
multiple
algorithms,
initially
T.
Initially
in
our
draft,
it's
now
called
Deena's
cookies,
algorithms,
I
think,
since
we
now
have
just
one
single
algorithm
and
one
single
version,
it's
better
to
renamed
it
off
the
shelf.
T
Paul
Hoffman,
why
did
you
choose
SIP
house
given
that
it's
like
not
at
all
standard
and
is
brand
new
and
pretty
much
isn't
in
many
of
the
crypto
libraries?
Yet
I
mean
it
will
be
it's
it's
not
like
obscure,
but
it's
it's
newer
than
anything
and
it's
faster
by
a
bit.
But
why
I
pick
something
like
that?
I
think
I.
U
Can
answer
that
this
hombre
and
I
see
while
the
sea
flesh
was
chosen,
because
this
is
a
good
fit
and
it's
even
though
it's
a
new,
it's
already
used
everywhere
for
full
collision
resistance.
If
you
look
at
it's
everywhere,
it's
in
all
programming
languages.
You
use
the
sebaceous
used
for
collision
resistance.
U
S
Q
D
Okay,
we
wanted
to
go
for
fast-track
now,
but
I
think
this.
It
really
solves
an
operational
problem.
We
had
a
operational
problem,
so
we
want
to
we'll
send
out
a
call
for
adoption.
That's
in
working
group
activity
document
draft
later
on
the
mailing
list,
but
I
do
see
I
think
in
the
room,
positive
vibes,
I
think
positive.
In
accepting
this
work
as
a
yeah.
S
V
B
So
hi
I'm,
Suzanne,
Wolfe
and
usually
I
sit
over
there
as
co-chair
of
DNS
op,
but
at
the
moment
no
hats
I'm,
also
a
in
a
few
hours
ex-member
of
the
IAB.
Also
a
hat
flung
away,
but
I
wrote
this
draft,
which
I
didn't
do
a
lot
to
draw
attention
to
and
sure
enough
it
didn't
get
much.
So
the
purpose
here
is
to
get
people
to
read
the
draft
and
comment
and
hopefully
make
it
a
better
better
work.
B
Subject
is
RFC
67
61
in
special
use
names.
We
are
not
here
to
recap
the
history
again
well
to
to
fight
over
the
history.
This
is
my
personal
view
of
the
broad
outlines
of
what
happened
and
isn't
the
most
important
thing
here,
but
since
it
was
several
years
ago
only
started
to
need
to
RFC
67
61
establishes
a
registry
for
domain
names
that
are
be
treat
to
be
treated
as
special
and
outside
of
the
DNS.
B
It
requires
that
the
use
of
the
proposed
special
use
name
be
described
along
certain
axes,
but
mostly
those
focus
on
how
the
name
interacts
with
the
DNS.
There
are
some
broader
architectural
questions
and
protocol
questions
that
are
not
addressed
at
all.
This
was
in
the
interest
of
providing
flexibility,
but
it
also
means
that
it
can
be
hard
to
apply,
and
the
registry
policy
includes
iesg
judgment
and
their
the
the
boilerplate
on
the
registry
has
standards,
action
and
iesg
approval
which
again
provides
for
flexibility
but
also
provides
for
challenges
in
consistency
and
and
and
clarity.
B
Deana,
stop
actually
agreed
earlier.
You
know
a
few
years
ago
to
discuss
special
use
names.
Broadly,
we
got
some
orchid.
We
got
some
decent
work
out
of
it.
We
got
some
insight
out
of
it.
Rfc
8240
for
special
use,
domain
names,
problem
statement,
seventy
six,
eighty
six
dot
onion,
and
there
was
some
discussion.
Although
not
a
lot
of
conclusion
of
the
impact
there
is
a
liaison
between
the
IETF
and
I.
B
B
What
do
you
need
further
from
us,
and
at
this
point
it
seems
like
the
question
that
it
would
be
useful
for
us
to
focus
on
is
how
should
the
is
G
and
the
IETF
apply
the
notions
in
RFC
67
61,
regardless
of
the
drama
around
the
edges
of
these
questions,
it
seems
to
happen
and
will
continue
to
happen,
that
IETF,
dug
working
groups
sometimes
need
special
use
names
in
the
protocols,
and
there
are
real
questions
there.
Protocol
and
architecture
relevant
questions
around.
How
do
you
specify
such
names?
How
do
you
pick
a
string?
B
B
In
a
case,
for
instance,
where
the
proponents
feel
a
stirring
might
have
to
be
delegated
as
a
TLD
for
the
protocol
to
work
properly
a
situation
that
has
come
under
discussion
in
several
cases,
the
IETF
cannot
do
that.
It
also
may
be.
The
assurance
could
be
required
for
the
string
that
the
string
won't
be
delegated
as
a
TLD,
to
avoid
name
collisions
and
for
a
protocol
to
work
properly
and
again.
The
IETF
is
not
in
a
position
to
speak
for
another
organisation
regarding
what
it
will
do
with
its
responsibilities.
B
It
acknowledges
that,
needing
that
having
a
case
where
you
need
a
TLD
can
be
really
difficult,
it
makes
things
harder
and
that
names
elsewhere
in
the
hierarchy
of
domain
names
are
going
to
work
for
for
protocol
purposes.
Most
of
the
time
we're
suggesting
you
know,
I'm,
suggesting
that
the
idea
that
I
ATF
working
groups,
you
need
to
think
about
if
you're,
if
you're
allocating
domain
names
as
part
of
your
protocol
or
assuming
certain
behavior
around
domain
names
in
your
protocol,
you
think
about
what
characteristics
they
need
to
have
one
date.
The
names
need
to
have.
B
Are
they
going
to
be
human
visible?
If
not
it
doesn't
matter
if
they're,
the
string
is
pronounceable,
for
instance,
think
hard
about
whether
especially
his
name
actually
helps.
We've
seen
discussions
and-
and
you
know,
barroom
arguments
about
having
a
barrier
that
it
might
actually
be
a
better
protocol
design
without
them.
You
know
it
can
be
an
easy
solution,
but
it's
not
necessarily
a
good
one.
Again,
try
not
to
need
a
TLD
just
because
it's
so
much
more
work
than
a
name
elsewhere
in
the
namespace.
If
you're
talking
about
an
IETF
protocol
and
IETF
activity,.
B
B
They
would
like
to
have
an
IETF
consensus
document
which
may
or
may
not
formally
update
67
61,
but
the
intention
is
probably
guidance
for
IETF
working
groups
and
possibly
to
non
IETF
proponents
of
special
use
name
reservations
as
a
second-order
goal.
It
seems
like
a
good
idea
to
avoid
each
request
for
a
special
use
name
going
to
DNS
op
for
ad-hoc
review,
since
folks
here
are
not
necessarily
going
to
be
experts
on
the
protocols
that
are
great,
that
created
the
requirement
for
a
special
use,
name
or
the
characteristics
of
that
protocols.
B
Use
requests
can
burn
up
a
lot
of
time
and
cycles
and
we
always
have
a
lot
of
work
to
do
in
the
working
group
on
other
topics,
and
it
just
seems
appealing
from
the
engineering
point
of
view
that
we
could
reuse
some
of
this
challenging
and
painful
experience.
We've
had
there's
another
issue
that
we
discovered
in
the
course
of
earlier
discussions
about
this.
That
could
be
rolled
into
this
document
having
to
do
with
the
IAB
and
DARPA
RFC
3172.
B
B
B
We
can
go
ahead
and
update
3172
or
not
currently,
there's
an
IETF
standards
track,
RFC
required
for
the
IEEE
Abita
Act,
but
some
of
the
pressure
for
special
use
names
is
coming
from
outside
of
the
IETF.
Does
it
make
sense
to
say
that,
under
certain
circumstances,
which
we
would
specify
a
delegation
under
is
available
beside
side
of
standards,
action?
B
B
Do
we
need
to
propose
some
new
mechanism
for
coordination
around
the
possibility
that
there
will
be
a
compelling
need
for
a
special
use
TLD
at
some
point,
I,
don't
think
it
requires
new
process.
We
have
a
liaison
relationship.
We
have
a
good
history
of
the
IETF
slays
on
relationships
working
out
reasonably
well,
but
again,
it's
something
to
discuss.
Do
we
adopt
it
as
Dan
asam
go
for
it.
Warren's
jumping
out
of
his
shoes
would.
V
You
mind
going
back
to
slide,
5,
sorry,
Warren,
Kumari,
so
I'm
sure
everyone
here
remembers
the
onion
discussions
and
they
were
long
and
painful,
and
it
would
be
really
really
really
nice
if
we
could
avoid
having
those
sort
of
discussions
again.
So
I
know
that
the
working
groups
really
tired
of
this
topic,
but
it
would
be
great
if
we
could,
you
know,
work
on
it
again
spend
some
time
getting
some
sort
of
closure.
V
So
in
the
future
there
is
some
guidance
and
we
don't
have
sort
of
start
the
process
again
and
be
like
what
did
we
do
last
time?
So
yeah
I'd
really
encourage
us
to
work
on
it.
You
know
whether
it
happens
in
DNS,
off
or
somewhere
else,
I
think
it's
a
problem.
We
definitely
need
solve
and
thank
you
for
writing.
It
I.
D
W
Thank
you,
these
very
tall
people
in
the
room
front
so
that
Jim
read
a
couple
of
comments
and
I
think
the
question,
but
not
having
the
DNA
sort
working
to
do.
The
review
of
these
proposals
for
new
special
use
names
is
a
good
one,
but
I
do
think.
We
need
some
kind
of
review
process
to
be
part
of
this.
W
Yes,
we
put
it
politely,
maybe
something
that
an
expert
review
palette
could
be
convened
to
do
with
that
round.
Have
the
confront
the
whole
of
the
working
group,
but
I,
do
you
think
we
need
to
have
some
kind
of
broad
perspective
and
understanding
in
case
someone's
asking
for
a
special
label?
That's
already
been
used
or
know
something
already
similar
to
the
use
of
that
particular
new
label
elsewhere
in
the
DNS,
so
that
kind
of
visibility
would
be
useful
to
try
and
manage
some
of
those
elements.
W
Secondly,
I
do
think
the
point
is
to
think
more
about
the
liaison
with
ICANN,
and
one
thing
that
concerns
me
with
all
specialist
name
thing
is
the
potential
in
the
future.
If
I
can,
in
its
infinite
wisdom
because
to
create
new
TLDs,
is
that
we
have
people
doing
forum,
shopping
and
double
dipping
or
perhaps
some
accounts,
the
ITF
to
try
and
severe
an
application
for
a
new
deal.
W
W
W
C
X
X
On
the
mic
powered,
we
just
want
to
make
one
point
of
clarification,
and
the
recap
of
what
we
did
I
think
that
one
bullet
point
I
was
definitely
missing
is
that
we
froze
the
use
of
67
61
and
said
we're
not
considering
any
new
domain
names
and
that
actually
selectively
left
out
some
names.
So
so
it
actually
opened
us
up
to
really
selective
process
why
we
did
adopt
onion
and
it
didn't
adopt
some
other
ones,
and
so
in
that
light,
I
think
it's
really
important
to
say.
B
Y
That
mic
cause
young
wrote
off
as
the
person
who
started
the
whole
thing.
I
guess
I
wanted
to
briefly
share
my
experiences.
What
has
happened
now?
I,
don't
know
if
you've
been
at
the
DA
NRG
group,
given
that
the
group
decided
that
we
should
not
have
the
dot
new
TLD,
we
have
now
released
software
that
basically
allows
the
user
to
use
the
root
zone
and
overwrite
any
top-level
domain
as
they
choose
which
has
had.
Basically
the
answer
you
know
do
you
need
a
new
TLD?
Y
No,
we
could
have
just
used
a
collision
and
we've
done
usability
studies
and
the
result
has
been
spectacular.
Users
can
no
longer
tell
apart
if
they're,
using
DNS
or
gns,
so
the
migration
to
a
new
protocol
is
much
easier.
If
you
don't
use
a
new
TLD,
so
the
usability
has
been
greatly
improved
and
that
would
have
been
good
advice
to
have
been
gotten
early
on.
Thank
you.
H
Where's
her
Aquarius
I
I
want
a
second
Jim's
notion
that
figuring
out
how
to
have
this,
really
how
to
have
the
input
from
Mikey
and
as
critical
importance
and
challenging.
At
the
same
time.
Second
thing
to
the
chairs:
don't
let
this
drop?
Don't
let
you
know
that
we
we
paused
way
too
long
with
this
issue
and
as
hard
as
it
is,
and
as
much
people
need
to
do
expert
review
on
it
from
multiple
standards
organisations.
It's
critical.
We
solve
this.
O
You
know
confident,
I
think
there's
one
recommendation
missing,
which
is
very
important
and
which
would
call
people
to
till
the
right
actions
regarding
sixty
seven
sixty
one
sixty
one
sixty
seven,
whatever
I
even
forgot
the
name
number,
and
that
is
sixty
seven
sixty
one
does
make
the
name
special.
It
doesn't
allocate
you
the
name,
so
this
is
not
second
way
to
get
a
teal,
the
urine
Montiel
d
or
anything
prior
mistakes
of
application
of
their
RFC
non
withstanding.
O
Second
I
doubt
that
DNS
up
is
the
right
venue
for
this
I
don't
have
a
better
one
and
when
it
comes
to
liaising
with
ICANN,
the
previous
occasion
showed
that
both
organizations
were
happily
conspiring
together
to
avoid
the
problem.
Now,
the
next
one
around
is-
and
you
mentioned
on
the
slides
home,
Corp
and
Mail
and
I
could
imagine
interesting
fireworks
if
the
I,
if
I,
can
just
throw
this
over
the
fence
to
the
ITF
to
say.
Well,
we
have
a
draft
here
just
register
these
as
special.
O
J
Stefan
Watts
mayor
as
it
is
written
in
today's
draft.
It's
mostly
recommendation
for
ITF
developed
protocols
such
as
don't
try
to
reserve
a
TLD
that,
like
the
thing
which
was
done
with
that
one
at
the
beginning,
but
it
doesn't
solve
what
is
the
real
problem,
because,
besides
okay,
the
inside
the
IETF,
there
is
not
really
any
problem.
The
problem
comes
when
people
from
the
outside
wants
to
register
a
name
as
a
special
on.
There
is
no
proper
way
to
greet
them
and
to
direct
them
to
something
proper.
J
We
have
not
been
able
to
reserve
that
out,
for
instance,
for
them,
so
they
will
continue
to
reserve
TLD
because
it
so
I
seem
to
do
for
them,
and
then
we
will
still
have
the
problem
on
I
can
also
because
when
you
say
that
I
can't,
we
cannot
force
I
can
to
lock
TLD
to
be
them
even
tip
from
being
delegated.
We
cannot,
but
we
can
talk
to.
J
I
can
say
that
this
one
is
used
in
practice
on
I
can
can
do
it
by
itself,
because
I
can
decided
not
to
delegate
a
dot
on
that
cop,
the
smell,
because
our
actually
used.
So
input
from
the
IETF
could
be
just
one
more
input
for
the
ICANN
for
this
decision,
but
at
this
time
the
draft
for
me
is
not
really
interesting.
It
doesn't
serve
really
any
problem
because
it
gives
advice
for
people
who
already
know
about
it.
So
we'll
problem
is
how
to
greet
requests
from
outside.
B
Part
of
the
attempt
here
is
that
there's
sort
of
a
taxonomy
of
different
cases
where
there's
inside
the
ITF
and
outside
as
you're
saying
and
the
other
distinction
that
we
end
up
making
because
of
the
the
inter
organizational
implications,
is
single
label?
Name
I,
don't
even
like
the
term
TLD,
because
it's
it's
it's
you
know
in
its
oh,
it's
overloaded,
but
seeing
the
label
name
or
not
the
other,
but
the
other
dimension
is.
B
Okay,
so
the
question
I
think
will
have
to
go
the
chairs
to
discuss
how
to
forward
discussion
on
the
list.
Well,
we'll
put
on
the
spot
to
consider
what
we've
heard
here
also,
but
my
real
goal
was
just
to
get
review
for
the
document
and
get
people
who
are
not
too
traumatized
to
ever
think
about
this
subject
again,
to
help
us
do
something
constructive
here
within
the
cases
that
we
can
actually
deal
with
Thanks.
G
V
Z
Is
Alex:
this
is
an
idea
of
Alex's,
basically
slides.
So
it's
essentially
looking
again
at
the
problem
at
Deeb
and
was
trying
to
tackle
to
try
and
see,
is.
Is
there
a
small
bit
of
that
problem,
small,
a
bit
that
people
might
be
willing
to
kind
of
tackle
and
then
publish
records?
The
idea,
basically,
is
that
if
you
have
two
two
related
domains
that
one
of
them
can
can
declare
this
relationship,
basically
asserting
the
relationship
without
in
this
draft,
giving
any
kind
of
strong
semantics
about
that.
Z
Z
There
was
a
zero
zero
version
of
this
that
had
dkm
style,
use
of
txt
records
and
tecum
style
signatures
for
doing
some
authentication,
and
we
gots
a
bunch
of
comments
on
that
on
the
D
bound
list.
So
we
put
out
a
zero
one,
that
kind
of
flips
over
and
has
optional
signatures
that
are
DNS
X
file
and
a
new
or
Ora
type
which
I
may
have
messed
up,
because
it's
the
first
time
I've
written
a
draft
that
tries
to
find
a
new
Mora
type.
Z
AA
So
I
wanted
to
talk
a
little
bit
about
these
cases
in,
in
my
day,
job
I
spend
time
doing
anti
abuse
and
email.
So
in
in
some
of
those
analysis,
we
find
that
we
can't
always
determine
relationship
between
two
domains
that
appear
to
be
related,
and
then
sometimes
we
may
need
to
err
on
the
side
of
caution
and
that
doesn't
always
work
out
well
for
the
end
user.
So
it
would
be
beneficial
in
our
world
to
be
able
to
say
that
yes,
example.com
is
really
examples.
Mr
or
for
example,.
AA
The
marketing
department
may
use
an
outside
vendor
I
work
for
a
large
company,
sometimes
without
knowledge,
to
the
DNS
team,
the
mail
team,
whatever
else
they
go
outside
and
they
creates
you
know
whatever
they
feel
like
at
whatever
vendor
they
feel
like
and
you
have,
and
then
they
don't
understand
where
the
mail
doesn't
go
through
creating
new
domains.
For
example,
uber
calm
decides
they
would
like
to
launch
a
new
service
called
uber
eats.
They
might
want
to
determine
straight
a
relationship
companies
by
companies.
All
the
time
you
may
want
to.
AA
You
know
for
some
reason
or
another
show
that
sort
of
chain
of
authority-
I,
guess
something
more
for.
First,
even
I
think
use
internet
surveys,
your
research,
I
suppose
being
I.
Don't
wants
a
map
the
web.
It
sounds
kind
of
hard
when
I
say
like
they
have
but
yeah
and
then
something
like
was
sort
of
on
the
first
slide
example.
Dot
F
are
an
example
de
I.
AA
Don't
know
how
commenters
I
mean
we
I
am
living
the
States,
so
I
don't
know
how
common
it
is
for
a
large
brand
here
to
say
like
McDonald's
com,
McDonald's
ifr
McDonald's
about
de
and
how
can
I
actually
determine
their
relationships.
We
we
used
to
have
a
lot
of
not
a
lot
of
data,
but
there
was
data
in
who
is,
and
some
of
it
was
reliable.
AA
W
AA
So
there's
a
link
to
their
the
name
of
the
draft
and
we've
been
having
discussions
on
the
D
bound
list
only
because
that
seemed
more
appropriate
I
suppose
what.
AA
AB
AC
AC
Brian
Dixon,
one
of
the
things
that
I
think
is
a
concern,
is
the
difference
between
an
explicit
declaration
of
non
mapping
versus
an
implicit
lack
of
declaration
which
can
be
interpreted
either
way.
I
think
it
would
be
very
helpful
to
have
the
explicit
declaration
of
mapping
or
also
the
explicit
declaration
of
non
mapping
ie
somebody
can
put
a
defensive
record
that
says:
there's
no
other
related
zones,
Oh.
AD
Alex
mail
phone,
if
that
80
I'm
concerned
about
two
things
actually
for
one
you,
you
gave
a
very
great
definition
of
what
the
relation
the
semantics
of
the
relationship
is.
Besides
that
this
is
somehow
related.
So
I'm
I'm
wondering
how
how
can
I
semantics
of
the
protocol
be
here
when
not
even
the
relationship
definition
of
what
does
this
record
actually
mean?
AD
Is
here
so
quite
frankly,
that
would
render
it
completely
useless
and
the
other
point
is
there
like
a
couple
of
other
mechanisms
out
there,
I'm
thinking
about
HTML,
based
meta
tags,
related
pages,
and
something
like
that
redirect
whatever
so
I
wonder
whether
if
you
put
something
in
the
DNS
like
this,
does
it
apply
to
each
and
every
protocol
each
and
every
future
protocol?
It's
it's
very
opaque,
yeah
sure.
Z
I
mean
I,
think
it's
fair
comment
and
I
mean
there's
a
cesspit
of
semantics
that
you
could
get
into
and
we
try
and
we're
trying
to
hold
it
now.
Maybe
that
would
work.
Maybe
it
wouldn't
work.
That's
that's
a
good
question.
I
think
later
I
mean
right
now
we're
trying
to
avoid
that
issue.
Maybe
that's
feasible.
Maybe
it
isn't,
but.
B
W
To
Jim
needs
pepper
comments,
Stephen
and
there's
an
interesting
idea,
but
I'm
not
sure
the
DNS
is
a
police
for
representing
these
kind
of
semantic
relationships.
I
think
the
idea
be
able
to
say
these
things
are
kind
of
equivalent,
it's
potentially
useful
and
interesting,
but
as
Alex
was
suggesting,
it
perhaps
creates
other
potential
problems
further
down
the
line,
and
we
need
to
think
male
author,
but
more
about
that,
but
I'm
still
not
all
that
convinced
we
should
be
putting
that
kind
of
semantic
meaning
into
the
DNS.
The
DNS
is
really
essential.
W
M
M
Query
behavior
we're
not
talking
about
that,
because
we
find
a
PIR
that
when
you
try
and
cluster
domains
together
to
identify
when
you're
doing
business
intelligence
about
the
scope
of
registry,
for
example,
the
mechanisms
that
you
have
to
try
and
cluster
these
domains
together
are
horribly
messy,
but
to
do
with
Whois
data.
That's
vaguely
similar
or
words
that
are
common
or
this
specific
to
the
web
because
you
scrape
the
web,
but
you
find
out.
M
The
veil
thing
is
in
common
and
it's
incredibly
resource
intensive
to
try
and
do
an
inaccurate,
so
I
think
this
would
be
great
if
it
existed.
But
my
question
is:
what
incentive
does
it
the
main
name
holder
how
to
actually
publish
these
records?
If
there
was
something
like
deacon?
Where,
if
you
don't
publish
it,
you
don't
deliver
mail
to
google,
then
that's
a
good
incentive
right.
It's
like
reverse,
DNS
and
v6.
Nobody
would
do
it
at
all
if
it
wasn't
familiar
to
Google
and
places
like
Google,
but
there's
some
more
policies.
AA
Mean
I
sort
of
would
think
so.
I
mean
again
I
come
from
a
large
company,
so
we
do
have
our
marketing
departments
do
things
that
make
our
lives
very
difficult,
so
they
could
Ardi
nesting
could
go
back
and
say
we
we're
gonna
work
with
you
to
make
sure
this
is
correctly
attributed
to
our
company
and
then
we'll
work
with
you
at
some
point
later
to
make
that
really
work.
AA
The
way
it
should
I
mean
it
seems
like
it
would
be
something
for
their
operations
to
make
it
ease
their
lives,
but
I
mean
ultimately
it's
it's
from
my
also
from
the
anti-abuse
perspective
it
you
know
if
you
want
to
try
to
create
a
new
domain
name,
and
you
don't
have
the
time
to
say,
create
a
new
reputation
for
that
domain
in
terms
of
messaging
reputation.
You
know
you
can
say:
okay,
look.
This
is
linked
to
here.
AA
E
M
N
And
brief
answers,
please.
My
pal
said
this
actually
ties
back
a
little
bit
to
what
Joe
said,
but
I'm
having
a
hard
time
wrapping
my
head
around
the
use
cases.
You
mentioned
a
lot
of
them,
but
when
I
look
at
the
incentives
for
a
lot
of
those
use
cases,
they
all
seem
to
boil
back
to
anti
abuse
and
and
potential
and
and
boil
back
to
the
interpretation
by
anti
abuse,
researchers
and
that.
N
N
In
those
other
cases
and
when
I
look
at
the
anti
abuse
situation,
I
start
to
wonder
what
the
possible
interpretations
of
the
absence
of
the
records
could
mean
and
and
and
that
get
that
starts
to
feel
like
it
could
be
kind
of
messy
and
so
that
that
might
be
a
vote.
That
might
be
a
suggestion
towards
actually
making
it
a
little
more
semantically
meaningful,
rather
than
less.
N
AE
D
AE
John
reed
Akamai
quick
question
about
directionality
in
the
draft
I
know
you
say
it's
unidirectional.
Has
any
thought
been
given
to
recommendations
around
the
best
practices
to
which
direction
it
should
be?
Should
the
you
know,
email
marketing
provider
at
its
customers
the
other
way
around
either
way
those
lists
can
get
real
big,
real,
fast
and
I'm.
Just
wondering
what
you
know,
thought
has
been
given
to
that,
and
also
how
sorry,
once
you
set
up
the
directionality,
how
do
you
make
sure
it's
gone
on
both
ends
when
the
relationships
over
I
mean.
AA
Yeah
I
mean,
from
my
perspective,
it
seems
like
the
sort
of
the
largest
or
most
well
known
domain
wins,
but
maybe
that's
not
really
how
it
works,
so
I
mean
maybe
is
if
I
don't
know
if
there's
an
alphabet
compa
that
seems
less
well
known
than
google.com
sure
so,
but
you
we
think.
Ultimately,
if
alphabet
com
is
actually
the
real
parent
of
Google
that
that's
where
it
should
kind
of
feed
up
through,
but
I
know
it's
really
the
relationship
that
you
want
to
declare
I.
Suppose
right.
AB
Please,
on
the
mailing,
this
is
a
Marie
from
our
co-chaired,
eBay
and
I'm
totally
fine
with
you
using
my
mailing
list,
because
we
narrowed
it
in
a
useful
with
it
anyway.
So
again
the
T
sort
of
took
half
my
point.
You
should
probably
say
something
about
what
happens
when
you
find
a
unidirectional
assertion,
because
that
may
be
meaningless.
It
might
even
be
a
threat
like
I'm,
claiming
an
association
with
your
domain
to
try
to
gain
some
benefit.
AF
What
I
heard
Sam
Wyler,
what
I
heard
you
say
as
you
went
through
the
use
cases
was
this
is
a
way
for,
but
what,
if
I,
want
to
know
if
these
two
domains
are
related,
I,
think
the
real
question
comes
when
what
does
a
piece
of
code
do
when
it
seats?
One
of
these
I
think
that's
why
your
use
cases
are
not
fleshed
out
enough
part.
AF
Two,
someone
at
the
mic
said
that
they
weren't
sure
if
DNS
was
the
right
place
for
this
I
will
draw
everyone's
attention
to
a
proposal
from
my
quest
called
first
party
sets
that
involves
JSON
objects
served
over
HTTP
I,
don't
know
if
that's
the
right
way
either,
but
it
is
a
different
way
and
may
have
a
differently
scoped
set
of
use
cases
than
what
you're
looking
at
part
3.
This
signing
with
straight
authenticate
keys
thing
is
crazy.
V
Thank
you,
so
Warren
Kumari
Google
I'll,
try
and
keep
it
really
short,
so
I'm
not
entirely
sure
that
there
should
be
in
the
DNS.
But
if
it
is,
I
would
like
to
build
a
habits
that
I
can
say.
Google
comm
is
the
same
as
google.de
not
at
lookup
time,
but
so
that
people
who
are
doing
abuse
stuff
can
have
a
look
and
draw
some
correlation.
V
AG
Jane
you're
employed
by
the
internet
society,
but
not
speaking
for
them,
so
first
I
want
to
say
thanks
for
bringing
this
draft
here,
I
think
it's
good
to
have
you.
We've
often
talked
about
wanting
to
have
people
bring
an
operational,
you
know
usage
of
DNS
and
where
you're
seeing
issues
with
it
bringing
here.
So.
Thank
you
for
writing
this
from
bringing
here.
I
guess.
I
would
just
have
two
comments.
AG
I
think
I'm
a
little
concerned
with
the
trust
by
the
way
I'm
from
one
of
those
communications
departments
that
does
that
kind
of
stuff,
and
you
know
this
would
be
kind
of
cool.
We
could
use
this
in
a
couple
places,
but
one
question
is
what
prevents
some
less
ethical
marketing
folks
or
somebody
from
claiming
that
they're
really
associated
with
another
domain?
AG
AB
Yes,
Murray
again,
also
not
employed
by
our
paid
by
I
sock
I
think
this
possibly
has
applications
in
the
Demark
space
as
well,
because
we
tried
to
we
wanted
to
capitalize
on
D
bound
and
it
didn't
work,
so
it's
possible
that
this
could
be
an
add-on
to
that
somehow
so,
there's
maybe
a
possible
use
case.
Okay,
thank.
D
AH
D
L
D
Historical,
so
we
had
a
discussion
on
a
name
in
Bangkok
Tim
prepared.
Well,
the
problem
space
is
well
known.
I
think
we
don't
have
to
go
too
into
this.
Also,
given
time
there
was
the
C
name,
a
name
discussion,
HTTP
I,
just
felt
it
was
kind
of
all
the
different
repels
of
Health
themselves
or
together
we're
in
the
deadlock.
So
we
want
to
separate
this
discussion,
so
we
can
have
the
HTTP
discussion.
We
can
have
the
C
name
discussion
if
we
still
want
to
pursue,
but
don't
let
us
start
with
a
name
discussion.
D
Actually,
that's
why
we're
here
now.
I
also
want
to
point
that
out.
Sorry
I
want
to
point
out
draft
written
by
Denton
York
about
all
the
users
or
the
web.
Commercial
perspective
have
a
read
of
it
and
actually,
given
time,
I
want
to
give
the
floor
to
UX
new
yeah,
but
I
see.
The
title
gives
well
speak
for
yourself
actually
about
the
day
named
draft
status
and.
AJ
Okay,
so
I
think
I'm
I'm
here,
because
I
made
some
confusion
on
the
mic
on
Tuesday,
there
I
said
that
it
might
be
a
good
idea
to
have
a
separate
direction
with
aiming
to
have
a
different
scope.
Smaller
scope,
so
can
make
more
progress
that
caused
some
reaction
on
them
mailing
lists,
so
I
thought.
Maybe
it
would
be
good
idea
to
get
this
to
the
working
group.
AJ
AJ
People
came
along
to
that
lots
of
discussion
made
a
very
complex
solution
in
the
or
one
version,
and
then
we
thought,
if
we're
on
a
bad
bad
bad
here.
So
there
was
a
complete
rewrite.
That's
the
OH
version
that
Tony
finished
it
to
me.
That
is
very
nice
document.
All
the
complexity
has
gone
away.
It
doesn't
rely
on
resolve,
equate
and
got
a
lot
of
feedback
on
the
mailing
list
after
everyone
a
little
bit
silent.
AJ
So
how
do
we
proceed
with
a
name
is
basically
the
same
and
when
on
the
list
and
looked
at
the
discussion
and
got
a
little
bit
of
requirements
out
of
that,
so
the
Ingham
stuff
shoot
free
support
on
a
flying.
Demon
sack
does
not
require
service
changes
except
further,
like
the
are
type
miss
work
with
resolvers
that
don't
do
any
name
like
but
never
implemented.
AJ
AJ
One
is
iterate
on
the
current
draft
and
please
make
sure
that
the
discussions
focus
on
what's
in
there
and
and
notice
that
it
actually
has
two
requirements,
several
justices
or
we
can
reduce
the
scope
and
just
just
get
rid
of
all
the
resolves
of
processing
and
secondary
server
processing,
with
the
idea
that
we
can
come
to
reached
to
an
document
faster
like
this
less
contentious,
stuff
test,
we
do
scope
or
we
can
iterate
on
the
current
draft
I'm.
Finally,
both
I
would
like
to
hear
what
the
working
group
thinks
about
that.
AC
Brian
Dixon
Go,
Daddy
I've,
piloted
extensively
on
the
lists,
and
one
of
the
main
issues
with
any
of
the
current
drafts
are
the
requirements
for
authority
servers
to
act
in
a
way
that
previously
only
recursive
x'
needed
to
which
is
fetching
and
storing
and
updating
the
targets
of
painting,
and
that
does
not
scale
for
authority
servers,
especially
large
ones.
So
I
don't
speak
for
my
employer
GoDaddy,
but
it's
a
major
concern
that
we
clearly
have
an
interest
in
not
having
problems
that
don't
scale.
It's
it's.
AC
Basically,
it's
an
existential
threat,
so
it
hasn't
been
addressed
adequately
by
the
the
draft
and
I.
Don't
think
it
can
be
due
to
the
requirement
for
the
fetching
and
updating
of
Records
other
than
the
specific
local
ones,
so
I
think
I
think
you
need
to
be
addressed
in
a
different
way
in
a
different
place.
But
that's
that's
my
analysis
and
observation
and
I
think
it
needs
to
be
strongly
considered
and
when.
AC
In
the
authority,
servers
there's
a
whole
bunch
of
different
aspects
of
this,
one
of
which
is,
it
interferes
with
geoip,
because
for
at
least
our
implementations,
the
authority
servers
for
a
given
zone
are
centralized
and
pushed
out
to
anycast
locations.
They're,
not
differentiated,
so
querying
an
authority
server.
AC
AC
It
work
the
second
aspect
of
that
is
scale
recursive
scale
by
query
authorities
scale
by
the
number
of
zones.
So
if
you
look
at
the
longtail,
the
issue
is
you're
now
placing
recursive
level
transaction
requirements
on
that
changes,
the
business
model-
and
it
does
so
in
a
very
negative
way,
because
typically
the
long
tail
of
zones
don't
see
query
load,
there's
no
way
to
recoup
the
costs
of
doing
what
aining
requires.
So.
AJ
To
your
last
comment,
I
think
he
need.
It
would
be
nice
that
the
document
or
as
a
successful
document
would
at
least
have
to
resolve
our
a
name
processing
to
improve
and
make
the
a
name
resolution
better
for
the
client
to
your
first
point:
a
geo
RP.
Yes,
that's
a
different
thing.
If
you're
going
to
do
tailored
responses,
then
the
document
doesn't
work,
but
that's
the
same
with
like
Dean
a
sec
you're
with
your
PL,
so
they're
not
doing
offline
signing.
You
are
required
to
do
online,
something
because
you're
doing
tailored
responses.
AJ
It
sends
true
for
any
resolution.
So
if
you
want
to
do
aiming
and
0
IP
you're
have
to
implement
it
sort
of
in
your
secondary
server,
and
that
will
scale
actually
and
the
draft
doesn't
prevent
you
from
doing
that
either.
You
just
have
a
bend
a
little
bit.
The
rules,
like
those
providers
do
and
I
would
have
to.
AC
AK
N
So
I'm
sort
of
gonna
repeat
that
anecdotal
evidence
that
it
that
this
sort
of
thing
does
work,
I,
implemented
or
was
involved
in
implementing
this
with,
for
a
large
genus
operator,
with
3.7
million
zones
we
ended
up,
we
ended
up
having
to
do
ramp
up
and
back
off
algorithms
such
that
the
more
often
we
witnessed
a
target
change,
the
more
often
we
queried
it
to
see
if
it
had
changed
in
order
for
the
ones
that
were
very
stable
to.
We
could
essentially
ignore
them
that
helped
it
work
really
well,
but
yeah
it
works.
N
L
You
want
in
your
particular
implementation
and
I
think
that
this
would
go
a
long
way
because
it
would
allow
people
who
use
this
already
in
existing
deployments,
like
Dyna
and
whatever,
to
have
more
than
one
provider,
because
once
we
have
this
on
transfer
specified,
you
can
just
move
or
use
two
providers
and
so
on,
and
then,
if
this
actually
works
and
gets
implemented
by
these
big
guys
who
offer
this
service
now,
we
can
go
and
work
on.
The
second
document,
which
could
say:
okay,
if
I'm
Venus
software
developer
house
in
Poland,
is
in
my
coat.
AL
Only
one
high
up
I
didn't
buy
that
it
will
procure
nearness,
because
we
just
finished
a
name
JD
in
this-
a
name
that,
with
our
provider
that
actually
also
resolves
propagates
a
DNS
or
multiple,
a
name
recurs,
and
we
are
very
funny
last
night
and
it's
works.
Just
fine
I'd
really
need
my.
It
would
somehow
break
it.
AC
D
AH
AJ
AJ
AH
Think
we
should
iterate
it
and
I
give
this
scale
everybody.
Does
it
now
right,
all
the
vendors?
Do
it
everybody?
Does
it
so
yeah
I,
don't
see
that
as
a
problem,
even
so.
AG
Let
me
just
real
a
comment
on
that:
Tony
Finch
who's
been
involved
with
this
asked
I'd
like
more
descriptions
on
the
list
from
vendors
on
how
they
do
a
name
so
to
the
comment
that
people
are
saying
they
they
already
do
this
and
scale.
This
I
think
Tony's
sort
of
saying
why
and
not
realizing
the
time
send
to
lists,
and
likewise
for
people
who
would
say
we're
in
here
saying
the
scales
and
stuff
would
they
support.
This
would
be
useful.
Okay
to
ocinski.
AH
Tony.
Thank
you.
Of
course.
Then
you
follow.
This
I've
talked
with
the
vendors
about
this.
They
owe
each
vendor
feels
their
secret.
Sauce
has
tastier
than
the
other
vendors
secret
sauce
and
they
don't
like
to
share,
but
if
we
can
find
some
of
that,
that
would
be
great,
but
that's
my
experience
talking
it
with
them
under
NDA,
not
actually
getting
solid
answers,
so
you
know
vendor
a
see.
It's
much
tastier
the
vendor
be
sort
of
thing
so,
but
a
useful
idea
of
Tony.
Thank
you.
The
search
for
common
ground
continues.