►
From YouTube: IETF105-DNSOP-20190723-1000
Description
DNSOP meeting session at IETF105
2019/07/23 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
B
A
Welcome
demon
excellent.
Thank
you
very
much.
A
note
well
take
notice
of
this
note.
Well
is
also
applied,
so
this
working
group,
of
course,
blue
sheets,
please
fill
them
in
with
a
full
room.
We
want
to
have
a
large
room
and
for
the
next
time
also
to
accommodate
everyone.
Thank
you
agenda.
We
have
a
full
agenda,
so
please
bear
with
me
if
we
are
a
little
bit
strict
on
time
management
depending
on
a
discussion.
Of
course,
we
have
some
current
working
group
business
to
a
name.
We
have
something
like
the
chairs
introduction.
A
We
will
give
brief
context
about
a
name
and
a
new
draft
by
Eric,
negan,
I,
sorry,
I've
mispronounced,
your
name
about
HTTP
SVC,
well
gives
a
little
bit
context
how
they
overlap,
but
also
different
new
working
business.
It's
not
all
new,
but
it's
not.
It's
not
dinner.
Stop
working
business
yet
is
work
on
the
r
DD,
r
DB
d
by
Steven
and
maybe
Carson
okay.
Some
will
give
a
presentation.
New
work
by
Paul,
hora
Giovanni
will
give
an
update,
etcetera
if
time
permits
what.
A
I'll
give
a
presentation
on
Venus
comfort,
good,
let's
get
started,
so
we
want
to
start
with
a
name
discussion
here.
A
name
has
seen
a
number
of
iterations
after
Tony
did
some
redrafting
of
the
document.
It
simplified
a
name
draft
and
it
makes
a
distinction,
be
the
authoritative
parts
and
the
recursive
part.
So
much
of
the
complexity
are
in
the
recursive
part
and
the
more
simple
use
case
are,
in
the
alternative
part,
a
name.
A
At
least
it
started
out
to
solve
a
problem
like
an
alias
or
a
cname
in
the
apex,
but
it
also
has
other
solutions.
That's
a
solution.
It
spawns
a
solution
space
with
the
recent
SPS
SVC
proposal.
It's
address
is
partly
the
same
problem:
provisioning
web
services
or
names
for
web
services
on
different,
maybe
multiple
CD
ends,
so
that
seems
to
be
an
overlap,
so
the
chair
still
believe
they
addressed
different
problem
spaces
with
an
overlap,
but
are
still
both
worthwhile
to
explore.
A
So,
let's
keep
that
in
mind
when
we
discuss
the
different
drafts,
more
specifically
a
name,
and
if
you
have
more
interest
in
that's
use
case,
a
name
is
very
interesting.
If
you
talk
about
API,
so
if
you
go
for
fertilization,
you
have
all
kind
of
services
on
different
places
that
move
around
you
want.
So
it's
not
specific.
It
has
started
a
name.
Work
started
out
for
the
web
services
and
the
CDN
said
provisioning,
but
it
has
a
larger
solution.
Space
also
for
api's,
and
not
necessarily
web
services.
Web
browsers.
A
Tim
should
I
mention
something
else
on
this
topic
to
give
some
context
so
so
for
keep
in
mind
as
the
authoritative
parts
comp
less
complex
in
the
recursive
part
for
HCPs.
It's
straightforward
cotton
quality
solution,
but
it
probably
needs
some
additional
processing
for
the
records,
but
we
expect
I
am
NOT
and
web
browser
developer.
This
additional
processing
is
probably
done
by
the
web
browsers
anyway
or
might
be
end
up
somewhere
extra
work
in
Lipsey,
I,
don't
know,
but
that's
all
something
to
discuss
during
the
drafts.
I
think
I
give
sufficient
contacts
on
both
the
draft.
A
We
reserved
quite
some
time,
twenty
plus
twenty
minutes.
So
it's
about
40,
ish
minutes,
including
discussions.
Of
course
I.
Think
we
go
to
the
remote
presentation
by
my
dice.
Evan
will
be
in
the
room,
is
in
the
room
and
this
will
act
as
a
backup
for
discussions
and
explanations.
I,
don't
think
it's
necessary,
but
okay.
Thank
you.
C
A
C
So
they
know
already
mentioned
a
little
bit
on
the
motivation,
so
this
slide
should
be
a
little
bit
of
repetition.
This
is
the
motivation
we
started
out.
We
want
to
do
seeing
them
at
the
apex
of
the
suit
work
for
the
CBN's,
but
it's
not
the
only
use
case,
although
admittedly,
it's
probably
the
largest
use
case,
the
nests
provide
us
with
silly
end.
Customers
now
have
their
own
propriety
solutions,
and
so
it's
hard
for
them
to
to
switch
providers
or
support
multiple
model.
Next
slide,
a.
C
Basically
forget
everything
before
the
no
version
that
version
I
think
is
the
fundamental
basis
of
aiming
everything
before
had
some
issues.
It
required
to
resolve
a
spot
which
made
it
hard
to
deploy,
had
issues
with
some
transfers,
and
so
the
rewrite
actually
makes
it
much
simpler
in
the
sense
that
it
makes
aiming
processing
optional
in
every
place
but
possible
in
any
place.
C
What
that
means
is
that
afforded,
if
can
do,
the
ending
processing,
but
then
the
result
can
also
do
they
mean
processing
and
that
might
be
redundant
if
both
to
them,
but
it
still
works
from
there
I
sort
of
cook.
The
editing
obligations
on
me
and
I
made
it
first
and
editorial
version
which
is
attached
to
a
tree
and
then
a
one
that
resolves
some
issues
that
was
still
existing
in
a
digital
version
next
slide.
C
C
C
C
C
Afford
use
with
a
lot
of
issues
that
were
mentioned
on
the
list,
put
him
to
the
github
and
then
and
then
we
solved
these
three
I
think
are
the
main
ones.
First,
one
is
alien
precedents.
There
was
a
discussion
whether
the
addresses
that
are
next
to
the
aining,
whether
they
should
override
aiming
or
could
be
used
as
a
defaults.
When
the
lookup
fails,
for
example,
we
resolved
it
to
being
as
a
default.
C
That
means
in
the
co2
version
that
was
already
okay,
so
little
tax
changes
were
needed
for
the
affirm.
The
second
one
listed
TTL
considerations
when
doing
a
target
lookup.
Now,
when
you
have
resolved
the
target
and
you're
going
to
place
the
sibling
other
circuits,
if
the
TTL
will
be
the
minimum
of
all
the
encountered
TTL.
So
if
you
do
look
up
in
Percy
name
on
or
a
name,
you
will
minimize
the
TTL
and
then
eventually
will
be
target
and
so
you're
going
to
necessary
matters.
It's
the
TTL
will
be
the
lowest
you'll
encounter.
C
This
is
because,
when
you're
doing
this
at
the
afford
it,
if
you're,
actually
playing
as
a
resolver-
and
so
you
can
do
some
caching,
but
then
you
have
a
cache
at
your
authoritative
and
then
the
client
will
ask
for
records
and
they
will
cast
themselves
as
well.
So
there's
some
TTL
stretching
here
and
and
taking
the
minimum
TTL
will
mitigate
against
it's
a
little
bit.
We
also
put
some
text
in
there
for
those
stretching
considerations,
explain
what
exactly
happens,
and
the
third
point
is
whether
the
sibling
advocates
records
should
be
in
the
additional
section.
C
So
let
me
rephrase
again
whether,
when
you
do
a
address
query,
so
cute
IP,
say
or
four
day
whether
the
a9
should
be
in
the
answer
section
or
in
the
additional
section
am
is
part
of
the
answer,
so
it
makes
sense
to
put
them
in
the
am
section.
But
Tony
pointed
out
that
the
DNA
is
caused
a
lot
of
issues.
C
C
So
an
address
query,
which
has
an
a
name
on
that
evening,
may
trigger
another
additional
query:
to
look
up
that
target
that
can
hit
another
server.
That
has
a
name
name
and
that
will
point
back
to
eventually
the
same
server.
Creating
a
loop
and
it's
very
hard
to
detect
a
blue
young
posted
is
to
list
with
some
options
to
resolve
it.
C
One
option
is
to
put
the
logic
that
a
queue
type,
a
name-
means
that
the
afforded
a
service
should
not
almost
not
chase
the
target
so
that
accent
avoids
or
allows
for
a
target
look
up
without
one
have
to
worry
about
a
loop
and
the
other
one
is
having
an
easiness
option
and
that
says:
don't
chase
targets.
I
know
a
name
myself.
C
My
personal
consideration
that
the
last
one
is
that
eventually
will
hope
that
browsers
will
query
for
a
name
or
similar
record,
and
how
will
they
signal
that
support
and
also
in
the
current
version
of
the
draft
we
say
a
for
deaf
can
do
any
processing,
which
also
can
do
any
processing.
So
if
we
resolve
a
signal,
support
for
a
name
and
authority
could
still
chase
targets
because
it
wants
to
give
the
most
optimized
response.
C
My
feeling
is
that
that
you
could
use
the
currently
known
sibling
other
circuits
as
the
best
effort
or
another
option
is
to
transfer
fail
because
on
your
lookup,
something
unexpected
happens.
So
would
you
give
back
a
slightly
less
optimized
response,
or
would
you
prefer
to
signal
that
that
I
look
up
films.
C
C
E
Hunt
is
see,
I
was
the
original
name.
Draft
author
and
I
wanted
to
make
a
similar,
but
also
kind
of
different
point.
I
also,
don't
think
we
should
go
to
last
call,
but
it
has
always
been
my
opinion
from
the
beginning
that
the
reason
I
was
doing.
The
a
name
draft
was
that
I
did
not
expect
browser
uptake
of
any
other
solution.
E
I'm
getting
the
impression
now
that
there
is
some
momentum
for
browsers
to
take
up
HTTP,
SVC
and
I
believe
that
if
they
do
so,
I
would
personally
recommend
that
we
not
proceed
forward
with
a
name.
I'd
suggest
that
we
shall,
but
until
such
time
as
we
have
a
really
clear
use
case,
that
justifies
the
weight
on
the
camel.
E
F
Tim
was
sinski,
I
know,
I
made
some
comments,
kind
of
cautious
about
it.
Http
VC,
but
I've
really
come
around
on
it.
I
like
a
lot
of
the
ideas,
especially
not
putting
you
know
stuff
in
there,
but
I
ever
saw
a
name
as
trying
to
solve
the
web
problem.
I
always
saw
it
trying
to
solve
the
name
at
Apex
problem
and
so
and
I
think
part
of
my
problem.
F
This
is
what
I
didn't
want
to
sit
up
there
today,
because
I
spend
way
more
of
my
day
now
talking
about
containers
and
sight,
cars
and
service
meshes
and
all
these
things
and
I'm
think
about
like
I,
see
we're
aiming
I
get
host
my
name
right.
I.
Remember
it
mentioned
that
to
Eric,
and
that's
like
how
do
we?
You
know
you
know
a
night
Eric's.
F
You
know
Eric
had
some
great
answers
for
that
right,
but
and
I
look
at
all
these
zones,
so
I'm
an
operator
right
and
I
I
work
for
a
crazy
company
that
does
weird
things
and
so
but
I
spend
a
lot
of
time.
Looking
at
zone
data
I
see
no
zones
anymore
with
a
and
quad-a
in
them
anymore,
and
they
do
crazy
things
where
they're
just
service
cuts.
F
F
This
is
a
totally
different
reality
than
I,
think
anybody's
ever
thought
of
right,
and
so
it's
like
I,
think
I'm
in
a
weird
world
and
I
understand
that
but
I'm
trying
to
feel
I
think
they
both
have
value,
like
you
say
and
I'm,
but
it's
like
I
think
a
team
needs
to
be
simpler
as
far
as
the
best
race.
It
say
it
and
I
can
see
a
name
being
like
your
worst
case,
performance
thing
for
web
stuff
and
then
hey
that
makes
you
want
to
like
move
to
the
HTTP
service,
which
faster
kind
of
thing.
F
G
Ron
Dixon,
Go,
Daddy
I,
agree
with
most
of
the
previous
folks.
That
HDPE
SBS
definitely
is
SBC
is
is
the
way
to
go
for
the
web
use
case,
I'm
wondering
for
the
API
use
cases,
whether
it's
feasible
to
go
back
to
you
to
the
the
larger
more
generic
SRV,
if
that's
feasible
at
all.
But
it's
something
to
consider
as
well,
but
definitely
my
vote
would
be
for
putting
on
putting
a
bit
of
a
break
on
a
name
until
we
know
about
the
the
other
proposal.
Okay,.
H
Better
shakes
is
I,
think
I
think
that
the
last
call
is
well
premature.
The
sections
1
1
to
4
are
ok-ish
and
could
solve
the
interoperability
problem
between
health
providers
and
that's
okay,
but
the
processing
Condor
is
oversized
sections
5
&
6
needs
more
work,
so
we
either
postpone
the
last
call
and
refine
resolver,
processing
or
splitted
to
two
drafts,
and
you
know
dude
solve
the
interoperability
for
cloud
providers
and
then
go
and
look
at
the
optimizations,
because
the
resolver
processing
is
just
optimization,
not
requirement.
Yeah.
C
I
Heights
tell
Tim,
you
managed
to
confuse
me
a
little
you
started
off
by
saying
you
never
saw.
A
name
is
solving
the
web
problem,
but
I
was
just
solving
the
C
name
at
the
apex
problem,
which
I
understand
all
those
words.
But
to
me
the
compelling
use
case
that
C
named
at
the
apex
was
the
problem
for
was
the
web
and
I
wasn't
aware
that
there
were
other
compelling
use
cases
and
it
and
and
records
at
the
apex,
make
a
big
difference
there
for.
I
F
Doing
since
again,
yeah
it's
it's
not
even
it's
not
even
like
the
browser
stuff.
It's
all
that
back-end
servers
that
talk
to
all
the
back-end
services
that
talk
to
all
the
various
things
that
are
basically
and
they're
just
setting
up
zones,
understanding
something
at
the
apex.
It's
like
why
not
I
have
an
apex
right.
Why
do
I
need
to
actually
add
anything
else
to
it?
F
You
know
it's
like
they're,
an
engineer,
they're
working
in
some
application
space
in
the
world,
that's
kind
of
wonderful
to
them
right
and
so,
and
so
you're
saying
the
world
is
kind
of
wonderful,
thinners,
so
I,
and
so
it
that
is
sort
of
a
different
use
case
than
you
know.
But
if
you're
in
this
weird
container
world,
which
everybody
is
seems
to
be
running
into
at
full
speed,
right,
there's
they're,
just
these
elastic
services,
fancy
cloud
things
that
people
get
and
you
never
get
an
answer.
F
J
Eric
Nygren,
Akamai
and
I
think
on
some
of
those
that
that
particularly
use
case
of
cloud
services
and
I
think
one
thing
that,
before
jumping
straight
into
a
name,
is
a
solution.
There
may
be
to
step
back
and
work
with
some
of
those
folks
to
figure
out
what
the
requirements
are,
because
I
think
when
you
look
at
the
requirements
in
that
space,
especially
with
things
like
service
meshes
and
similar
becoming
more
common.
J
That
often
times
those
things
are
wanting
to
go
from
a
name
to
a
to
a
more
complicated
set
of
stuff,
like
they're
looking
to
go
to
a
IP
port
pair.
So
it
may
actually
be
that
maybe
even
SRV
or
it
should
be
a
server.
Something
else
was
actually
more
applicable
than
it
didn't
solve
that
problem.
Okay,
so
concluding.
A
C
I'm
not
convinced
yet
that
we
should
put
all
the
use
cases
in
here,
I
feel
like
people
seeing
in
and
thinking
hey.
This
might
fit
my
use
case
and
now
additional
requirements
will
come
there,
I
think
a
name.
Initially,
the
motivation
was
to
have
something
else:
that
propriety
idea,
cinematic,
VFX
solutions
and
there's
those
all
are
basically
going
to
a
different
name
at
your
apex.
C
That
is
what
aiming
provides
sure
if
the
working
group
now
thinks
we
should
come
up
with
the
solution
that
fits
both
CDN
and
service
end
points
and
they
text,
and
then
we
should
say,
take
a
step
back,
but
that
was
never
the
initial
case
of
anything.
So
putting
all
those
many
use
cases
in
the
draft
I'm
not
convinced
that
it's
a
good
idea.
A
Thank
you
to
make
some
progress,
but
I'm
just
proposing
this
without
any
consultation,
and
maybe
so
in
August
Tim
always
tells
that
all
the
Europeans
are
on
holidays,
who
nothing
happens,
but
maybe
in
September
October
ish
early
October.
We
can
plan
a
virtual
meeting
on
this
topic.
Do
you
get
the
use
case
order
the
overlap
and
the
differences
and
more
clear
straighten
out?
So
we
have
something
more,
the
next
step
for
the
next
RDF
meeting
in
Singapore.
A
A
K
J
That's
better
no
degree
of
eating
them
out.
My
could
have
helped
in
that
case,
so
eight
can
talk
about
HTTP
VC,
which
is
a
little
bit
of
a
mouthful.
J
But
there
was
a
concern
on
the
browser
side
on
this
like
oh,
if
we
have
to
go,
do
an
extra
DNS
lookup
for
that
particular
use
case.
What
is
gonna?
Be
the
performance
impact?
What's
going
to
be
the
impact
on
bad
home,
bad
home,
recursive
resolver?
Is
it
that
don't
know
about
extra
record
types
is
and
also,
as
you
start
accumulating,
these
different
record
lookups?
J
Are
you
going
to
be
in
a
situation
before
where,
where
it's
not
just
one
lookup,
you
have
to
make
that
it's
ten
different
lookups
and
then
you
have
correlation
issues
between
them,
so
HTTP
SVC
tries
to
look
at
some
of
these
holistically.
The
things
which
some
of
the
use
cases
we've
been
trying
to
address
have
been
the
encrypted
S&I
keys
discussion.
That's
been
going
on
in
the
TLS
working
group,
which
we've
had
a
number
of
design
meetings
around.
J
There's
the
the
ability
to
negotiate
a
transport
protocol,
in
particular
for
HTTP
3,
where
with
HTTP
2,
you
can
use
a
LPN
to
negotiate
upwards
with
with
HTTP
3.
Currently,
the
only
way
to
get
to
actually
use
quick
is
to
first
go
through
TCP
by
H,
2
or
H
1,
and
then
get
a
header
back
that
cause.
You
negotiate
up,
so
the
next
row
round-trip
there
that
having
that
information
having
information
in
DNS
could
help
skip.
J
There
is
a
use
case
of
indicating
that
that
in
origin
defaults
to
HTTPS,
so,
for
example,
in
the
browser
use
case,
if
someone
types
a
bear
name
like
example.com
into
a
web
browser,
does
the
web
browser
default
into
HTTP
or
HTTPS.
Today
it
has
to
go
to
http
M
securely
and
get
a
redirect
back,
and
this
prevents
an
opportunity
to
to
have
a
say,
much
more
safe
and
secure
default
as
more
things
ibiki
to
PS
by
default.
And
then
the
a
long-standing
issue
on
the
dns
ops
side
is
is
hey.
We
created
this
SRV
record.
J
Why
won't
the
browser's
implement
it
and
which
led
to
a
number
of
VA
named
discussions
of
okay?
We
need
to
create
a
name
because
browsers
won't
implement
as
haven't
implemented
s
SRV,
and
that
chicken
and
egg
there
and
being
able
to
address
that.
But
then
also
it's
clear
that
we've
been
accumulating
these
use
cases.
It
was
probably
going
to
be
the
n
plus
one
in
a
year
or
two
or
three
from
now.
J
In
fact,
I've
been
kind
of
terrified
at
the
number
of
people
who
have
come,
come
up
with
other
use
cases,
not
all
of
which
are
applicable,
and
since
the
since
that
or
the
first
version
of
the
draft
was
published
so
being
about
to
be
extensible
without
having
to
go
and
add
new
record
types.
That
browsers
would
have
to
look
up
so
the
goal.
Here
we
have
a
single
new
brow,
a
single
new
record
that
browsers
could
resolve
in
parallel
with
the
a
and
quad-a
lookups.
J
That
would
be
extensible
enough,
that
we
could
use
for
the
next
solve
kind
of
the
current
cases,
but
but
but
also
be
extensible
enough
to
cover
the
next
few.
The,
but
also
to
do
this
in
a
way.
That's
a
that
is
usable
for
operators,
usable
for
site,
site
owners
and
has
some
ability
to
do
some
of
the
performance
optimizations
so
that
it
doesn't
have
a
huge
lots
of
different
RT
T's
in
the
case,
word
has
been
set
up.
J
J
You
need
to
glue
together
and
return
back
to
clients
as
a
a
single
unit,
and
some
of
those
may
be
references
off
to
other
things
to
go
use.
So,
in
the
SRV
case,
it
was
a
you
had
as
the
name,
something
which
was
basically
the
name
and
the
port
in
the
scheme
and
the
target
of
or
the
data
of
the
RR
was
a
combination
of
things.
It
was
that
service
Jim,
it
was
a
a
domain
name.
J
It
was
a
port
and
priority
information
on
HTTP
SRV
basically
starts
off
with
that
basic
kind
of
port
and
I
end
and
hostname.
That
SRV
has
but
then
makes
it
extensible
so
tied
to
those
two
and
tied
to
that
are
that
are
within
that
are.
Are
you
can
start
adding
on
additional
information,
such
as
as
the
what
is
the
application
protocol,
such
as
h3,
that's
supported
if
there
are
any
es,
ni
keys
that
are
needed
to
negotiate
and
the
handshake?
J
What
are
those
and
part
of
the
reason
why
it's
critical
to
have
those
kind
of
bound
together
at
the
RR
is
because,
like
in
the
es
and
I
discussions
within
the
TLS
working
group,
you
may
have
these
different
different
services
being
operated
by
different
operators.
You
may
have
with
transitions
where
we're
seen
amis
has
switched
from,
or
things
are
switching
from.
J
One
hosting
provider
to
another-
or
you
have
operational
upgrades
or
you
may
have
multi
CDN
use
cases
and
you
try
to
mix
and
match
things
like
es
ni
keys
and
which
application
protocol
is
supported
with
which
actual
services
imports
to
connect
to
work
so
well.
So
there
are
two
forms
of
the
HTTP
SVC
record,
one
of
those.
J
If
you
look
at
the
structure
of
the
record,
the
and
the
defaults
in
the
candidate
for
the
default
HTTP
port
and
scheme
doesn't
use
any
label
prefixes
and
that
operationally
makes
a
bunch
of
things
easier,
but
in
the
the
Ana's
alias
form,
the
very
first
element
is
a
is
a
service
record
type
0.
That
means
that
it's
alias
form
there's
a
priority
that
that
isn't
used
in
this
record
and
this
forms
of
0
and
then
you
have
the
service
domain
name.
So
in
this
this
form
it's
purely
an
alias
target.
J
This
is
one
which
is
handled
by
clients,
there's
no
special
hand.
It's
similar
to
SRV,
where
there's
no
special
handling,
that's
needed
by
authorities,
no
special
handling
needed
in
DNS,
SEC,
no
special
handling
needed
and
recursive,
and
then
there's
the
alternative
service
form,
which
is
basically
which
you
can
think
of
as
a
SR,
an
extensible
SRV.
So
it
starts
off
with
the
that
service
record
type.
J
And
so
in
this
case
it.
So
in
this
case
the
first
one
of
these
records
would
say
say
that
you
can
either
use
quick
to
UDP
over
UDP
2,
sv,
3,
3,
sv
c
3.
Example
that
met
8003
with
this
particular
set
of
us
in
Ikeys
or
you
could
do
HTTP
to
2
over
tcp
to
a
different
SVC
2,
with
a
different
port
with
these
other
yes
and
I,
keys
and
I.
J
It's
also
from
API
clients,
think
on
service
to
service
calls
and
a
bunch
of
this
information,
around
kind
of
port
associations
and
bindings
and
protocols
are
just
as
applicable
to
some
of
those
in
the
cloud
use
cases
as
they
are
to
the
web
browser
use
case
on
a.
How
does
this
compare?
How
do
HTTP
service
and
a
name
compare
to
each
other
I
think
they're
complementary?
J
So
the
I
think
the
big
one
of
the
big
differences
and
been
helped
clarify
that
clarify
this
in
the
slides
was
that
that
HTTP
SVC
doesn't
require
any
changes
to
DNS
servers.
It's
basically
something
that's
just
a
record
type
that
has
no
special
handling,
whereas
a
name,
on
the
other
hand,
doesn't
require
any
special
changes
to
clients
the
clients
in
it
with
you
have
a
named
clients,
basically
just
magic.
All
the
existing
clients
magically
work
with
HTTP
SVC.
All
the
existing
name
servers
just
magically
work,
so
that's
probably
the
biggest
distinction
between
those
and
any.
J
But
on
the
con
side
there.
That
means
that
it
should
PS.
Svc
is
only
respected
by
the
compliant
clients,
so
to
add
support
into
clients,
which
would
ideally
would
be
something
that
I'm
expecting
would
happen
at
the
client
library
perspective.
And
if
we've
been
looking
at
the
ecosystem
of
client
libraries
that
are
out
there,
there's
a
lot
of
cases
on
the
HTTP
I
miss
much
complexity
involved
in
making
an
HTTP
connection
already
that
a
lot
of
operating
that
a
lot
of
mature
operating
systems
are
starting
to
provide
higher
level
abstractions.
J
So
applications
aren't
going
and
doing
get
hosts
my
name
they're
going
and
provide
calling
some
some
OS
or
library
API
that
is
going
and
dealing
with
all
the
certification
DNS
stuff,
all
that
stuff
for
them,
and
this
so
that's,
presumably
where
this
would
get
shimmed
in
there.
A
downside
here
is
this
is
HTTP
specific,
but
again,
HTTP
is
not
a
is
not
just
about
web
browsers
and
I.
J
Think
a
consideration
for
this,
if
this
is
successful,
might
be
that
maybe
there
is
a
pattern
here
that
some
of
the
things
we
could
learn
by
age
from
HTTP
SVC
might
be
applicable
to
other
protocols
and
having
a
either
more
generic
or
other
record
type.
That
kind
of
leverages
off
some
of
the
things
structure
of
this
might
make
sense
to
have
is
more
generic
and
I
think
that
maybe
also
a
question
for
the
working
group
of
how
much
makes
sense
to
over
genera
size,
HTTP
SVC
versus
keep
it
focused
on
the
HTTP
use
case.
J
So
far
in
particular,
as
we
on
the
some
of
the
stuff
we
had
in
the
wire
format,
didn't
make
sense,
and
we've
cleared
that
up
based
and
I
got
some
feedbacks
from
some
browser
implementations.
In
fact,
there
is
a
already
a
bind:
nine
private
type
in
draft
implementation
that
Mark
Andrews
did
and
the
hackathon
as
presented
yesterday,
someone
did
an
implementation
and
unbound
I
was
kind
of
surprised
before
presented
that
there
are
already
two
implementations
but
feedback
comment.
Suggestions
are
most
welcome
here.
Thank.
L
B
M
Warren
Kumari,
would
you
mind
going
back
to
the
thing
where
you
have
the
old
service,
DNS
HCP,
one
yeah,
so
a
quick
question
and
sorry
if
you've
already
answered
this,
but
it
looks
like
there
are
a
number
of
things
that
you
can
stick
it
right.
There's
like
h2,
h3
ma
assist
yes
and
I
keys.
How
big
do
these
end
up?
Cuz
I
could
see
this
getting
really
large,
which
is
funded
us
I.
Think.
J
J
Is
that
that
not
everything
makes
sense
to,
especially
if
especially
when
DNS,
especially
when
DNS
SEC
validation
isn't
being
done
by
clients,
there's
some
things
that
you
might
seem
attractive
to
put
in
here,
but
would
have
unfortunate
security
properties,
so
I
think
a
lot
of
the
I
think
the
things
that
you
would
want
to
put
in
here
would
need
to
have
some
constraints
on
and
some
consideration
on
what
would
make
sense
there.
N
I
all
over
the
Muslim
CloudFlare
I
like
this
a
lot
and
I
think
this
is
a
much
better
and
cleaner
solutions
than
a
name,
but
you
have
managed
to
walk
into
the
biggest
pitfall
the
DNS
has
ever
had
with
dealing
with
records.
You
have
subtyping,
and
that
has
always
to
be
taken
as
a
backing
of
thought
and
makes
things
very
difficult.
So
I
would
propose
that
you
get
rid
of
this
first
numeric
field
in
there
and
just
have
a
case
0
with
an
empty
shrink,
just
type
2
or
type
1,
as
it
is
in
there.
N
Provision
interfaces
etc.
They
will
write
it
based
on
the
spec
when
it
gets
published.
So
when
you
implement
the
next
asked
form
or
service
record
type,
it's
not
going
to
get
supported
ever
by
most
of
the
provisions,
because
they
are
it's
a
one-time-only
write
process.
For
that
we
have
this
problem
with
DNS
keys.
We
have
this
with
all
kinds
of
all
the
records,
so
just
have
one
format,
and
that
is
acceptable
in
the
string
cut.
Yet
mm-hmm
would
be
my
suggestion,
yeah.
N
J
E
E
Movement
at
all,
yet,
okay,
I
mention
it
because
changes
and
implementation
status
on
the
browser
we'll
inform
the
decisions
that
we
make
with
respect
to
whether
a
name
is
worthwhile,
I
think
and
I'd
like
to
figure
out
how
we
can
find
out
what
what
the,
what
the
early
indicators
will
be.
If
this
is
it's
actually
getting
up.
E
Take
the
other
question
I
wanted
to
ask
all
of
our
already
mentioned
some
typing
and
I:
don't
care
subtyping
as
much
have
you
did
you
give
any
thought
to
genera
sizing
this
so
that
it
wouldn't
be
specific
to
http,
and
that
may
be
an
additional
some
type
field
that
would
indicate
that
this
is
for
a
different
but
similar
use
case.
That's
not
HTTP
I!
It's.
J
Worth
considering,
I
think
my
big
worry
about
that
would
be
that
the
our
our
set
gets
really
big
is
that
if
we
start
he's
basically
start
putting
all
the
potential
services,
if
you
basically
put
the
like
HTTP
as
a
key
in
there,
and
you
don't
do
this
as
it
and
you
don't
do
a
prefix
label,
then
your
are
our
set
has
to
contain
all
the
different
possible
services
that
you
might
support.
It
may
be
word
I,
think
it's
worth
considering
or
may
be
worth
having
genera
sizing
and
there's
a
bunch
of
different
things.
J
I've
thought
about
on
the
generic
sizing
front.
In
fact,
a
a
few
years
back
I
had
a
more
generic
draft
that
was
very
very
similar
to
this,
but
but
I,
don't
I
think.
What's
the
one
option
might
be
to
to
have
the
format
be
generic,
but
then
to
hat,
but
then
for
at
least
for
a
few
of
the
most
common
are
are
types
or
few
of
the
most
common
application
types
would
just
be
to
use
a
different
RR
type
form
for
each
of
those,
but
still
bounding
that
fairly
small.
Okay.
Thanks,
sorry,.
O
Clearly,
I
think
I
also
find
sort
of
the
IC
HTTP
service
SVC
and
just
keep
hearing
the
word
browser
browser
browser
browser.
Why
there
are
lots
of
complications
in
our
browser,
I
mean
you
use
yourself
mention
API,
endpoints
and
container
container
communication.
I
would
like
to
echo
the
call
to
sort
of
can
we
can
we
at
least
like
try
to
design
this
to
be
generic
and
not
like,
because
I
keep
using
the
word
browser.
We're
gonna
end
up
doing
some
engineering
that
only
actually
really
works
for
browsers.
O
So
if
you
have
something
like
a
split
like
DNS
was
over
with
and
application
model
like
you
know,
most
of
Android
is
like
that.
You've
got
a
DNS
resolver
and
you've
got
a
bunch
of
apps
to
go.
What's
happened
this
and
that
and
you
could
you
could
say
that
what
saps
a
browser
cuz
it
just
uses
HTTP
but
I,
think
we
might
you
know
it
TLS
or
it
yet.
Tls
service
seems
like
a
good
idea,
because
it
is
a
lot
of
this
is
in
fact
TLS,
but
you
know
SMTP
also
uses
TLS.
O
O
Actually
this
group
can't
do
protocols
or
can
it
I
don't
know,
but
then
then
then
I
think
you
know
it
would
sort
of
I
think
it
would
I
think
it
would
help
a
lot
if
we,
if
we
looked
at
because
I
I
guess
I
see,
maybe
you
know,
maybe
this
can
become
what
s
are
we
never
could
right
so
and
I
think
for
size.
Your
concern
was
size,
but
I
can't
think
in
practice.
We're
actually
gonna
end
up
doing
this
over
TCP
and
then
encrypted
transport
anyway
cuz.
O
You
probably
don't
want
that
stuff
in
the
clear
where
anyone
can
mess
with
oh
yeah,
like
I'm,
actually
gonna
move
to
a
different
port
right,
cuz
like
oh
here.
Here's
your
new
s
and
I
keys,
because
I'm
in
the
middle
and
I
happen
to
be
yours
all
right.
You
don't
want
that
anyway,
so
I
think
the
the
sort
of
size
constraints
are
really
not.
You
know
material
anymore,
but
that's
just
my
personal
opinion.
P
P
J
Added
a
slide
on
that,
but
only
put
it
in
the
deck
for
to
the
chillest
working
group,
the
but
I.
Then
I.
Think
one
thing
on
the
structure
of
this.
A
part
of
why
I'm
part
of
why
there
is
the
Elias
Forum
is
to
get,
is
to
be
able
to
to
either
see
name
or
use
the
alias
form
for
whoever
is
kind
of
operating
example.com
to
be
able
to
have
the
option
of
delegating
and
pointing
this
over
to
whoever
is
operating
the
service
so
that
the
whoever
is
operating.
J
Those
servers
could
be
returning
this
record
and
the
yes
and
I
keys
themselves,
so
that,
in
collaboration
they
could
be,
could
be
doing
that
quick
that
quick
rolling
without
having
to
do
without
having
to
go
and
find
some
way
of
getting
the
s
and
I
keys
back
into
the
back
into
the
the
first
part
domain.
But.
P
D
Ben
Schwartz,
so
ok
on
on
the
ESN
I
question.
My
view
is
that
that
we
should
pick
one
and
I
would
like
to
pick
this
one
and
not
to
the
other
one
so
that,
hopefully,
that
answers
that
question
on
the
online
signing
thing
Eric
just
answered
this,
but
in
case
it
wasn't
clear
if
you
roll
the
es
and
iqs
once
an
hour,
you
have
to
sign
them
once
an
hour
in
this.
D
In
this
format,
there's
no
there's
no
need
for
repeated
signing
and
on
the
topic
of
being
generic,
could
you
go
back
to
the
two
slides
I?
Guess?
Maybe
the
only
one
slide
this
one,
so
you
can
see
on
the
lower
example
that
there's
something
there
underscore
8
4
4
3
underscore
HTTP.
So
as
defined
this,
this
draft
does
admit
essentially
arbitrary
new
protocols
to
be
defined.
To
use
this
and
the
the
data
type.
That's
in
the
service
field.
D
Domain
value
is
essentially
a
completely
unstructured
dick
of
keys
and
values
in
a
registry
controlled
by
Ayane,
and
the
existing
definition
of
the
alt
service
field.
Value
says
that
it
is
extensible
to
non
HTTP
protocols
subject
to
I
Ana
control.
Basically,
so
you
can,
if
you're,
if
you
write
a
draft
that
defines
what
all
service
means
for
for
any
other
protocol
for
SSH
or
FTP,
then
this
this
draft
automatically
covers
you.
The
only
thing
is
that
you
do
then
need
to
need
to
do
the
name
prefixing,
as
in
the
second
example
here.
D
D
So
this
does
mean
that
well,
yeah
there's
been
talked
about
sighs
that
maybe
that's
not
as
much
of
an
issue
if
we
are
only
doing
this
over
toe.
It
also
means
that
if
we
need
to
some
of
this
information,
like
the
zone
apex
issue,
when
Chrome
is
not
talking,
Doe
there's
still
room
for
other
solutions.
For
this,
like
a
a.
A
P
P
Yeah,
so
this
is
the
summary
it
allows
you
to
kind
of
express
a
relationship
between
two
two
names
you
can.
One
of
the
pieces
of
feedback
we
got
last
time
was
that
people
thought
yeah.
I
mean
that's
interesting,
but
I'd
like
to
be
able
to
express-
or
this
is
their
relationship.
So
it's
kind
of
negative
one,
and
so
we
added
that
in
as
part
of
that
you're
going
to
possibly
have
a
long
list
of
people
that
you
don't
want
to
be
associated
with.
P
So
we
change
the
thing
to
say
you
can
either
have
a
name
or
a
URL,
and
if
there's
a
URL,
then
there
can
be
a
list
of
names.
So
those
are
the
kind
of
two
main
changes.
There's
the
optional
signature
mechanism
is
still
there.
These
are
the
kind
of
use
cases
that
I
think
we
covered
last
time.
So
unless
somebody
wants
to
jump
up,
I
won't
stand
at
that
really,
and
this
is
the
changes
which
I
mostly
said
we
had
originally.
P
You
know
at
the
first
version
of
this
we
had
a
DCAM
like
syntax,
which
is
kind
of
a
little
bit.
What
was
like
the
the
values
for
the
previous
presentation
at
this
time,
it's
kind
of
binary.
We
scripted
up
the
sample
generation
stuff,
so
it
kind
of
looks
like
it
could
work
if
people
wanted
it
to
work
and
basically
we're
just
still
looking
for
more
feedback,
we're
not
asking
for
it
to
be
adopted.
P
Just
yes,
if
we
get
more
feedback
and
if
that's
of
the
nature
that
this
is
something
that
might
get
deployed,
then
we're
happy
to
kind
of
you
know,
do
the
changes
to
the
thing
and
bring
it
to
the
point
where,
hopefully
we
could
ask
for
adoption
and
I.
Think
here
would
be
the
right
place
to
ask
for
adoption
if
any
per,
and
previously
it's
been
on
the
D
Bound
list,
because
one
of
the
apps
ATS
thought
that
was
a
good
place
to
start
discussion,
we
can
move
it
to
the
DNS
op
list.
K
Hi
Jeff
Hodges
yeah,
this
has
been
a.
Can.
We've
been
kicking
down
the
road
for
a
long
time,
it's
on
the
D
bound
list,
because
we
did
have
a
working
group
a
while
back
that
was
specifically
working
on
this
problem,
but
nobody
had
the
time
to
keep
pushing
it
forward.
We
just
kept
kicking.
Can
it
does
need
to
get
solved?
K
K
If
you
search
for
d
bound
in
file
names,
you
can
find
it
on
there's
also
the
start
of
policy
authority
draft,
which
this
is
pretty
congruent
with
the
this
draft,
does
not
yet
cover
all
the
intricity
x'
at
this
point
in
time,
it
kind
of
glosses
over
various
things
happy
to
provide
feedback
down
the
road
on
it.
I
think
this
is
good
work.
It
really
needs
to
find
a
home
and
it
needs
to
get
solved
great
thanks.
K
C
K
K
P
K
L
Stefan-Boltzmann,
I
really
don't
understand
why
we
don't
if
we
want
authenticity,
why
we
don't
simply
use
DNS
SEC.
Today's
a
draft
creates
a
very
complicated
authentication
mechanism
copy
and
paste
from
DNS
SEC,
which
adds
a
lot
of
Camela
of
style
complexity.
So
why
not
just
cutting
everything
out
on
saying
if
you
need
to
identify
this
relationship,
use
DNS
SEC,
which
is
a
proper
way
to
identify
things.
Sure.
P
You
could
personally
and
again,
if
that's
all
working,
we
wanted
to
do
fine,
boss,
I
think
there
I'm
still
willing
to
make
the
argument
that
there
might
be
value
in
cases
where
one
part
of
the
relationship,
those
have
DNS
SEC
and
the
other
does
not.
And
that's
what
the
signature
mechanism
does.
It
is
bit
a
bit
complicated,
but
it's
also
a
vast
subset
of
DNS
SEC,
so
DNS
SEC
is
obviously
more
complicated
than
what's
in
here,
but
it
adds
to
a
character.
It's
not.
Q
I'm
not
going
to
answer
that
last
question:
John
Bradley,
yubico,
I'm,
gonna,
largely
agree
with
Jeff.
We
have
web
authentic
and
binding
a
bunch
of
different
projects,
I'm
working
on
we.
If
we
keep
inventing
point
solutions
to
address
this,
these
and
the
same
issues
are
coming
up
over
and
over
again.
Eventually
we're
not
going
to
you
know,
things
will
start
falling
over
because
we
won't
be
able
to
keep
up
with
manually,
maintaining
lists
and
patches
and
it's
it
is
impacting
web.
Q
Authentic
and
the
us
relate
their
European
domain.
This
is
unreasonable
as
far
as
they're
concerned.
This
is
something
we
have
to
progress:
progress,
yeah
I'm,
not
emotionally
attached
to
this
particular
spec,
but
we
need
to
move
this
ahead.
This
may
be
a
reasonable
way
of
doing
it.
I'd
be
willing
to
work
on
it
to
make
sure
that
some
of
these
we
have
a
broad
selection
of
use,
cases
that
are
covered
by
whatever.
The
final
document
is
great
thanks.
Paul.
R
Office
in
the
past,
I
used
to
be
fairly
against
this
I'm,
not
flipping
to
the
other
side,
I'm
more
in
favor
of
it
of
doing
this
I
do
see
some
problems
that
are
not
solved
and
I'm,
not
sure
if
you
can
solve
them.
For
instance,
the
one
I
see
very
frequently
now
at
my
day,
job
is
people
doing
surveys
internally
and
then
using
a
Google
forum
and
a
shortener
and
and
so
then
it's
a.
R
Between
me
and
all
of
Google-
and
it
sort
of
doesn't
really
help
me
if
everybody
burns
to
these
super
generic
solution,
farms
domains
so
I'm,
not
sure
what
this
solution
for
that
as
a
name
that
can
be
thought
of
somehow
in
this
too,
to
have
a
more
specific
URL,
I
guess,
because,
like
I
wanna
I
wanna
maybe
specify
some
forms
with
like
a
Google
Form
URL
of
a
just
a
domain
name
uni.
So
that's
one
part
and
I
also
agree
with.
R
If
you
use
DNS
SEC,
as
the
trust
model
has
some
advantages,
one
all
people
that
keep
confusing
Transport
Security
with
with
authenticity
of
data
I
get
another
slap
on
the
wrist
of
doing
it
properly
and,
and
the
other
part
is
if
the
power
bind
draft
moves
forward,
then
that
is
actually
your
signal
of
saying.
I
am
independent
of
my
parent,
and
so
you
would
solve
that
problem.
There
Victor.
S
Maybe
can
this
do
something
that
replaces
that
entire
suite
of
use
cases
and
and
solves
that
problem
for
us
once
and
for
all
I
mean
a
lot
of
people
with
allergies
to
use
in
the
public
suffix
lists
the
way
we're
doing
it,
and
so
on
so
I'm
excited
about
this
I
want
to
see
it
move
ahead
and
if
you
need
a
home
for
it,
that
isn't
here
we'll
take
it
or
something
like
that.
But
yes,
this
is,
this
is
good
stuff
and
if
it
simplifies
our
lives,
then
we'll
be
happy
to
move
towards
that.
S
P
A
About
call
for
a
dozen
I
think
from
the
room
there's
a
lot
of
interest
and
people
want
to
work
on
the
document,
but
yeah.
Thank
you.
If
it's
a
side
mark
for
the
power
bytes,
it's
correct
the
draft
from
what
I
understand
there
was
some
interest
in
the
draft,
but
not
on
the
mailing
list
not
expressed
in
the
Menem
itself,
as
people
have
an
interest
in
the
draft.
These
also
expressed
their
interest
on
the
mailing
list,
because
it's
now
being
discussed
on
the
coordinate
on
the
hallway,
please
correct
me
follow
if
not
Breck.
A
T
T
So
here's
the
thing
this
one-
we
are
mentioning
that
you
can
implement
this
over
DNS
or
HTTPS,
and
the
client
could
also
decide
to
query
this
information
over
DNS
or
over
HTTP,
which
leads
to
an
interesting
interoperability
question,
which
is
if
the
server
and
the
client
implement
only
one
of
them
and
they
are
not
the
same.
Then
they
can't
figure
the
information
out.
So
that's
something
we
are
looking
for
feedback
here.
D
Then
Schwartz,
so
I
I
think
I
support.
Adoption
I
would
like
to
solve
this
use
case.
I
appreciate
the
work
here.
I
have
some
personal
differences
of
artistic
differences
with
with
the
engineering
choices
here,
I
really
liked
the
special
use
domain
name,
formulation
that
you
have
originally
had
much
better
than
the
than
the
reverse
IP
address
formulation,
because
I
think
a
very
large
fraction
of
users
are
behind
DNS
forwarders,
with
the
result
that
the
the
true
recursive
resolver
in
play
has
an
IP
address.
That
is
not
known
to
the
client.
D
So,
for
example,
if
ISPs
wanted
to
use
this
service
to
to
offer
improve
transports
to
their
customers,
I
think
for
residential
ISPs.
That
would
largely
not
work
because
most
customer
equipment,
most
most
stub
resolver
--zz-
are
behind
DNS
forwarder
in
their
in
their
Wi-Fi
router.
If
the
Wi-Fi
router
actually
just
passes
the
true
IP
it
forwards,
the
IP
address
of
the
of
the
ISP
resolver,
then
it
will
work
but
I'd
like
to
cover
that
use
case.
I
also
think
that
the
dot
well-known
solution
is
is
not
necessary
thing.
It
might
simplify.
R
It's
pretty
brief,
so
you
can
kind
of
reply
to
that
power.
Just
we
just
entrace
had
a
discussion
about
pcp,
190
and
using
well-known,
and
we
got
pretty
much
shut
down
it
and
you
cannot
get
an
exception
to
that.
So
not
using
without
well-known,
will
be
a
hard
problem.
You
will
first
have
to
convince
the
arc
area
to
a
piece.
Q
A
L
Like
keep
the
strategic
remarks
for
later,
when
we
will
have
content
to
put
here,
but
first
from
a
technical
point
of
view,
getting
information
about
the
network,
you
connect
to
seems
to
me
very
close
from
what
are
doing
the
captive
portal
working
group
on
also
the
entire
provisional
provisioning
demands
thing
that
is
done,
I
believe
in
the
internet
area.
So
is
it
isn't
it
simply
a
very
special
case
of
provisioning
demands,
and
should
we
instead
rely
on
the
provisioning
demands
draft
which
is
I
think
near
to
completion
so.
Q
The
answer
that
one
of
the
initial
use
cases
could
be
done
in
DHC,
as
you
were
saying,
although
there's
when
that
was
asked
earlier
in
the
dough
working
group,
there
was
very
little
interest
in
that
people
said:
no,
we
don't
care,
but
in
addition
this
allows
you
to
get
other
information
about
a
resolver.
It's
not
just
for
getting
finding
out
about
dough,
so
a
resolver
might
want
to
tell
you
other
things
about
itself
such
as
I
prefer
that
you
connect
to
me
to
me
over
TCP
things
like
that.
So
that
is
really
a
you
know.
Q
This
can
be
used
by
resolvers,
saying
to
stub,
resolver
recursive
resolver,
saying
stub
resolvers.
Please
do
this
with
me.
I
am
able
to
do
this,
so
it
really
isn't
a
provisioning
thing
as
much
because
remember
not
all
not
all
resolvers
are
provisioned
through
DHCP
people
choose
other
ones
in
other
ways,.
L
A
V
West
heard
Icarus
I
so
I
shortly
before
the
IHF
I
was
actually
gonna
write,
something
very
similar,
so
I
guess
I
support
this
in
concept.
I
was
gonna.
Do
it
in
a
completely
different
way,
so
the
way
I
was
gonna
do
it
was
actually
to
create
a
single
name
that
would
give
you
a
list
of
other
records.
You
could
go
look
up
such
like.
We
already
have
some
that
a
resolver
based
like
you
know.
What
do
you
know
ski?
Do
you
support
and
things
like
that.
Q
The
so
one
note
on
that
that
who
needs
taped
over
is
new
name
value
pair.
If
this
goes
through,
with
the
current
set
up
new
name
value,
pairs
can
be
defined
just
by
expert
review
and
specification
required
mean
just
an
internet
draft,
so
it's
very
lightweight
for
adding
in
some
of
those.
Yes,
with
the
caveat
that
I.
V
Architectural
II
we're
doing
strange
things
with
the
text
encoding
values
in
DNS.
We
now
have
records
that
are
encoding
in
a
number
of
different
encoding.
You
know
mechanisms
like
SPF,
you
know
as
semi
colon
separated
kind
of
stuff.
This
is
now
doing
a
JSON,
and
every
time
we
we
fracture
that
you
know
we
are
limiting
or
or
the
number
of
things
that
can
read
it
or
mandating
that
you
know
everything
that
needs
to
be
able
to
read
everything
go
off
and
include
the
appropriate,
parser
and
I.
V
Don't
know
positively
that
we
want
to
do
that
with
respect
to
it
would
be
easy
to
add
stuff
you're,
also
building
on
gigantic
record
sizes,
and
things
like
that,
which
is
why
I
was
sort
of
you
know,
thinking
about
an
index
based
approach.
You
know
doing
it
instead,
so
you
know
again,
I
think
I
support
the
concept
in
general,
I'm,
not
sure
I
support
the
implementation.
Q
V
Q
D
The
top
of
Ben
Schwartz
on
the
topic
of
provisioning
provisioning
makes
sense
when
you're
speaking
about
local
information
about
the
network.
I
view
this
personally,
as
non-local
at
least
my
use
cases,
as
I
mentioned
before,
are
essentially
non-local
and,
in
fact
architectural
II.
What
I
would
really
like,
although
I
don't
know
if
it's
possible,
is
a
DNS
trace
route.
That
tells
me.
W
W
D
Q
A
X
Yeah
good
morning,
everybody
so
today
we're
I'm
here
presenting
this
draft
version
for
well.
It's
strange.
A
X
So
just
this
is
just
a
draft
history.
It
was
first
presented
after
104
and
Claude,
just
a
commander,
Peter,
the
slides
here
and
today
diversion
for
we
incorporated
a
lot
of
changes
based
on
the
feedback
we
had
on
Oh.
For
all
this
changes,
our
openness
issues,
we're
open
si
shoes
on
github
II
want
to
cover
that
and
today,
we'll
be
covering
most
the
most
important
ones
only
and
before
I,
even
dive
here
to
start
to
cover
them.
I
would
like
to
thank
again
everybody
on
the
104
for
the
feedback.
X
I
think
it
was
a
little
defensive.
That's
probably
my
the
way
I'm
used
to
academic
conferences,
but
when
he
went
home
and
watching
the
video
was
like
these
guys
are
right.
So
thanks
for
the
feedback
was
really
nice,
so
changes
for
a
no
for,
and
we
had
a
discussion
on
the
title.
The
word
recommendation:
that's
very
strong
for
the
ATF,
so
we
replace
every
instance
of
recommendations
to
considerations.
X
Women
point
that
point
on
and
he
was
concerned
that
we
could
reduce
the
setups
Richard
JT,
because
if
they
everyone
would
follow
that
recommendation
and
in
also
real
considerations.
The
word
you
use
in
many
of
other
several
others,
DNS
or
Isis,
and
a
note
to
self
here.
It's
like
a
ATF
recommendations,
different
from
a
paper
recommendation
in
a
paper
recommendation,
it's
more
or
less
like
a
IETF
consideration.
X
Other
issue
draft
talks,
mostly
about
anycast
but
not
exclusively
enjoyably,
pointed
at
except
for
the
CTR
considerations,
are
other
ones
are
related
to
any
case,
and
he
is
right,
but
the
thing
is
like
this
is
a
tax
we
put
there.
Our
fix
is
based
pretty
much
saying
yeah.
That
could
be
the
case.
Can
you
work
for
other
applications,
but
we
have
only
done
for
DNS
this
academic
study,
so
we
cannot
actually
claim
that
it
would
work
for
the
others,
but
could
Wells
might
as
well
were
TTL
consideration
controversy
like
Peter
call.
X
He
pointed
how
complex
the
issue
was
before
DNS
off
like
15
years
ago,
people
try
to
figure
that
out.
There
was
a
very
complex
problem
and
he
also
said
like
tht
I
was
mostly
first
on
Montana's,
not
ops,
but
there
you
know,
there's
some
operators
that
also
zone
maintainer.
Still
this
typically
there's
child
and
parent
detail
as
well.
So
it's
important
for
issue
and
to
fix
that
we
actually
rewrote
the
entire
section
and
because
we
had
a
new
study,
the
cover
and,
specifically
the
considerations
of
TTL.
X
We
just
I
presented
last
Sunday
here
on
ia
PG
and
has
just
been
accepted
on
the
next
forthcoming
IMC
conference.
This
is
a
here
in
this
URL.
You
have
actually
the
submitted
version.
A
revised
version
will
follow
up
after
that.
So
pretty
much.
We
wrote
the
whole
thing
and
now
we
kind
of
up.
We
don't
you
don't
say
like
hey.
You
should
use
a
detail
of
one
day
or
one
hour.
X
We
just
like
measure
care
a
lot
of
scenarios
and
situations,
and
you
show
where
the
consequences
and
the
implications
of
the
choices,
because
before
people
wouldn't
you
know,
people
just
copy
and
paste
details
and
let
it
run
in
that
way.
But
now
we
can
actually
make
any
form
choice
and
how
to
choose
that
and
regards
performance
with
regards
caching
and
we've
got
a
bunch
of
stuff,
so
I
recommend
it.
You
have
a
look
in
that
paper.
Select
issue.
15
first
selection
could
be
a
more
diverse.
X
We
had
trade
different
papers
on
to
the
references
of
this
draft,
which
you
are
not
co-author
by
us.
We
also
had
this
piece
of
tax
here
to
just
say:
hey.
This
document
actually
covers
it's
based
on
research
papers
and
recommend
folks
to
read
the
related
work
section
of
those
papers
because
they
they
have
a
specific.
They
address
that
specifically.
So
that's
what
we
have
done,
I
think
George
Marcus
when
he
pointed
at
like
Atlas,
it's
typically
biased
towards
Europe
for
one
of
our
considerations.
X
That
was
like
a
c3
and
he's
right,
but
I
did
include,
and
we
have
include
that
on
version,
oh
three
of
the
trap
that
actually
the
consideration
about
any
case-
and
this
paper,
the
folks
the
altar
is
what
they
did
did
not
do
it
only
analysis
for
the
all
the
awry
pathos
probes
altogether.
They
actually
break
that
down
into
countries
and
regions.
So
the
consequences
of
that
is
it's.
X
This
text
that
we
put
there
it's
a
given
that
well
Atlas
has
a
little
bit
more
bias
towards
here,
but
the
analysis
per
country
per
region
does
not
change
the
conclusion
that
locations
of
any
caste
instances
dominates.
Latency
and
just
to
remind
us
also
peer
review
and
I
think
that's
the
most
important
issues
we
have
changed,
there's
many
more,
but
they're
on
github
and
I
just
cover
the
basic
ones.
Here,
thanks.
A
A
Considerations,
there's
a
group
of
people
here
in
their
working
group.
They
think
it's
very
interesting
and
very
good
to
have,
and
but
that's
more
the
biggest
discussion
about
the
wordy
so
and
for
the
draft
future.
It's
also,
of
course,
up
to
the
group
what
I
think
it's
a
useful
document
yeah
and
please
please
speak
up
here
in
the
room
or
on
the
mailing
list,
also
operators.
You
also
discussed
things
with
any
card
operators.
A
X
A
X
B
Alright,
so
in
the
room,
how
many
folks
have
read
it?
I
have
the
impression
a
bunch
of
people
around
this
document,
okay,
just
as
a
quick
home
to
get
where
we
are
as
far
as
the
future.
This
document,
because
because
there
have
been
a
couple
of
versions
here,
if
you
think
it
makes
sense
for
the
working
group
to
consider
this,
as
it
adds
a
working
group
draft
these
home
now,
if
you
oppose
it
as
a
working
group
draft,
please
home
now,.
B
Okay,
so
I
guess
the
only
thing
we
can
say
from
that
is.
We
were
asking
room
for
more
review
and
you
to
continue
to
take
the
feedback
up.
Chirping.
K
Thank
oh
yeah,
Matt
Poinsett
I've,
a
sort
of
a
comment
on
the
adoption
question,
since
this
is
a
review,
essentially
a
review
of
academic
papers.
I,
don't
really
see
what
the
working
group
is
going
to
do
to
improve
it.
It's
it's
an
analysis
of
research,
that's
out
there
and
I,
and
so
I
don't
really
see
what
what
the
contribution
of
the
working
group
would
be
to
improving
it.
It
really
feels
like
an
independent
submission
to
me.
Z
Posterity
discover
is
vulnerable.
Details
are
presented
in
my
presentation
at
rock
sathi,
and
this
IEP
meeting
and
energy
is
said
to
be
the
biggest
user
by
IP
fragmentation,
because
Eden's
arrow
under
dynastic
with
widely
deployed
research
papers,
described
effective,
cache
poisoning
attacks
using
IP
fragmentation
on
the
passivity
discovery,
fragmentation
cost
the
poisonous
2013
IP
hunter
shot
attack
on
DNS,
2030
domain
validation,
prosperous
for
MDM
reagent,
PKI,
2000,
2018,
auditor
toe.
We
cannot
trust
to
fragment
the
UDP
packets
and
passivity
discovery.
Z
Z
She
should
see
891
section
six
point
two
point:
one
says
that
note
that
facility
with
the
wizard
fragmentation
could
be
smaller
than
this
and
truncation
works.
Well,
when
responses
exceed
specify
the
median
suicides,
some
of
the
written
truncated
responses
and
currently
try
by
TCP
and
TCP,
is
considered
resilient
against
IP
fragmentation
attacks.
Z
Z
Then
I'd
like
to
propose
new
recommendations,
new
services
or
about
the
shooter
set
to
ETS
arrow
requested
EVP
pelo
sides
to
2120
defined
in
DNS,
take
Archie
40:35
as
minimum
pay,
Rosa
sides
and
also
observers.
Andrews
observers
should
set
each
net
zero.
Spawned
responded,
maximum
payroll
side
to
320
same
body
and
more
also
it
is
harbors,
may
send
DNS
responses.
It's
IP,
don't
hug
IP
version,
6,
don't
allow
options
and
Hulu
service
is
all
about.
May
drop
fragmented,
EVP
responses.
There
I
will
hood
on
Dennis
before
I
P
reassembly.
Z
Z
The
constant
320
is
not
good
calculate
from
passivity
or
incremental
value.
It
is
wrong
idea
and
we
need
a
special
consideration
in
small
mutant
network
when
DNS
servers
are
located
across
the
increased
empty
body,
less
than
280
choose
the
EDS,
requesters
and
responders
maximum
payload
sizes,
fit
to
the
smallest
ring,
como
tu
barrio.
Z
Otherwise
the
response
may
be
dropped
and
the
small
empty
body,
IP
version,
4
version
6
head
aside
and
UDP.
He
decides
it's
possible
in
a
genericized
or
maybe
another
recommendation.
Nina
sabado
should
be
located
on
networks.
Higher
mu,
tu
barrio
to
the
major
part
to
the
major
part
of
the
Internet
is
Raja
or
equal
to
1280
and.
Z
Deployment,
the
proposed
method
supports
incremental
deployment
when
observer
increments.
The
proposal,
the
horses
who
services
rubra,
becomes
to
avoid
IP
fragmentation
in
DNS
and
when
an
authoritative
server
implements
the
proposal,
the
authorative
Sabha
becomes
to
avoid
IP
fragmentation
in
DNS
other
proposal
case.
Basic
OTC,
with
shared
key
requires
both
requesters
and
respondents.
Support
not
implemented.
Z
Under
I
hope,
I
have
concern
about
to
drop
in
fragments,
not
written
in
draft
drop,
fragment
derocker
elementary
responses
and
DNS
responses.
I
peed
on
trot
version,
6,
don't
shrug
options,
may
cause
Deena's
communication
error
timeout
and
to
recover
situation.
Guru,
services
Israel,
who
services
world
needs
to
retry
by
TCP
transport.
It
increases,
compare
complexity
of
service,
robots,
new
robots,
and
how
do
you
consider
do
you
support
this
recommendation,
or
do
you
like
fragmentation?
AA
Though
largely
month,
on
that
note,
I
think
I
ieave
your
writing
what
you
say.
The
the
technical
content
in
there
is
quite
okay,
so
my
comment
is
just
along
the
lines
of
again
as
the
last
last
draft.
How
to
how
to
put
this
to
the
end-users
and
the
people
who
deploy
this
recommendations
is
a
strong
word.
Considerations
might
be
a
better
word.
AA
T
J
Arithmetic
on
Akamai,
have
you
been
in
coordination
with
the
TMT
SV
working
groups
working
on
APL,
PMT,
UD,
Trafford,
ideograms,
it's
addressing
is
trying
to
dress
in
similar
things.
It
may
make
sense
to
collaborate
with
them
to
figure
out.
Are
there
some
ways
to
make
this
complimentary,
because
there
may
also
be
some
ways
to
not
have
to
set
it
on
set
for
the
low
MTU
and
all
in
all
cases,
but
only
in
certain
cases.
Thank.
H
G
Dixon
GoDaddy,
but
previously
it
a
little
bit
of
follow-on
research
to
the
original
fragmentation,
poison
draft,
it's
much
much
worse
than
that
draft,
or
that
dark
paper
was
if
anybody
is
really
interested.
I
can
go
into
more
deep
he'll
at
some
later
point,
I'm,
definitely
in
favor
that
definitely
want
to
recommend
that
the
developers
of
resolvers
changed
the
default
on
their
a
dns
buffer
size
to
get
it
down
to
a
reasonable
level.
Thanks.
AB
AB
A
Thank
you
mark
from
the
mic
line.
I
do
here
in
support.
I
was
also
asked
want
to
ask
the
working
group
to
look
at
the
draft
of
supply
and
Britain,
but
mark
and
I
think
please
give
some
reply.
Some
comments,
feedback
on
the
mailing
list
and
we
will
discuss
it
with
the
chair
and
the
author
about
a
call
for
adoption
later
on
the
mailing
list.
Yep.
AC
AC
So
those
of
you
who
are
not
familiar
with
it,
it
is
basically
a
compact
or
condensed
representation
that
can
expand
similar
to
a
dollar
generate
at
a
meta
level,
and
it
can
also
be
transferred
between
primaries
and
secondaries
in
a
condensed
form.
So
a
single
record
could
expand
into
millions
of
Records.
AC
AC
This
would
just
offer
a
standard
way
to
exchange
those
records
between
the
multiple
vendors
and
I've,
also
in
the
field
I've
seen
record
or
zone
files
that
have
expanded
well
above
50,
even
above
150
megabytes
which
don't
really
transfer
well.
If
they
do
a
lot
of
timeouts
a
lot
of
errors,
sometimes
they'll
have
to
be
manually,
transfer,
etc
or
broken
into
smaller
zone
files.
AC
AC
Yes
and
I've
broken
up
the
NPN
into
a
second
draft.
Thank
you
and
we
are
still
trying
to
get
this
adopted
by
the
working
group.
So
any
questions
comments,
Jeff,
Houston,
peteus
on
it.
How
do
you
sign
it?
You
either
would
use
the
NPN
which
would
modify
the
signature
and
the
validation
mechanism
there's
another
record
or
you
would
do
online
signing.
M
AC
E
A
AD
Okay,
so
this
should
be
a
short
one:
hi
I'm
Vito
from
I
see
the
idea
is
DNS
resource
record
for
transferring
covert
information
from
primary
to
secondary,
and
don't
ask
me
about
the
covert
we've
had
this
discussion
about
how
to
name
it.
So
the
idea
is
to
transfer
something
that
should
not
be
queried
for
in
bandwidth
the
zone.
The
idea
is
for
it
to
be
generic
so
that
we
can
spend
it
with
another.
AD
Our
types
without
changing
the
behavior
of
the
server
and
the
examples
include
note
RR,
which
we
have
a
draft
for
this
Evan
is
here
as
an
author
DHCP
time
out
from
Tim,
for
example,
an
SEC
five
keys
when,
if
an
SEC
five
is
adopted
and
even
zone
signing
keys
for
inline
sign
Inc
on
the
secondary,
although
that's
that's
just
an
example,
so
don't
be
scared,
because
that's
the
most
of
the
discussion
on
the
list
was
about
examples
and
that's
just
an
example.
It's
a
generic
for
anything.
AD
The
big
I
think
the
biggest
issue
was
that
was
on
the
list
and
in
other
discussions
was
about
encryption
and
the
security
of
transfer,
because
we
are
putting
something
that
should
be
hidden
and
then
we
we
don't
encrypt
it.
We
don't
mandate
encryption
so,
for
example,
forensic
five.
The
encryption
is
not
either
because
if
you
have
the
zone,
then
the
an
SEC
five
key
is
not
needed,
for
it
is
not
necessary
for
you.
AD
I
AD
So
that's
those
are
the
questions
for
the
draft
and
the
details.
Well,
we
there
is
a
range
in
our
type
numbers.
That's
currently
reserved.
We
want
to
cut
a
piece
of
it
for
for
this
kind
of
Records.
The
question
also
becomes:
should
there
be
a
private
wrench
for
this
kind
of
Records
cut
from
also
from
the
reserved
archives?
AD
There
is
a
mechanism
that
this
allows
transfer
to
secondaries
if
they
don't
understand
the
covert
semantics.
So
if
there
is
a
second
secondary
that
does
not
understand
covert
records,
it
won't
send
the
idns
option
that
I
understand
covert
records
and
it
won't
receive
the
transfer
at
all
so
that
it
won't
serve
it
also.
The
server
must
not
serve
covered
records
without
an
explicit
ACL,
allowing
it
that's,
for
example,
for
a
note,
because
a
note
is
a
record
that
someone
an
operator
might
want
to
ask
for,
but
it
requires
an
ACL.
AD
The
other
thing
that's
in
not
in
current
version
of
the
draft,
because
I
thought
about
it
on
Sunday
is
that
we
should
not.
We
should
for
generic
types,
generic
binary
types.
We
should
change
name
so
that
the
zone
would
not
load.
If
it
has
covert
records
on
a
server
that
does
not
understand
covert
and
there
is
an
usage
we
published
those
two
drafts
in
simultaneously.
AD
There
is
a
note
or
our
definition,
which
is
basically
a
comment
in
zone
that
can
be
transferred
with
the
zone,
because
1034
has
own
comments,
but
axfr
came
a
bit
later
and
those
comments
are
not
transferred
with
the
zone
and
sometimes
it
might
be
useful
for
operators.
So,
for
example,
mark
that
this
IP
was
given
to
this
person-
and
these
you
know
it's
just
a
comment,
but
it
it
stays
on
on
the
secondary,
so
yeah.
That's
it
and.
A
H
If
HX
is
ethnic,
it
smells
like
database
and
I
SES
on
top
of
it,
and
I
have
a
bad
feeling
that
eventually,
someone
will
come
and
ask
hey.
I
want
to
have
only
this
group
of
users
allowed
to
query
for
this
type
and
that
group
of
users
allowed
to
create
that
other
type
and
stuff
like
that,
and
then
you
will
have
to
invent
mechanism
how
to
transfer
the
ACLs
and
so
on,
and
so
on.
So
I
think
it's
kind
of
worms
and
it
don't
belong
to
DNS.
Please
don't
I.
P
AD
AE
AD
The
idea
was,
you
know
if
you
want
to
put,
if
you
want
to
have
something,
that's
covert,
and
with
each
draft
you
would
have
to
specify
that
this
should
not
be
queried
for
so
the
idea
is
to
have
a
range
in
which
you
can
put
specific
resource
records.
Like
note,
like
DHCP
timeout,
like
anything
else
that
you
know,
servers
with,
would
understand
that
they
should
not
allow
queries
for
me.
E
The
comment
that
this
sort
of
thing
doesn't
belong
on
the
DNS
and
I
just
wanted
to
say
that
this
sort
of
thing
already
is
in
the
DNS.
Quite
often
it's
just
not
in
the
DNS,
in
a
way
that
is
resistant
to
open
normal
queries
from
just
everybody
and
I
have
heard
a
number
of
people
who
are
operators
request,
a
way
of
putting
something
in
the
DNS
that
will
automatically
be
replicated
to
secondaries
that
isn't
easily
queryable,
and
there
is
already
data
that
is
used
in
DNS.
That
is
not
easily
queryable.
E
You
can't
look
up
in
SEC,
3
record,
you
receive
it
if
you
look
up
something
that
doesn't
exist,
but
you
can't
specifically
query
for
it.
Policy
zones
are
often
often
have
queries,
disallowed,
that's
just
metadata
for
the
operation
of
the
server,
but
it
can
still
be
transferred
over
a
channel
from
a
primary
to
a
secondary.
H
But
there's
projects
easily
I
think
that
evan
has
a
point.
Basically,
this
is
inventing
tens
zone
transfer
protocol
which
is
intentionally
incompatible.
Video
all
one
using
the
ideon
assumption
to
prevent
the
old
slaves
from
getting
the
data
right.
So
I
think
it's
opportunity
to
invent
much
better
than
through
protocol,
which
allows
like
more
flexibility
and
don't
necessarily
stops
all
the
non
DNS
data
in
its
own
file.
Right
I
mean
this
is
the
perfect
opportunity
to
do
that.
I
think
and
do
news
on
transfer
protocols,
because
the
old
one
is
quite
horrible.
So.
V
We
have
traditionally
so
to
two
points:
I
guess:
one
DNS
is
not
designed
to
be
a
a
entity
to
entity
type
mechanism,
so
we
have
transfer
abilities
and
things
like
that
who
we
expect.
Caching,
we
expect
things
to
be
transferred
beyond
that.
We
have
signatures
that
exist
over
portions
of
it.
We
have
a
draft
that
you
know
it's
signing
the
whole
thing.
V
V
AD
AD
V
AD
V
So
second
point
is
that
in
a
security
context,
we
almost
always
insist
on
private
information
to
be
transferred
out
of
band,
not
in
the
original
protocol.
So
it's
unclear
to
me
what
the
why
it
is
needed
to
be
in
band
in
DNS
protocol,
as
opposed
to
a
supplemental
bit
of
information
like
how
we
currently
transfer
security
related
information.
Okay,.
U
Well,
first
of
all,
it
smells
what
security
by
obscurity
and
then
we
create
some
kind
of
special
secret
sauce
from
special
resource
record
tapes
have
got
a
special,
significant
meaning
and
that
will
then
determine
the
behavior
of
the
server
and
how
it
then
response
to
queries.
I
think
that's
a
very
bad
idea
and
a
start
of
a
very,
very
slippery
slope.
If
we're
going
to
set
aside
a
verb
types
and
see
these
are
special
significance
and
the
kumbhak
build
by
certain
clients
or
sell
and
serve
those
under
certain
circumstances.
U
I
think
that's
a
very,
very
bad
thing
to
do.
I
think
it
will
keep
very
many
difficult
and
proper,
able
operability
and
operational
problems
if
the
stuff
escapes
into
the
wild.
Now,
yes,
the
maybe
I
need
for
some
candies
can
afford
cost
not
as
much
as
covert
information
but
as
I
find
information
like
that.
That
make
my
better
description
over
here.
But
if
that
information
is
sensitive,
don't
put
in
the
DNS,
the
DNS
is
public.
AA
AA
Listening
to
the
comments
here,
I
think
that
having
some
kind
of
parallel
transferring
structure
may
be
in
invent
a
new
transfer
type
instead
of
normal,
sometimes
grow
incremental
song
traffic
that
that
transfers
parallel
information,
or
we
already
have
the
the
NSC
control
protocol,
which
is
another
method
of
transferring
data,
but
I,
don't
see
it
really.
It
doesn't
feel
right
to
have
it
inside
so.
AD
Ohms
instead
well
catalogs
owns
convey
information
about
a
zone
as
a
whole,
and
in
this
case
we
can,
for
example,
for
notes
record.
We
can
have
a
record
in
the
zone,
guess
what
we
can
have
a
record
in
the
zone,
so,
for
example,
mac-10
dot
is
C
dot
org
and
the
note
stating
that
mac-10
I
see
that
org
is
Evans
computer,
which
catalog
zones
are
a
concept.
AD
Well,
it's
it
would
be
possible
to,
for
example,
transfer
zone,
signing
keys
with
catalog
zones,
because
those
are
those
are
values
that
are
attached
to
a
zone,
but
in
this
case
we
want
to
have
something:
that's
in
the
same
key,
our
key
as
the
zone.
So
if
we
can
have
a
record
in
the
zone
and
a
note
for
this
and
a
note
for
this
specific
record,
so
yeah
in
this
case,
for
example,
for
note
R
or
DHCP
timeout
R,
it's
not
possible
to
do
it
with
catalog
zones.
Q
Paul
Hoffman,
just
since
I'm,
busily
typing
the
minutes,
I
think
that
Peter
said
something
that
many
people
agreed
with
afterwards,
but
didn't
say
they
agreed
with,
which
is.
This
is
an
opportunity
to
create
a
new
zone
transfer
program.
If
people
don't
like
doing
it,
this
way,
which
is
seem
like
a
bunch
of
people
didn't,
but
they
agree
that
there
is
a
use
case
and
might
even
have
extra
use
cases
which
it
seemed
like
a
bunch
of
people
did
a
different
zone
transfer
program.
It
could
be
parallel.
That
only
does
not
so
we
don't.
Q
We
aren't
wedded
to
axfr
and
IX
FR
forever
if
we
can
come
up
with
a
better
way
to
do
it,
and
I
think
I've
seen
better
ways
to
do
this
written
on
eight
boards
for
the
last
ten
or
fifteen
years.
So
maybe
this
is
the
opportunity
to
do
that
at
which
point
in
that
new
transfer,
it's
not
just
zone
transfer,
zone,
information
transfer
or
you
know,
zone
configuration
transfer
as
well
could
include
this
okay.