►
From YouTube: IETF101-DNSOP-20180322-1810
Description
DNSOP meeting session at IETF101
2018/03/22 1810
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
Gang
it's
about
time
to
get
started
and
I'll
be
nice
and
give
you
a
two-minute
warning.
But
if
you
want
to
be
in
DNS
op
you're
in
the
right
place
and
please
sit
down
and
we
hope
prepare
to
be
entertained.
If
you
don't
want
to
be
in
DNS,
op
you're
welcome
to
stay,
but
you
might
want
to
be
somewhere
else.
B
Okay,
gang
welcome
to
session
two
of
danezaa
ITF
101,
I'm
suzanne
wolf.
You
may
have
noticed
that
my
co-chair
tim
was
in
skis
not
with
us.
If
you
saw
the
mail
to
the
list
this
morning,
tim
is
not
well
and
being
taken
care
of,
but
as
far
as
I
know,
he
will
be
fine
thanks
to
him
for
all
the
prep
work.
B
He
did
I
want
o'clock
in
the
morning
before
he
left
her
medical
treatment
and
bless
his
wife
for
making
sure
he
did,
but
I
also
want
to
introduce
the
lovely
and
talented
Brian
here
Berman,
who
agreed
to
step
in
and
help
out
with
the
logistics
of
running
the
meeting
as
usual,
any
errors
or
omissions
are
mine.
After
all,
as
you've
always
suspected
is
much
smarter
and
more
organized
than
I
am
so
any
issues
are
entirely
my
fault
yeah.
Well,
Tim
we
miss
you.
B
B
You
be
the
judge.
Also.
We
like
it
a
lot
when
first-time
attendees
bring
work
to
our
meeting
so
be
kind
and
be
polite.
Please
we
look
for
things
that
are
of
interest
to
us
and
it'll.
Probably
it
would
seem
likely
to
be
of
interest
to
the
group.
Discussion
on
the
mailing
list
is
definitely
a
plus
but
not
necessary.
B
It
was
Tim's
idea
to
name
the
camel,
though,
for
all
of
this
work
and
here
and
on
the
mailing
list.
We're
interested
in
is
this
work.
That's
that's
people
feel
is
worth
doing,
but
also
is
it
worth
it?
Do
we
want
to
adopt
it
as
a
working
group
item
which
to
us
is
a
commitment
to
Shepherd
it
through
the
process
and
eventually
in
RFC?
B
C
Okay,
it's
plenty
I'll,
be
very
quick,
then,
if
you
put
a
load,
balancer
or
ETA
TLS
on
wrapper
in
Ron
in
front
of
another
server
that
server
for
losers,
information
about
the
clients
like
the
IP,
the
protocol
used,
etc.
This
proves
to
be
a
problem
in
many
situations,
including
when
that
reason
over
does
dns64.
For
example,
I
understand
this
specific
problem
has
occurred
at
a
previous
IDF.
C
C
The
the
first
version
led
to
some
privacy
concerns
on
DNS
op
and
at
IDF.
We
feel
we
have
addressed
those
by
specifying
that
if
you
see
in
xpf
that
you
did
not
expect
you
need
to
return
refused.
This
means
that
if
you
accidentally
leak
metadata
through
xbf,
you
will
not
get
DNS
service
and
we
feel
that
this
addresses
the
privacy
problems.
C
D
E
Hi
I'm
Andrew,
Sullivan,
I
I
read
this
and
it
is
a
good
document
and
I
applaud
the
document.
A
good
document
of
a
of
a
of
a
straw
for
the
camel's
back
idea
is
still
is
still.
You
know
like
not
a
great
idea
and
III
just
like
this
seems
almost
designed
to
be
the
canonical
example
of
the
sort
of
thing
we
were
talking
about
the
other
day
and
that
that
troubles
me
a
little
bit.
That
doesn't
mean
I
I'm,
completely
opposed
to
it
I.
Just
it
makes
me
a
little.
F
C
If,
in
a
specific
case
of
a
saline
debt
DNS
this
forwarding
to
a
specific
backends
that
does
not
honor
the
you
must
and
refused
rule,
then
yes,
you
will
be
slurping
up
all
the
data,
but
in
any
situation
where
say
a
home
router
gets
some
xpf
code
for
some
weird
reason
and
it
sends
queries
to
different
machines
on
the
internets.
They
should
quickly
learn
that
they
are
misconfigured
right,
but
I
think.
C
H
H
This
is
something
that
only
is
only
intended
and
designed
to
be
added
by
son
by
load
balancer,
for
example,
DNS
dist
talkin
to
a
back-end
server
cluster
and
where
they're
in
the
same
admin
domain,
so
a
bad
active
server
receiving
DNS
you
got
basically
got
to
you've,
got
to
be
cooperating.
Adults
for
this
not
be
used.
I
Year,
the
other
another
individual
draft,
quite
similar
to
this
called
in
DNS
current
adoption
and
I've
read
both
and
I
know
these
are
different.
But
on
the
other
hand,
I
saw
quite
a
lot
of
similarity.
The
like
the
information
conveyed
in
this
and
also
privacy
concerns.
So
maybe
we
might
think
about
the
how
I
don't
know
if
it's
reasonable
to
unify
them,
but
give
some
thought
to
at.
C
K
K
C
H
Next,
anyway,
this
is
not
something
that
would
normally
end
up
being
misconfigured.
It
would
have
to
be
miss,
implemented,
yeah,
a
router
yeah,
please
be
leaking
information,
you
wouldn't
be
miss
configure
your
router.
Your
rights
would
have
to
intentionally
include
code.
That
is
not
and
logic.
This
is
not
intended
for
that
part
than
outcome
to
infrastructure.
I.
G
B
H
Right
so
yes,
so
Patriots
presents
a
drop
of
my
name
on
it.
I'm
not
presented
a
draft
with
ma-kun's
name
on
it.
Just
to
confuse
you
all.
So
catalogs
owns
who's
familiar
with
this
scene
earlier
versions:
okay,
good!
So
not
really
gonna.
Do
the
elevator
pitch
that's
useful,
who
seen
the
latest
version
of
it?
H
Oh
fall
on
deadline
day,
March,
5th,
I,
think
that
was
from
memory,
so
we
have
actually
reorganized
the
draft,
but
I
was
I
was
brought
in
to
do
the
last
review
of
this
one
and
looked
at
it
and
realized
that
had
quite
a
bit
of
a
mishmash
of,
for
example,
things
like
an
unlit
Ike,
which
was
an
unordered
list
of
domain
names.
We
had
other
things
where
lists
of
prefixes
were
input
within
site.
H
One
are
are
a
lot
of
the
restructure
and
then
goes
around
getting
rid
of
that
mix-up
and
having
a
clean
separation
between
multi-value
types
and
single
value.
Types
we'd
also
have
some
objections
to
these
of
crypto
hashing
as
the
way
to
generate
a
unique
prefix
for
some
labels
is
required
in
some
places
and
although
the
bi9
implementations
still
prefers
to
use
crypto
digests,
it's
no
longer
my
mandatory.
It's
simply
a
recommendation
because
of
these
changes,
we've
now
changed
the
protocol
version
string
in
this
version
too,
and
also
such
more
relies
on
Latin
a
moment.
H
So
yes
go
back
to
multi-value
properties
yeah.
There
are
various
configuration
strings,
for
example,
good.
A
good
example
list
of
note,
5
little
masters,
for
example,
where
you
need
multiple
values
and
earlier
versions.
Sometimes
these
would
have
actually
just
been
individual.
Are
ours?
A
single
our
asset?
We've
now
changed
that
so
that
you've
always
got
to
have
a
prefix
in
front
of
each
unique
entry
in
the
list.
H
The
APL
record
we
previously
were
using
for
prefix
lists
now
has
to
follow
these
same
rules,
so
we're
saying
that
any
PR
record
can
only
have
one
prefix
and
if
you
need
more
prefixes,
then
you
have
to
use
the
multivalued
property
syntax,
and
here
we
have
an
example
of
that.
So
each
member
zone
has
its
own
unique
prefix
within
the
members
within
the
catalog
zone.
H
The
m
unique
and
here's
an
example
where
we
would
have
two
separate
values
for
this
property
example
prop
and
they
shall
have
their
own
unique,
ID
and
associated
with
the
value
so
we're
well
the
implementation.
This
change
doesn't
actually
reflect
the
current
buying
implementation,
which
was
the
previous
version.
H
H
By
911
on
9/12
route,
there
with
version
1,
which
was
what
was
in
the
earlier
versions
of
the
draft
more
or
less,
but
we
have
got
an
internal
commitment
to
deploy
this
newer
version,
which
we
think
is
in
totally
much
cleaner
and
simpler
to
implement.
I
can't
promise
it
will
be
913
or
even
914.
So
we've
got
a
new
release
schedule
for
bind
releases
now,
and
there
is
also
a
plug-in
that
Peter
has
done
of
power
DNS,
currently
only
own
version,
one
I
imagine
but
would
I'm
sure
be
very
easy
operator
to
support
version.
H
One
of
the
problems
we've
had
Pearlie
in
this
working
group,
we've
had
probably
no
sex
before
this
working
group
was
trying
to
find
a
common
dictionary
for
name
server
configuration
items.
What
bind
calls
a
certain
configuration
item
might
be
called
something
different
in
other
servers
or
may,
even
indeed,
even
if
it's
conceptually
the
same
configuration
item
might
have
different
rules
on,
for
example,
bind
ACLs
can
include
named
lists
of
prefixes
of
the
name
server
implementations
might
not
so
that
learn
leads
on
to
the
next
issue.
H
You
may
end
up
with
multiple
entries,
all
meaning
the
same
thing,
but
we
think
is
probably
only
clean
way
to
make
different
themselves
interoperate
without
and
have
some
massively
complicated
translation
dictionary
from
some
hypothetical
and
in
practice
impossible.
The
common
data
dictionary
in
whose
name
serve
configurations,
don't
know
yet
whether
this
is
gonna
go
in
the
draft
or
not,
but
there's
email
a
sense.
H
The
list
on
3rd
March
talking
about
how
we
might
do
templates
so
that
you
could
say
the
other
citizens
will
all
take
configuration
from
this
domain
name
over
here
and
some
other
domains
might
take
it
from
there.
Rather
Nate
each
individual
domain
and
a
half
log
having
to
have
its
own
complete
set
of
properties
specified
all
over
and
over
over
again,
there
are
some
minor
gotchas
on
that
because
of
the
way
the
D
name
works.
L
H
It's
mostly
the
recognition
that
I
think
there
are
some
design
flaws
in
version
one.
It
is
out
there
already
yeah.
It
wasn't
quite
right.
We
want
to
get
it
better,
but
we
also
don't
see
it.
There's
necessarily
much
point
in
continuing
to
document
version,
one
when
we
know
that
we're
going
to
go
ahead
with
the
new
version
and
whether
we
fit
templates
it
in
the
subversion
or
Nasus
to
be
deferred,
determined.
M
With
each
box
is
it
Nick
I
will
be
the
first
to
invoke
the
KML
in
decision
and
I
have
a
feeling
that
this
just
is
stretching
DNS
protocol
too
far.
I
understand
that
having
everything
invent
this
looks
nice,
but
it
means
that
you
have
to
implement.
Everything
comes
as
right,
so
I
think
that
there
is
sufficient
number
of
configuration
systems
out
there,
including
some
specifications
which
we
are
done
by
ITF
and
are
widely
used
in
different
working
groups.
H
Don't
see
those
configurations
being
used
for
names
of
configuration,
I,
don't
think
they
actually
do
exist
as
respects
the
camel
comment.
This
is
not
a
protocol
change.
This
is
a
provisioning
system.
It
it
happens
to
use
DNS
zone
data
much
like
RPC
does,
but
it
isn't
a
change
to
any
protocol.
Yes,.
M
N
O
I'll
find
another
left.
This
is
interesting,
so
I'm
interested
sorry
now,
but
I
was
also
following
the
discussion
on
the
mailing
list.
I
think
it's
important
to
at
least
to
consider
also
well
teams
rephrased
the
comments
of
his
colleague
about
operators
needs
and
it
doesn't,
but
the
current
catalog
sounds
didn't
fit
his
operational
requirements.
Order.
J
O
Ok,
but
indeed
so
considering
the
draft
I
have
some
comments
and
but
it's
not
important
to
hear
I
think
it's
important
to
have
operation
operational
people
also
looking
at
the
document
and
if
it
feels
their
needs
and
just
I
agree
with
you
better.
We
shouldn't
overstretch
that
protocol,
but
there
might
be
use
cases
where
there's
just
immutable
well
containers
whatever,
and
you
want
to
spin
up
some
service
and
can
we
either
address
it
with
catalog,
sounds
or
other
order,
otherwise
so
I'm
just
very
open
positive.
O
H
F
Tony
Finch
I'm,
using
it
in
catalog
zones
on
my
experiments
with
DNS
server
I've
advertised.
This
is
a
facility
to
my
users,
because
we
have
quite
a
lot
of
stealth
secondary
scattered
around
the
university.
You
have
copies
of
all
of
our
internal
zones
and
certainly
for
for
the
purposes
of
configuring
that
kind
of
server
the
catalogs
zones
make
it
much
simpler
and
much
more
easily
maintainable.
F
For
our
public,
authoritative
servers.
It
is
a
bit
more
of
a
difficult
fit
because
the
problem
I
would
like
or
the
the
thing
I
would
like
to
be
easier-
is
to
route
to
receive
a
list
of
zones
from
other
sites
that
I
act
as
a
secondary
for
and
have
that
sort
of
nicely
contained
within
a
little
secure
bubble,
so
that
I,
so
that
they
can't
mess
up
the
rest
of
the
configuration
of
my
DNS
server
so
that
I
don't
have
to
manually
maintain
the
list
of
the
zones
that
I
secondary.
Ok,.
H
F
H
I
mean
one
of
the
concerns
for
me
and
going
back
to
this
title,
be
quick
about
the
D
name.
Stuff
is
not
less
imperfection
in
any
the
enemy
of
the
good.
Oh
yeah,
some
of
the
responses
we
had
the
D
name
proposal.
Well,
yes,
wouldn't
it
be
nice
if
we
could
have
nested
templates
well,
yes,
I'm
sure
it
would
be
very,
very
nice,
but
it
that
would
be
adding
quite
significant
complication
to
the
deployment
and
the
D
name.
H
P
Q
Q
At
the
same
time,
it
doesn't
help
administrators
that
have
lots
and
lots
of
zones
there's
other
problems
associated
with
that
and
I
was
trying
to
think
of
ways
to
hack
into
it,
but
it
would
increase
the
complexity
of
this
quite
a
bit
and
at
the
same
time,
if
you
want
to
do
server
configuration
outside
of
just
zones,
you
have
to
do
all
this
vendor
specific
stuff.
I.
Think
if
you
were
gonna
design
a
protocol
to
do
this
today,
of
course,
you
wouldn't
put
it
in
the
DNS.
Q
C
For
like
power
Dennis,
as
Ray
said,
we
have
an
implementation.
This
implementation
lives
outside
of
power.
Deenis,
not
a
line
of
code.
Empowered
eNOS
was
changed.
There
is
no
weird
potential
for
interaction
with
other
features.
The
complexity
envelope
has
not
been
pushed
this.
In
response
to
better
saying
this
is
a
straw
of
course.
It's
a
straw
but
I
think
it's
a
straw
on
a
different
camel.
N
N
Reconfiguring
zones
and
things
it
was
a
really
nice
interface
with
transaction.
All
you
roll
it
back
and
you
commit
it.
I
think
doesn't
do
everything
that
you're
draft
talks
about
it.
I
think
it
would
be
a
really
good
starting
point,
so
maybe
merge
the
two
ideas
together:
well,
not
take
thinking
from
what
they've
done.
Yeah
yeah.
D
P
Support
of
Ben,
oh,
we
do
plan
to
use
some
immutable
servers
that
nominate
and
as
such,
this
is
interesting
to
us,
but
we
also
will
consider
using
other
systems
out
of
dns
such
as
ansible,
and
that
was
just
comment
there.
Both
options
are
currently
being
considered
and
as
such,
I
will
be
following
the
draft
carefully.
P
H
B
B
J
B
D
B
B
R
B
No
I
wasn't
going
to
ask
for
a
hum
on
the
first
draft,
because
I
only
heard
negative
commentary
in
the
room,
but
in
any
case
what
happens
in
the
room
is
not
normative.
What
happens
on
the
mailing
list
is
normative,
so
please,
your
views
on
all
of
the
drafts
will
be
fairly
considered
and
thank
you
for
your
comment.
It's
helpful
to
keep
me
answer.
You
keep
me
on
track.
B
J
S
Hi
folks
so
I'm
here
to
talk
about
a
new
draft
that
we've
written
on
multi
provider,
DNS
SEC.
So
after
a
two-day
Tuesday's
very
entertaining
session,
I
kind
of
felt
obligated
to
provide
a
little
bit
of
a
disclaimer
I,
don't
know
if
Burt
Huber
is
in
the
room.
Is
he
okay?
He
went
home.
Okay
go
right!
Well,
he
can
relax
and
take
a
deep
breath,
because
what
we're
doing
here
was
is
we're
not
actually
proposing
any
new
DNS
protocol
enhancements
at
all.
S
What
we're
simply
doing
is
providing
some
new
operational
deployment
models,
so
I
think
the
camel
will
approve
and
and
agree
that
we're
not
trying
to
torture
it
too
much
or
cause
it
to
do
too
many
additional
contortions.
So,
let's
see
how
this
goes
so
the
problem
statement-
and
it's
not
really
a
problem,
but
rather
a
scenario
we're
trying
to
accommodate,
and
that
is
that
many
enterprises,
these
days
use
the
services
of
multiple
DNS
managed
DNS
providers
to
operate
their
authoritative
DNS
service
and
we
want
to
be
able
to
successfully
deployed
DNS
SEC
in
such
environments.
S
Now
this
could
be
fairly
straightforward
or
depending
on
the
kinds
of
features
that
you
use
and
in
the
DNS
they
could
actually
pose
a
little
bit
of
a
challenge
and
I'll
go
into
that
a
little
bit
later.
So
we
present
for
deployment
models
in
the
draft,
so
the
first
two
are
the
really
important
ones
serve.
S
Only
and
sign
is
served
the
last
two
I'm
not
really
going
to
discuss
here,
they're
kind
of
variations
and
combinations
of
the
first
two
and
they're
kind
of
because
they
inherit
the
weaknesses
of
both
they're
kind
of
the
worst
of
both
worlds
too.
So
they're
not
ideal,
so
the
serve
only
model.
This
is
probably
the
most
straightforward
one
to
describe
and
that's
where
the
zone
owner
runs
their
own
master
server,
signs
the
data
and
pushes
out
the
zone
to
multiple
DNS
providers
using
traditional
DNS
zone
transfer
mechanisms.
S
Notable
limitation,
which
is
that,
if
you
use
certain
types
of
non
standard
as
DNS
features,
then
it
doesn't
work.
Okay,
so
I'm
going
to
describe
what
those
features
are
now,
generally
speaking,
they
have
many
names,
but
a
lot
of
the
DNS
providers
and,
in
my
experience,
lumped
them
under
this
general
term.
Traffic
management,
which
includes
things
like
global
server,
load,
balancing
probing
and
failover
records
and
more
complicated
things
like
that,
and
these
type
of
responses
are
often
dependent
on
some
characteristic
of
the
querier
or
dependent
on
examining
the
dynamic
state
of
the
network.
S
Before
determining
what
response
should
be
returned,
so,
ideally,
they
are
best
determined
at
the
authoritative
server
itself
or
at
query
time
or
at
or
some
combination
of
both
I.
Think
folks,
in
this
room
are
probably
very
familiar
that
Paul
vixie
famously
had
a
term
for
these
things
about
a
decade
ago.
Anyone
stupid
DNS
tricks,
yes
exactly
right
so,
but
we
have
to,
and
he
made
some
very
cogent
arguments
and
which
almost
all
of
them
I
agree
with,
but
the
reality
is
in
today's
world
Z's.
S
These
are
so
pervasively
deployed
that
we
just
have
to
deal
with
them
and
DNS
SEC
has
to
has
to
follow
suit.
So
that's
why
we
are
interested
in
the
next
model
which
we're
calling
sign
and
serve
where
the
zone
owner
typically
uses
provider
specific
api's,
to
update
the
zone
to
the
providers,
the
providers
sign
and
serve
the
data
to
the
rest
of
the
world.
S
What
did
I
do
here?
Oh
these.
This
model
can
support
a
DNS
SEC
for
those
non-standard
as
features
if
the
provider
in
question
has
the
ability
to
sign
those
dynamically
generated
responses
and
I
want
to
mention
that
not
all
of
them
do
some
of
them
do
some
of
them.
Don't
so
that's
still
a
kind
of
a
failing
in
the
in
the
DNS
industry
today,
but
for
the
ones
that
can
sign
them.
The
common
strategies
are
are
doing
on-the-fly
signing
it's
probably
the
easiest
way
to
do
it,
and
the
other
way
is.
S
If
you
can
enumerate
all
the
answers
in
advance,
you
can
pre-compute.
Those
answer
sets
pre
sign
them
and
then
algorithmically
determine
at
query
time
which
one
to
respond.
I
went
with
which
response
and
signature
to
return
that
actually
works,
and
there
are
some
companies
that
actually
do
that
too.
J
S
You
read
through
I'm,
not
going
to
explain
it
now,
it's
a
little
bit
subtle
how
it
works.
But
if
you
read
the
draft,
it
should
become
clear
how
that
works.
Let's
go
a
little
bit
quickly.
I
described
two
models,
and
these
are
not
random
models
that
we
picked
out
of
our
head.
We've
actually
sat
down
and
talked
with
actual
managed
DNS
providers
to
see
if
these
seemed
operationally
viable
and
they
and
they
do
so.
S
Alright,
so
there
are
some
subtleties
and
how
this
all
works.
You
saw
some
of
the
chatter
on
the
mailing
list
and
some
people
had
to
read
the
document
twice
to
do
it,
but
there's
a
section
that
I
added
on
validating
resolver
behavior.
If
you
look
through
that
hope,
you'll
all
become
clear
and
that's
about
it.
I
know
the
chairs
are
probably
gonna.
Ask
some
questions.
S
Are
I'm
gonna
preemptively,
just
say
what
questions
I
wanted
to
ask
the
audience
is:
first,
is
this
a
useful
document
for
the
DNS
operations
working
group
two
will
be
working
on
if
we
ask
for
adoption
what
category
of
adoption
should
we
ask
for
I,
currently
I
just
put
it
out
there
with
a
very
low
bar
informational,
but
maybe
an
argument
can
be
made
that
there
should
be
a
PCP
if
we
can
all
agree
on
the
models.
Are
there
additional
models
that
we've
missed?
S
That
should
be
documented,
and
the
question
I
already
asked
this
on
the
list
earlier
today
for
sign,
and
so,
if
we
present
too
many
models
and
providers
implement
some
disjoint
subsets
of
those
models.
We're
gonna
have
an
interoperability
challenge.
So
my
question
is:
should
we
recommend
one
specific
model
or
should
we
narrow
down
what
we're
suggesting?
Ok,
so
I'll
stop
here?
Yes,.
B
This
is
a
brand
new
document.
We
are
really
just
looking
for
comments.
We're
not
going
to
decide
today
what
to
do
with
it,
we're
looking
for
how
much
interest
there
is
and
we're
looking
for.
If
people
seem
interested,
we
would
like
to
identify
some
reviewers
that
we
can
hold
their
feet
to
the
sector's.
B
T
Well,
I
just
raised
my
hand
that
signaled
that
I
am
in
favor
for
the
working
group
picking
it
up.
This
was
certainly
something
that
came
up
really
King
crystal
clear
in
the
wake
of
the
attacks
on
dime
a
year
and
a
half
ago
that
a
lot
more
people
are
looking
to
have
multi-vendor,
setups
and
I.
Think
it's
a
mistake
for
any
particular
organization.
U
S
Are
you
asking
if
any
actual
managed
DNS
provider
was
doing
this
today,
not
to
my
knowledge,
so
at
this
point,
I've
only
had
conversation
with
them
and
they're
open
to
deploying
the
mechanisms
that
allow
this
to
work.
I've
done
some
simple
lab
tests
with
these
environments
to
make
sure
that
they
work
and
they
say
they
seem
to
work
fine,
but
I,
don't
know
of
any
actual
manage
to
DNS
offender
that
can
do
this
today.
S
For
the
for
the
DNS
key
response
that
will
be
larger
right,
so
the
zone
responses
for
other
data
in
the
zone
are
gonna,
be
what
they
used
to
be
well,
it's
certainly
worth
mentioning
there
are.
You
know,
people
who
run
large
DNS
key
sets
in
the
wild
today,
right
and
without
notable
issues,
but
it's
worth
noting.
Thank
you.
Karl.
V
West
vertical
USCIS
I,
you
know
for
those
in
the
room
that
want
you
know,
SEC
to
be
further
deployed
and
increased
to
go
out.
I
think
the
stock
union
is
a
must
I,
think
it's
a
good
start
and
well-written
those
that
1d
no
sick,
you
know
die.
A
horrible
death
should
probably
come
on
the
negative
side,
because.
V
We
wanted
there's,
this
type
of
usage
is
going
up
not
down,
so
we
either
have
to
figure
out
a
way
to
support
it
or
not.
Right
as
to
you
know,
should
we
pick
one,
that's
better
or
worse,
I
would
say:
let's
leave
it
as
a
pro
and
con
list
and
just
realize
it.
There
was
another
document
that
passed
that
my
colleague
with
rush
wrote.
Then
that
displayed
pros
and
cons
of
doing
split,
DNS
and
how
to
do
it
and-
and
he
didn't
do
it-
he
didn't
say
a
suggestion
other
than
don't
do
it,
but.
V
J
S
N
W
S
Q
G
P
X
I'm
going
to
juice
another
animal
into
this
DNS
menagerie
that
we're
creating
here
and
I'm,
struck
by
a
boxer
the
horse
from
animal
farm.
If
we
can
just
throw
more
stuff
at
this
DNS
SEC
thing
or
get
more
people
to
actually
say
in
the
zones
and
I'm
sorry,
I
strongly
disagree
with,
what's
being
said
at
this
meeting,
so
far,
I
really
can't
see
adding
more
parts.
Moving
parts
to
this
DNS
sake
say
anything
actually
helping
getting
this
stuff
deployed.
I
really
strongly
disagree
with
that.
X
No
it's
great
we've
got
hosting,
provide
the
show
some
interest
in
that,
but
other
customers
showing
any
interest
in
this-
is
this
really
going
to
move
things
forward?
If
there's
any
kind
of
evidence
of
that,
then
yes,
I
would
be
more
willing
and
receptive
to
kids
over
this
idea,
but
I.
Finally,
I
just
don't
see
it
so
I
think
Harry
people's
bet
and
think
about
this
as
being
yet
another
example
of
another
straw
for
the
camel,
or
in
this
case,
boxer
right.
X
J
S
I
wrote
the
reason
I
wrote
this
draft
is
because
there
is
a
customer,
namely
the
company
that
employs
me.
Who
wants
to
do
this
right
and
that's
sweet.
It's
a
big
company,
and
so
as
far
as
other
many
customers
out
there
I
think
the
problem
is
there
aren't
many
commercial
customers
for
DNS
SEC
in
the
first
place,
so
that's
a
deficit.
We're
gonna
have
to
address
at
some
point.
Yeah.
X
X
X
B
W
Still,
oh,
okay,
so
basically
I
thought
it
will
be
nice
to
say
something
on
the
Dina's
hackathon
that
we
did.
Most
people
were
actually
working
on
the
dope,
but
they're
actually
also
other
people.
Just
well
me
Shane
working
on
something
else.
We
were
sort
of
welcome
to
work
on
I,
said
I've.
This
expired
draft
from
three
years
ago
and
would
just
be
fun
and
to
see
if
I
can
get
this
implemented.
The
same
said:
okay,
let's
do
that
and
that's
we're
off
this
minimum
x4,
basically
very
shorts,
minimal
x-bar
is
when
I
was
working.
W
I
hope
in
sec.
I
noticed
that
there
were
some
transfers
coming
out
incremental,
never
really
large.
There
were
maybe
sometimes
even
larger
than
a
x4.
Basically,
why?
Well
you
change
our
sets.
You've
resigned
our
assets
and
then
in
your
x4
it
says:
well
you
have
to
delete
distinct
signature
and
then
you
have
to
add
the
signature.
Well,
you
actually
already
know
that
you
have
to
delete
this
image
because
the
data
has
changed.
So
there's
a
lot
of
redundant
data
and
try
to
tackle
that
in
that
draft.
W
So
well,
what
we're
going
to
do
we'll
take
name,
server,
implementation
and
see
if
we
can
get
that
hacked
in.
We
considered
all
four
bigger
open
source
name
service
authority,
the
name
service,
but
powerdine
asked
for
two
all
knowledge
at
that
time
and
NSD
didn't
do
as
far
as
master
and
the
other
was
bind.
And
so
we
did
it
in
not
sorry.
J
W
W
W
I'm,
actually
not
here,
to
try
to
get
mix
for
resurrected
or
adopted,
maybe
a
my
accent,
maybe
because
they
are
all
the
week,
a
lot
of
talks
about
other
improvements
that
we
can
do
to
a
DNS
application.
Obviously,
Pekka
size
is
important.
The
there
are
large
anycast
networks
running
here.
We
have
low
time
on
when
we
want
to
replicate
that,
so
those
will
benefit
from
the
mix
for
kind
of
approach,
but
we
also
maybe
want
to
have
like
eggs,
for
only
that
is
a
better.
W
If
you
know
multi
master
mode,
where
you
can
say
I,
don't
not
giving
you
an
egg.
So
for
our,
please
try
to
excess
oil
from
a
different
master,
and
there
are
many
other
ideas
like
we
saw
a
couple
of
them
here,
trying
to
get
things
in
band.
Maybe
it's
even
better
to
have
a
separate
protocol.
It
has
been
said
before
so
yeah
I'm
here
to
see
if
people
are
interested
in
working
on
it,
if
we
should
do
small
adjustments
or
if
we
should
focus
on
maybe
on
a
different
protocol.
W
F
Reproduce
the
things
that
other
things
can,
because
there's
actually
mathematics
here
about
whether
you
can
prove
prove
that
these
group
dates
are
exactly
identical
to
the
atomic
single
transaction.
I
think
they
probably
are.
But
do
you
think
there's
any
chance
that
you
could
do
some
things
in
one
that
you
can't
do
in
the
other.
F
B
R
Ridiculous
I
think,
which
is
a
great
idea,
I
think
we
should
try
to
move
this
forward.
As
you've
already
said,
we
have
large
anycast
networks.
A
lot
of
people
here
do
have
those
and
we
I
think
this
is
not
as
strong
in
the
back
of
the
car
I
think
this
is
more
like
improve
it
paw
of
the
camera
or
a
spine
because,
as
as
you
said
to
we,
the
the
industry
is
most,
the
users
are
pushing
the
industry
to
shorter
increase
incremental
publications.
R
W
R
I
think
we
have
plenty
of
spaces
to
for
for
meta
resource
records
on
the
protocol,
and
this
is
only
something
for
the
provisioning
and
for
the
infrastructure
of
DNS.
This
doesn't
deal
with
the
protocol
by
itself,
so
I
think
we
could
continue
to
use
the
way
you
were
proposing.
I.
Think
so.
Okay
know
that
I.
Q
Am
Shanker
the
other
person
who
worked
on
a
coupon,
so
I
actually
think
it's
a
terrible
idea,
and
we
should
do
another
protocol
for
basically
the
same
reasons
that
I
discussed
with
the
catalog
zones.
I.
Think
we've
we've
reached
the
end
of
useful
life
and
we
can
do
all
kinds
of
sexy
fun
things
if
we
break
free
of
the
constraints
of
having
to
do
it
over
port
53.
J
Y
Y
Thank
you,
okay,
so,
first
the
problem
statement:
there
are
some
stupid,
DNS
tricks
and
security
challenges
related
to
DNS
and
enterprises
just
want
to
solve
them
somehow
and
under
most
conditions
they
prefer
to
go
with
some
managed
solution
or
as
somewhat
as
some
folks,
a
lot
to
put
it
cloud
based
solutions.
There
are
a
lot
of
them
present
on
the
market,
but
there's
one
issue
related
to
almost
all
of
them,
so
you
actually
need
to
synchronize
zones
with
those
providers.
Somehow
and
yes,
there's
a
standard
mechanism
for
that.
Y
Yet
for
many
of
those
managed
DNS
providers,
it's
just
not
implemented
like
with
Amazon
Road
53.
They
were
considering
implementing
zone
transfers
back
almost
six
years
ago.
It's
still
not
supported.
The
other
example.
Here
is
Asia,
which
is
like
having
some
transfers
on
there
like
lists
of
tasks
for
one
and
a
half
years,
but
it's
still
not
supported
what
they
do
offer.
Instead,
that's
API,
which
is
most
likely
JSON
or
XML
RPC
restful
as
well,
and
you
can
use
that
to
keep
the
data.
Y
The
DNS
data
in
sync
there
are,
as
we
almost
any
stable
trend.
There
are
solid
reasons
why
things
are
going
that
way.
First
of
them,
that
is,
that
standard
zone
transfer
mechanism
doesn't
support
all
those
stupid
tricks
which
enterprises
always
try
to
try
to
use
and
sometimes
depend
on
that
heavily
next
load.
Customer
generally
want
some
status
or
feedback
or
statistics
about
how
well
the
cloud
service
is
actually
serving
his
records,
so
the
amount
of
requests
inside
per
second
to
the
traffic
as
well
and
for
some
alton
reputed
companies
like
what
chain
startups.
Y
Ok,
so
so,
basically
we're
our
idea
is
to
create
a
common
denominator
for
those
restful
api
s--
for
new
providers
entering
the
market,
as
well
as
old
providers
who
might
want
to
ease
emigration
of
customers
towards
the
service
or
maybe
adding
a
new
provider
in
in
line.
Who
is
also
helpful.
This
is
basically
as
for
camel.
We
are
not
adding
anything
to
the
DNS
protocol.
It's
we
are
just
building.
On
top
of
that,
that's
restful
JSON
over
HTTP,
with
core
concepts
taken
from
the
adopted
terminal.
Y
The
protocol
should
be
extensible
because
there
will
be
more
features
in
the
future,
and
we
all
need
to
support
that.
So
in
case
this
is
something
of
a
working
group
wants
to
work
on
or
participate
in.
That
here
is
how
we
are
going
to
do
that
here.
Key
milestones,
hopefully
we'll
have
something
solid
next
year.
Thanks
questions.
P
Y
Don't
think
so,
and
probably
we
we
have
Paul
Hoffman
here.
I,
probably
you
know
the
idea,
isn't
it
to
introduce
something
you
there?
Our
idea
is
to
make
some
order
across
what's
actually
happening
and
if
you'll
look
at
the
API
is
for
Amazon
or
NS
one
or
Dyne,
maybe
that's
they
are
completely
different
from
though
so
we
are
not
going
to
change
the
way.
Planets
is
spinning.
We
just
want
it
want
to
bring
some
sanity
some
order
into
that.
B
Okay,
I'm
gonna
cut
the
mic
line
and
unfortunately
we
are
not
going
to
get
to
the
last
two
presentations
on
the
agenda.
We've
had
livelier
discussion
than
we
really
had
time
for
and
thanks
everybody
for
participating
and
everything.
You
know
the
slides
are
there
and
we
can
continue
all
the
conversations
on
the
mailing
list,
but
for
now
go
ahead,
warren
and
then
we'll.
Z
M
Good
question
thinking:
fetish
projects
is
ethnic.
This
I'm
in
DNS
up
it
is
don't
have
very
well-established
track
of
designing
RPC
interfaces.
So
maybe
it's.
This
must
like
not
invented
here
syndrome.
Right
again,
we
should
be
reusing,
whatever
other
ITF
working
groups
established,
which
is,
for
example,
the
ank
or
something
else,
but
please
don't
invent
new
RPC
or
they
out
there
I
mean
just
you
know,
young
and
and
so
on.
That's
it.
B
B
We'll
go
to
the
mailing
list
for
further
discussion.
I
hope
people
heard
ideas
of
interest,
but
we
could
I
would
love
to
go
longer,
but
we
really
can't
it's
the
end
of
the
day
and
we'll
leave
out.
We
will
be
losing
our
remote
support,
so
thanks
everybody
and
we
will
see
you
on
the
mailing
list.
We
will
summarize
impressions
from
the
reactions
to
these
drafts
here
and
get
those
to
the
list
soon,
and
thanks
for
your
participation.