►
From YouTube: IETF115-DNSSD-20221108-1500
Description
DNSSD meeting session at IETF115
2022/11/08 1500
https://datatracker.ietf.org/meeting/115/proceedings/
A
Welcome
to
dnssd
we'll
start
properly
in
a
few
minutes,
but
meanwhile
please
join
the
meteco.
You
can
use
the
QR
code
or
follow
your
usual
method.
B
There
we
go,
I,
see
it
and,
let's
see
I'm
going
to
Grant
it,
it
might
kick
you
out
and
see
what
happens.
B
B
B
Welcome
to
DNS
service
Discovery,
we
are
I'm
David
and
this
is
Chris
and
we
are
your
friendly
neighborhood
chairs.
Welcome
to
itf115
next
slide.
Please.
B
So
it's
Tuesday
afternoon,
most
of
you
have
probably
seen
the
note
well
and
all
of
you
have
guaranteed
at
least
click
that
to
promise
that
you've
read
it
when
you
registered
so
two
parts
that
I
really
want
to
highlight.
B
The
first
one
is
the
IPR
policy
of
the
ITF
any
contributions
you
make
require
that
you
disclose
patents.
That
you're
personally
aware
of
so
just
note
that
before
you
dock
and
the
other
one
is
our
code
of
conduct.
B
We
have
a
clear
quarter
conduct
at
the
ITF
and
we
want
all
of
our
work
to
be
done
professionally
and
nicely,
and
luckily
that's
never
been
a
problem
in
this
working
group.
So
let's
keep
it
that
way.
Next
slide
as
a
reminder
and
the
itf115
just
like
the
last
one
has
a
mask
policy.
B
I
know
that's
surprising
to
some,
because
people
aren't
wearing
masks
outside
these
days,
but
this
is
the
policy
that
the
community
decided
on.
So
please
wear
a
mask,
with
the
only
exceptions
being
that
you're
actively
speaking
into
a
microphone
as
per
usual.
If
I
see
people
not
wearing
masks,
we'll
do
something
like
over
there.
Please
put
a
mask
on
all
right,
so
these
are
the
some
links
for
folks
that
see
this
later.
I
will
do
the
jabber
relaying.
B
If
you
want
to
say
something
in
the
meet
Echo
chat,
I
can
relay
it
for
you
and
thank
you
Eric
for
taking
minutes.
Much
appreciated.
Can
someone
help
Eric?
So,
where
he's
not
no
you're,
fine,
all
right
cool
thanks
next
slide
here
are
some
useful
links
same
if
you're
logging
in
I
just
want
to
point
out
why
it's
very
important
that
you
all
fill
in
the
blue
sheets.
B
Look
at
how
big
this
room
is.
This
is
the
first
time
that
we're
not
in
a
boom
closet
and
we
can
breathe
it's
amazing.
So
the
more
people
sign
the
blue
sheets,
the
bigger
the
room
we
get
next
time
next
slide.
Please
we
have
our
GitHub
organization,
where
two
of
two
of
our
three
Ted
did.
We
put
the
advertising
proxy
document
in
GitHub
or
not
yet
yeah
all
right
cool.
B
So
two
of
our
adopted
working
group
documents
are
there
out
of
the
three,
the
third
one
soonish,
and
when
we
adopt
future
documents,
it's
becoming
our
more
common
way
of
working
on
them.
It's
pretty
handy
for
making
sure
that
people's
comments
get
addressed
next.
D
B
Speaking
of
our
adopted
working
documents,
a
quick
status
update,
so
the
SRP
stateless
replication
protocol
document
we
finished
working
with
last
call
I
think
it
lasted
for
a
year.
So
let's
try
to
do
better
next
time,
but
thank
you,
everyone
for
the
reviews
and
we
had
a
few
comments.
They've
been
addressed.
We
have
a
few
very
minor
one,
because
Ayana
provided
a
review,
so
let's
get
those
cleaned
up,
but
that
shouldn't
take
long.
Similarly,
the
update
leads
document
which
is
required
for
SRP.
B
The
working
last
call
was
completed.
There
were
some
comments
that
have
been
addressed
and
the
chairs
or
Shepherds
for
the
documents
we
found
a
few
knits
that
should
be
fixed
before
we
send
it
to
the
ASG.
So
we
expect
that
to
happen
pretty
soon
and
then
we'll
click
the
button
for
rid
overlords
to
then
review.
B
The
third
document
is
the
advertising
proxy,
which
we
adopted
last
August
and
hasn't
seen
a
whole
lot
of
love
since,
but
we're
going
to
talk
about
it
some
more
today
and
I
think
some
of
the
discussion
will
lead
to
takes
changes
in
the
near
future.
A
B
And
we
also
have
some
individual
drafts,
so
there's
the
SRP
replication
one
and
the
I
am
blanking
which
about
what
TSR
stands
for,
but
we're
going
to
be
talking
about
them
later.
So
that's
fine
and
the
The
Zone
Discovery
one.
We
were
talking
about
it
for
a
while,
but
it's
expired
now.
So
I
think
that
one's
on
the
back
burner
for
a
bit.
We
have
a
bit
of
documents
that
are
expired,
that
we
just
will
grab
when
we
need
them
next
slide.
B
All
right,
this
is
our
agenda.
For
today
we
have
a
few
conversations
proposed
by
Esco
interaction
between
a
DNS
server
and
a
discover
proxy
when
they're
running
on
the
same.
C
B
Well,
I
guess:
I'm
not
going
to
read
this
off
the
slide
and
then
we're
going
to
talk
about
the
advertising
proxy,
which
is
our
working
group
adopted
document
and
then
we're
going
to
talk
about
individual
drafts
that
we're
considering
adopting
at
some
point
in
the
future.
Does
anyone
want
to
bash
the
agenda.
B
So
you're
saying
doing
an
advertising
proxy
before
the
discussion
because
it
makes
the
slides
easier.
Does
anyone
object
to
that
all
right?
Let's
do
that
then
I
think
that's
the
end
of
our
chair,
slides
right
then
Ted.
Can
you
come
up
for
that
slide
set
please.
D
Okay,
so
I
gave
this
slide.
This
particular
title,
because
when
we
originally
started
off,
the
goal
was
to
have
a
document
that
just
described
what
an
advertising
proxy
was.
But
when
discussion
proceeded
on
the
topic,
it
became
somewhat
clear
that
what
we
actually
really
needed
was
a
document
describing
the
thing
that
does
the
advertising
proxy
function,
which
also
does
a
bunch
of
other
functions,
and
so
that's
why
it's
poorly
named
next
slide.
D
So
motivating
use
case
for
the
advertising
proxy
I'm
just
going
to
give
you
kind
of
a
an
over
a
review
but
I'll
try
to
keep
it
brief.
The
goal
there's
two
motivating
use
cases,
one
is
supporting
stub
networks
and
the
other
is
replacing
mdns
with
DNS,
and
so
these
go.
These
motivating
use
cases
have
slightly
different
needs.
D
Stub
networks,
you
at
least
in
the
current
use
case-
that
we
have
for
stub
networks.
The
stub
Network
itself
is
a
sort
of
Greenfield
environment
and
the
network,
it's
connecting
to
obviously
is
just
a
regular
old
Network.
So
we
need
to
support
different
behaviors
on
these
two
networks
and
we
are
not
assuming
cooperation
for
the
infrastructure
for
replacing
mdns
with
DNS.
D
We
probably
are
going
to
want
cooperation
from
the
infrastructure,
so
that's
a
little
different
and
now
the
advertising
proxy
function,
which
just
to
remind
everybody,
the
advertising
proxy
function,
is
basically
serving
a
DNS
Zone
using
mdns
to
some
link
or
links
next
slide.
D
D
So
one
of
the
modes
is
you've,
got
a
Greenfield
Network,
so
we
control
the
resolver.
We
can
do
anything
we
want
with
DNS.
We
don't
need
an
advertising
proxy
on
that
link
because
there
aren't
any
Legacy
hosts
it's
a
Greenfield
Network,
so
we're
essentially
requiring
that
they
do
DNS
service
Discovery
through
the
resolver
which
pretty
much
every
host
already
can
do
and
importantly
we're
requiring
that
they
register
themselves
using
SRP
so
and
by
the
way.
D
If
they
want
to
do
service
discovery
on
an
adjacent
infrastructure
link,
then
we
need
a
discovery
proxy
for
that.
So
that's
one
mode,
non-cooperating
infrastructure.
This
is
a
case
where
we're
on
the
infrastructure,
we're
providing
service
Discovery
and
the
the
use
case
for
this
is
again
the
the
stub
Network.
So
in
the
stub
Network
we
have
devices
that
are
on
the
stub
Network
that
are
doing
Service
registration
using
SRP.
We
need
to
be
able
to
discover
those
devices
on
the
infrastructure
Network.
The
infrastructure
network
is
not
a
Greenfield
Network.
D
D
The
third
use
case
is
that
we
have
cooperating
infrastructure,
so
infrastructure
is
providing
a
resolver
is
providing
service
registration
protocol.
Somehow
we
haven't
actually
said
how
that's
happening
yet
and
I
don't
think.
This
document
is
where
we
would
say
that,
but
at
least
in
principle
it's
providing
SRP.
D
We
only
really
need
an
advertising
proxy
for
devices
that
that
don't
who
don't
support,
mdns
and
I-
don't
really
know
that
there
are
any
such
devices.
So
we
probably
don't
actually
need
an
advertising
proxy
on
this
network.
D
We
probably
do
require
a
discovery
proxy,
because,
if
we're
having
the
nodes
on
this
network,
do
DNS
service
Discovery
using
DNS
and
not
mdns,
then
they're
not
going
to
do
an
mdns
broadcast
or
an
MDS
multicast
when
they
want
to
discover
a
service,
and
that
means
that
the
poorly
named
advertising
proxy
has
to
do
that
for
them.
D
So
those
are
the
three
modes
so
next
slide.
D
So
so
what
we
actually
need
to
provide
in
the
document
is
a
little
bit
more
than
what
we
originally
set
out
to
provide
and
by
the
way
when
I
say
when
I
describe
all
of
this,
when
we
originally
set
out
to
do
the
advertising
proxy
document,
we
were
just
going
to
describe
the
you
know:
you've
got
an
SRP
service
and
you've
got
an
advertising
proxy.
That's
advertising
whatever
was
registered
with
SRP,
and
that
was
a
very
constrained
set
of
problems.
D
The
reason
that
we
morphed
out
of
that
is
because
an
SRP
server
is
actually
an
authoritative
DNS
server.
It
doesn't
need
to
do
the
advertising
proxy
function.
The
only
reason
we
need
the
advertising
proxy
function
is,
in
certain
cases
like
in
a
a
sub
network
configuration
that's
the
only
way
that
we
can
actually
deliver
what
we're
trying
to
deliver,
which
is
service
discovery
of
hosts
registering
with
SRP.
D
So
that's
why
this
kind
of
morphed
and
I
think
that
I
think
it
morphing
in
this
way
was
a
good
thing,
not
a
bad
thing,
but
obviously
I
encourage
people
to
to
give
feedback
if
they
disagree.
So
what
we
need,
assuming
that
we
accept
this
sort
of
larger
scope
is
we
need
an
SRP
registrar.
D
It
accepts
SRP
registrations
from
whatever
networks.
It's
doing
that
on
it's
going
to
update
a
DNS
zone,
so
SRP
is
basically
just
DNS
updates,
it's
an
updated
DNS,
so
it
may
update
more
than
one
DNS
Zone.
That's
something
we
need
to
think
about.
D
D
The
second
thing
we
need
is
an
advertising
proxy,
and
the
point
of
that
is,
if
we're
on
a
network
where
we
have
clients,
basically,
we
don't
have
control
of
the
resolver.
D
E
D
D
We
need
this
in
two
cases.
We
need
this
both
for
the
Greenfield
case,
the
stub
Network
case,
where
essentially
the
stub
router
controls
the
stub
Network
and
can
act
as
a
DNS
resolver,
and
so
it
can
do
all
these
cool
things
and
also
for
the
use
case
where
we're,
where
we're
doing
DNS
service
Discovery
using
DNS
instead
of
multicast
DNS
on
some
future
new
network
that
we
haven't
really
talked
about
yet.
D
So
this
is
a
little
bit
of
scope
creep,
and
it
may
be
that
we
don't
actually
want
to
solve
that.
The
reason
that
it's
on
there
is
because,
since
we
need
it
for
the
stub
Network
anyway,
it
doesn't
really
it's
not
really
any
different.
D
E
D
Know
ibm.com
or
whatever
has
to
provide
Discovery
proxy,
so
that
say
you're
on
the
sub
Network,
you
can
discover
devices
that
are
on
the
infrastructure,
Network
or,
if
you
have
a
you
know
like
like,
if
we
ever
wind
up
addressing
the
home
net
use
case
again,
this
would
be
ideal
for
a
setup
in
a
home
net
so
and
it
has
to
be
authoritative
for
the
SRP
Zone
and
that's
just
an
authoritative,
DNS
server.
So
there's
no
there's,
no
there's
no
advertising
proxy
there.
D
So
the
current
document
state
actually
talks
about
most
of
this
stuff
still
is
called
the
advertising
proxy
document
I'm
not
really
sure
what
to
call
it,
but
it
talks
about
the
advertising
proxy
function,
the
full
service
resolver,
it's
going
to
be
proxy,
authoritative
server,
it's
probably
not
sufficiently
detailed.
At
this
point
we
probably
need
more
text,
but
but
it
basically
covers
all
of
these
functions
next
slide.
D
So
the
questions
that
Esco
was
asking.
We
had
a
bunch
of
questions
that
were
on
the
agenda
and
I
lumped
these
into
this
presentation,
because
they're
actually
relevant
to
this
blob.
Whatever
it
is,
it's
not
really
a
discovery,
but
not
really
an
advertising
proxy
anymore,
but
but
it's
relative
it's
relevant
to
this
blob,
because
this
blob
is
doing
the
thing
that
that
Esco
was
asking
about
so
the
first
question
that
Esco
was
asking-
or
at
least
the
first
one.
D
That's
on
the
agenda
is
that
RC8
76
8766
is
talking
about
the
discovery
proxy
as
an
authoritative
server
and
I
I
I'm,
somewhat
contextualizing.
What
Esco
asked,
because
there
was
a
whole
bunch
of
context
that
came
with
the
question
that
wasn't
actually
in
the
question.
But
so
basically
the
idea
is:
we've
got
this
thing.
D
That's
this
blob,
that's
both
an
advertising
proxy
and
a
discovery
proxy
and
a
DNS
server,
and
we're
going
to
ask
a
question
in
a
specific
Zone,
and
this
is
something
the
thread
spec
does
and
that
also
the
the
Discovery
broker
spec
that
Stuart
and
I,
mostly
Stewart,
did
a
couple
years
ago.
The
discovery
broker
respect
talks
about
this.
D
The
idea
is
basically
you've
got
a
constrained
client,
you
don't
want
to
do
like
a
million
queries
because
queries
consume
power,
and
so
you
wanted
to
ask
one
question
and
based
on
the
answer
that
question,
it
should
have
the
information
that
it
needs
to
either
ask
clarifying
questions
if
necessary,
but
ideally
just
just
it's
got
all
the
information
it
needs
in
order
to
access
some
service
that
it's
looking
for,
and
so
so
the
idea
in
the
thread
spec.
It
says.
D
If
you
do
a
query
to
default.service.arpa,
then
you
will
get
answers
back
for
SRP
and
you
know
we
don't
actually
support
any
local
DNS
browsing
zones,
but
if
there
were
then
presumably
good
answers
for
those,
but
so
SRP
and
the
discovery
proxy,
those
both
come
back
from
the
same
domain,
and
so
those
might
be
actually
the
the
information
in
those
domains
might
be
in
different
might
be
subdomains
of
different
domains.
But
when
you
do
the
query,
the
the
the
the
Discovery
proxy
blob.
D
Sorry,
this,
the
advertising
proxy
blob,
is
going
to
sort
of
figure
out
which
zones
to
do
queries
in
order
to
get
answers
for
you
and
then
return
stuff
to
you
and
one
of
the
questions
about
that
is
so
RFC
8766
says
you
know
when
you
get
a
query
you're
supposed
to
wait
six
seconds
before
you
decide
that,
there's
nothing
that
there
are
no
answers,
and
so
in
this
case,
where
we
have
this
hybrid
Zone,
that's
both
partially
an
authoritative,
DNS,
Zone
and
also
partially
the
discovery
proxy.
D
When
do
we
send
an
answer
and
so
I
think
the
answer
to
this
is
so
the
first
of
all
we,
we
didn't
really
talk
about
blobbing
zones
together
in
the
in
the
current
document,
and
so
we
kind
of
need
to
to
specify
that
but
I
think
the
answer
to
this
and
tell
me
if
this
sounds
dumb.
D
Esco
is
if
we
have
zero
answers
in
in
any
zone,
for
that's
populated,
like
a
DNS
Zone,
where
we
don't
have
to
wait
to
get
the
answer,
then
we
want
to
wait
until
we
either
do
or
do
not
get
an
answer
from
the
discovery
proxy.
D
F
D
D
F
D
D
I
mean
our
general
assumption.
I
think
is
that
if
the
client
really
wants
to
get
a
comprehensive
set
of
answers,
they
should
be
doing
DNS
push,
not
not
regular
DNS
UDP
queries,
so
yep
yeah.
So
let's
go
to
the
next
slide.
I
think
you
asked
a
couple
more
questions.
Oh
actually,
no
so
I'm
gonna
make
you
walk
because
it
looks
like
I
interleaved
your
questions
with
some
slides,
so
I
just
wanted
to
talk
about
the
discovery
broker
because
it's
relevant
to
this.
So
the
idea
with
the
discovery
broker
was
what
I
just
described
earlier.
D
You
query
for
a
Singleton:
you
get
answers
from
multiple
zones,
it's
less
work
for
the
client.
We
didn't
talk.
The
document
didn't
really
talk
about
mixing
answers
from
Discovery
proxies
and
authoritative
servers,
but
you
know
that's
not
a
bad
thing,
and
so
we
had
a
little
bit
of
a
discussion
about
this
at
lunch,
but
but
basically
in
order
for
us
to
support
this
function
in
the
blob.
That
is
no
longer
a
an
advertising
proxy
there's,
probably
an
acronym.
E
D
But
anyway,
The
Blob
needs
to
be
able
to
do
this
thing
that
that
is
described
in
the
discovery
broker.
Document
Discovery
broker
document
is
a
very
general
document
and
I
think
you
know
we
talked
what
we
talked
about
at
lunch
was.
Maybe
we
could
just
like
pull
the
bits
of
it,
that
we
really
care
about
out
and
put
them
into
the
advertising
proxy
blob
document,
and
because
otherwise,
we're
going
to
have
to
add,
like
we've,
got
a
whole
bunch
of
documents.
D
D
All
right
so
now
we're
getting
back
to
esco's
question.
So
another
question
that
Esco
asked
is
like:
what's
the
right
name
for
this
Zone
thread
is
using
default.service.arpa,
but
actually
that's
not
really
even
I
mean
there
are
a
bunch
of
different
things
we
might
want
to
be
able
to
query
right.
Default.Service.Arpa
and
thread
is
currently
being
used
to
just
say.
Give
me
any
service
of
this
type
anywhere.
That
is
local.
Sorry.
B
I'm,
just
thinking
before
we
jump
into
esco's
second
question:
maybe
open
up
the
floor
in
case
other
folks
had
further
comments
on
the
previous
one.
It
sounds
like
you,
two
were
in
agreement,
but
I
just
want
to
make
sure
anyone
else
has
an
opportunity.
Sure
I'll,
also
relay
Jonathan
Hui
in
the
chat,
was
saying
Chris
Juan
to
the
proposed
answer
of
immediately
respond.
If
there
is
an
answer,
otherwise
wait
for
Discovery
proxy
okay,
so
that
that
sounds
like
we
have
agreement
there.
B
G
B
G
D
D
Another
question
we
might
want
to
be
able
to
answer
is:
is
there
any
service
of
this
type
on
the
subnet
I'm
on
right?
My
current
link
and
another
question
we
might
want
to
ask-
is:
is
there
any
service
of
this
type
on
the
adjacent
infrastructure
link
for
a
stub
router
or
for
if
we're
on
a
stub
Network?
D
It's
not
clear
to
me
that
we
need
necessarily
need
to
be
able
to
ask
all
of
these
questions,
but
these
are
certainly
questions
that
occur
to
me
that
we
might
want
to
be
able
to
ask
so
I
think
the
working
group
needs
to
do
a
little
bit
of
thinking
about
how
we
want
to
approach
this.
The
other
thing
is
so
I
think
pretty.
Clearly
we
need
to
have
a
a
a
name
for
this
link
and
that's
sort
of
a
future
thing.
D
So
I
don't
know
that
we
necessarily
need
to
solve
that
in
this
document,
but
I'm
mentioning
it
now
because
I'd
like
just
people
to
be
aware
that
that's
something
we
need
to
think
about.
But
the
other
thing
is
for
SRP
suppose
you
have
multiple
stub
routers
that
are
connected
to
multiple
stub
networks
that
are
attached
to
the
same
adjacent
infrastructure
link.
D
D
Another
way
to
deal
with
it
is
to
have
each
stub
Network
have
its
own
set
SRP
data
set.
Currently,
the
SRP
replication
draft
assumes
that
each
sub
network
will
have
its
own
data
set
and
so
and
then
the
data
sets
could
just
be
like
sort
of
layered
into
a
single
zone,
but
then
you
get,
then
you
run
into
name
Collision
problems
which
become
difficult,
and
so
that's
probably
not
the
right
thing
to
do.
D
It's
probably
better
to
to
have
them
be
separate
zones,
and
so,
if
you're
going
to
do
that,
then
you
need
a
way
to
figure
out
what
the
zones
are
called.
D
So
that
was
that
document
that
that
we
were
talking
about
earlier.
That's
that's
been
sort
of
pushed
back,
I
don't
know
if
we
need
to
answer
this
question
for
the
advertising
proxy
document,
but
there's
a
case
to
be
made
that
we
do
so.
This
is
just
something
we
need
to
think
about.
D
I
I,
don't
know
the
answer
to
that
question
yet,
but
I
think
I
think
we
need
to
think
about
this
and
I.
Don't
think
we'll
be
ready
to
publish
the
document
until
we've
at
least
either
answered
the
question
by
saying:
here's
how
you
do
it
or
answered
the
question
by
saying.
Actually
we
really
don't
need
to
answer
this
in
this
document.
D
F
Okay,
yeah
I
was
thinking
about
this.
What
you
said
with
multiple
SRP
servers,
for
example
yeah.
It
could
could
be
that
each
one
of
them
has
their.
You
know
separate
Zone,
let's
say
for
the
registration,
but
I
think
there
was
this
RFC
that
that
defines
home.arpa.
So
it's
RFC,
8375
I,
think
the
way
I
read
that
it
was
supposedly
to
mean
the
scope
of
the
entire
home
network,
I'm,
not
sure.
D
F
Is
authoritative
for
home.arpa
yeah
that
could
work,
but
I
had
the
feeling
that
well,
this,
this
name
at
least,
is
already
reserved,
so
it's
already
defined
by
ITF
to
cover,
let's
say
the
entire
home
and
you're
yeah.
My
neighbor
can
then
have
the
same
domain
name,
but
then
should
be
a
different
zone
right
because
it's
the
neighbor.
So
it's.
D
F
Ideally
would
not
conflict
that
way,
so
that
yeah,
that's
something
that's
at
least
defined
and
and
what
you
mentioned
is
yeah,
also
being
able
to
do
that
more
granularly.
So
if
you
have
multiple
stop
networks,
then
you
could
yeah.
You
could
ask
for
services,
maybe
on
stop
Network
one
or
two
or
both.
D
F
You
might
need
new
names
for
that
so
and
I
don't
do
not
maybe
follow
what
you
mean
with
this
link.
Isn't
that
dot
local
already
yeah
so.
A
D
F
Okay-
and
you
could
could
have
something
also
for
in
identifying
all
the
stuff
networks,
plus
the
adjacent
infrastructure
link
right.
D
D
Yeah
so
I
mean
in
thread
right
now
we're
using
default.service.arpa
for
that,
but
we
aren't
actually
doing
it
in
a
very
smart
way
at
the
moment.
So,
for
example,
if
you
have
multiple
thread
networks
that
are
connected
to
the
same
infrastructure,
then
it's
not
clear
to
me
that
those
queries
are
actually
going
to
do
what
you
want.
D
We're
going
to
have
basically
we're
going
to
have
multiple
advertising
proxies
with
multiple
thread
networks,
and
so
the
advertising
proxies
are
probably
all
going
to
advertise
the
set
of
services
that
they
have
on
the
infrastructure
link,
which
is
going
to
be
a
big
pile.
D
So
they
are
essentially
going
to
be
mashed
into
the
dot
local
Zone
in
that
sense.
But
is
that
really
what
we
want
to
do?
I
don't
know.
E
Stuart
Josh
from
Apple,
just
very
briefly,
coming
to
answer
the
previous
question
about
whether
to
use
dot
local,
it's
not
really
a
difficult
question.
It's
just
one.
We
have
to
answer
as
currently
written
RFC
6762
says
very
clearly.
If
a
name
ends
in
dot
local.
That
means
you
look
it
up
with
a
multicast
query
to
a
particular
V4
or
V6
link
local
multicast
address.
E
E
H
E
D
I
mean
one
one
additional
slate
wrinkle
to
that
discussion
is
that
if
you
have
a
multi-link
home
network,
then
dot
local
means
a
different
thing,
depending
on
which
link
you're
connected
to,
and
in
this
sense
it
would
probably
be
better
to
have
something
that
doesn't
have
a
different
meaning,
depending
on
which
link
you're
connected
to
that's
the
main
argument
for
not
using
dot
local.
D
To
back
to
the
question
of
home.arpa,
you
probably
got
a
little
bit
of
pushback
for
me
on
home.orpo,
and
the
reason
for
that
is
because,
when
we
were
when
we
were
working
on
this
in
HomeNet,
we
actually
had
this
idea
that
we
were
going
to
have
multiple,
a
multi-link
home
network,
which
we
actually
you
know
I
mean
we
came
up
with
a
sort
of
a
solution
for
that,
but
it's
not
ever
been
to
it's.
Not
ever.
D
You
can't
buy
it
and
it's
not
clear
that
it's
highly
Deployable,
but
essentially
the
idea
was
that
each
link
in
the
home
network
would
be
a
subdomain
of
home.arpa,
and
so
so
in
a
sense
yes,
you'd
use
home.arpa,
but
you
you'd,
subdivide
it.
You
wouldn't
just
have
everything
all
be
in
one
Big
Blob.
D
The
other
issue
with
home.orpa
is
that
it's
only
for
homes.
So
if
we're
using
this
for
for
a
commercial
environment,
then
using
the
name,
home.orpa
seems
wrong
right.
I,
don't
know
that
it's
actually.
F
Maybe
this
question
yeah
I
was
just
wanted
to
ask
a
question
about
default.services.orpa
because
that's
defined
by
the
sap
draft
as
a
kind
of
Alias
that
should
be
mapped
to
something
else
and
I.
Think
then
the
question
is
okay.
What
is
this
something
else
by
default
if
it's
not
configured
by
an
administrator
right.
D
F
F
D
D
F
B
Good
David
scanassi
speaking
as
an
individual
here
so
yeah
I,
was
going
to
say
pretty
much
the
same
thing
that
Ted
covered
about
home
narpa.
It
sounds
attractive,
but
it
comes
with
a
whole
lot
of
baggage
that
doesn't
necessarily
work
well
here
and
coming
up
with
new
names
is
cheap,
like
this
is
a
standards
track
document.
It
needs
approval
from
the
internet
architecture
board
I'm,
one
of
them
like
that,
won't
be
a
problem.
B
The
Omni
for
for
the
question
of
potentially
using
dot
local
here,
I
guess.
My
question
is
like
any
time
when
we
have
the
choice
of
updating
and
re
like
an
old
RFC
to
reuse,
something
or
defining
something
new.
For
me,
the
distinguishing
factor
is
if
this
name
shows
up
on
an
old
box.
What
do
we
want
to
happen?
B
Do
we
want
it
to
try
on
the
local
interface
or
do
we
wanted
to
just
say,
I,
don't
know,
or
if
it's
something
do
we
want
it
to
send
it
and
in
an
Ideal
World
some
box
along
the
way
will
be
like
oh
I,
know
what
to
do
with
this
and
we'll
know
that
it's
an
old
client
and
send
that,
and
so
my
gut
feeling
here
is
what
we
want:
is
the
old
device
to
send
it
over
unicast,
not
only
multicast
on
the
local
link
and
that
kind
of
points
over
not
local
or
maybe
I'm,
not
quite
understanding
what
we
want.
D
D
Yeah,
so
that's
a
good
point
and
in
a
sense
what
that
means
is
that
so
we
already
support
doing
Legacy
service
Discovery
pretty
much.
Everybody
supports
that
Windows,
Mac,
yeah,
Android,
yeah,
I,
think
Linux,
also,
but
I'm
not
sure,
but
I
mean
Android's
using
linuxy
things,
so
that
sort
of
suggests
that
it
does
support
it.
So.
B
D
So
the
other
thing
that's
a
little
bit
challenging
about
using
dot.
Local
is
if
you've
got
a
device
with
multiple
interfaces.
Then.Local
means
a
different
thing
on
a
different
interface,
and
you
know
we
support
that
on
the
Mac
and
on
you
know,
devices
Apple
devices
that
have
multiple
interfaces
by
returning,
both
the
information
and
the
interface
that
we
got
it
on,
but
that's
an
additional
complication.
C
Yeah
everything
no
special
ed
on
this
one
come
back
on
the
default.service.apa.
This
zone
is
not
in
the
Ayana
registers,
so
thread
if
it's
using
it
sorry,
but
please
try
to
flow
the
procedures
and
I
would
have
advised
not
to
use
dot
RPA
because
DOTA
Pi
is
a
real
zone.
So
if
the
request
leaks
also
the
domain,
it
will
go
to
real
actual
in
a
server
that
will
resupport
this
load.
D
Yeah,
so
the
reason
we
use
default.service.arpa
is
because
we
anticipated
the
SRP
document
getting
that
allocation
and
the
way
that
it
currently
works
for
like
home.arpa
and
the
way
we
intend
for
it
to
work
for
default.
Service.Arpa
is
that
that
will
go
to
the
black
hole
servers,
and
so
you
know
yeah
you'll
get
a
root
query
asking
for
a
real
good.
You
know
our
the
arpa
server
will
get
a
query
asking
for
the
authoritative
information
about
arpa,
but
in
principle
you
know
it's,
it
should
be.
It
should
be.
D
D
Yeah
I
mean
essentially
what
what
you're,
what
it
sounds
like
you're
arguing
for
Eric
is
the
same
thing
that
we
were
arguing
for
when
we
originally
asked
for
DOT
home
and
we
didn't
get
dot
home,
because
the
IAB
decided
that
it
wasn't
really
worth
the
trouble
of
having
that
argument.
C
With
icann
yeah,
but
actually
at
the
bare
minimum
right
register
this
Zone
before
it's
using
actual
code.
B
Might
be
too
late
for
that
one
good
advice,
so
just
thanks
for
the
answer
Eric.
Then
it
becomes
a
trade-off
for
instead
of
hitting
the
r
press
server,
you
hate
you
hit
the
root
and
I
think
that's
worse.
Just
to
give
you
an
example:
Christian
uitma
did
a
presentation
quite
a
few
moons
ago,
rightfully
accusing
Chrome
of
being
the
biggest
botnet
on
the
internet,
because
Chrome
had
a
feature
that
said
some
random
DNS
queries
and
it
turns
out.
B
It
was
responsible
for
90
of
the
load
on
the
root
servers
and
the
root
server
operators
were
pretty
mad.
We
turned
that
off.
So
it's
a
trade-off
and
I
think
my
personal
take
again.
No
hats
would
be
to
to
hit
arpa
more
to
than
the
root.
A
So
sure
you
should
have
joined
the
queue
but
I
recognize
you
were
there
before
last.
So
oh
go
ahead.
E
You're
right,
I
I
should
have
done.
I
just
ran
up
to
answer,
Eric's
point
I,
absolutely
right.
Eric,
the
Ayana
registry
exists
for
a
reason,
it's
sort
of
an
accident
of
history
in
terms
of
how
different
things
progressed
at
different
rates.
If
we
decide
to
do
something
else,
I
think
we
can
change
this.
We
can
ship
software
updates,
so
we're
certainly
not
resistant
to
doing
that,
and
you
know,
but
I'll
mention
this
for
everybody
in
the
room
who
doesn't
know
there
is
a
meeting
tomorrow.
E
It's
listed
on
the
ietf
website
under
the
side
meetings,
not
on
the
main
agenda.
There
is
a
meeting
that
Paul
Hoffman
has
put
together
to
discuss
special
use
domain
names
and
how
they're
allocated
and
managed
he
has
written
a
very
short
internet
draft.
It's
only
about
eight
pages,
so
I
plan
to
be
at
the
meeting
anybody
else
who's
interested
in
this
please
come
along
because
I,
don't
I,
don't
know
exactly
what
Paul
is
proposing.
He
did
make
it
clear.
He
wants
people
to
read
the
draft
if
they
show
up.
E
So
it's
not
very
long,
but
everybody
in
this
room
has
got
an
interest
in
that
I'm
letting
you
know
that's
happening
because,
unsurprisingly,
I
think
having
names
that
have
certain
defined
properties
is
a
useful
thing.
That's
not
something.
Everybody's
always
agreed
on
and
there'll
be
more
discussion
on
that
tomorrow
and.
B
H
Thank
you,
Laura
sliemann,
from
netnode.
With
regards
to
the
root
name
servers.
The
the
the
Chrome
issue
is
rather
different
from
what
you're
discussing
here
I
believe,
because
the
Chrome
issue
was
that
there
was
any
random
top
level
domain
queries
which
couldn't
be
cached
by
the
resolvers,
which
meant
that
there
was
no
delegation
that
could
take
the
hit.
That's
not
the
case
that
we're
talking
about
here
so
so
this
is
different
and
the
arpa
servers
are,
as
far
as
I
know,
identical
to
the
root
name
servers.
H
Names
but
not
different
documentaries,
it's
going
to
hit
the
same
machines,
but
in
the
future
we
now
have
the
option
of
delegating
that
elsewhere.
But
again,
the
random
thing
is
the
big
issue
having
talking
about
things
that
that
are
either
can
be
returned
as
negative
answers
and
X
domains,
which
can
then
be
cached
or
even
preferably,
a
delegation
that
can
be
cached
is,
is
of
less
concern.
H
I
would
say
for
for
at
least
for
me
as
a
root
name
is
server
operator
soon
for
the
others,
but
this
is
an
ongoing
discussion
in
several
for
us.
So
so
please,
listen
in
and
and
have
this
this
talked
about,
and
you
might
even
want
to
consider
having
a
chat
around
this
specific
General
issue
with
the
the
DNS
directorate
yeah
thanks.
D
Next
slide
or
yeah,
we
got
it
good.
So
Esco
also
asked
the
question:
what
about
suppression
link
local
addresses
because
RFC
6762
says
don't
and
I
think
the
answer
to
that
is
actually
straightforward.
Rc
6762
is
is
about
mdns
mdns
is
single
Link
Link
local
is
always
valid
on
the
local
link,
therefore
suppressing
it
would
be
bad
because
actually
you'd
prefer
that
they
use
the
link
local
address
because
that's
not
going
to
go
away
during
a
renumbering
or
something.
D
F
Yeah
and
just
I
think
the
answer
is
clear.
At
least
I
was
think
thinking
the
same
so
use
the
link
local
address,
because
the
RFC
says
okay,
put
in
all
your
addresses
that
you
have
basically
yeah
yeah
I,
think
the
question
was
smaller
to
confirm
this
basically
well
I
think
it's
been
confirmed
by
you
now
yeah.
You
know
the
question
is
well
what,
if
we
have
some
implementations
around
like
open
source
implementations
that
I'm
not
doing
it
correctly?
F
D
D
Yeah,
that's
a
huge
problem.
There's
been
discussion
about
this
is
avahi
he's
talking
about,
there's
been
discussion
about
adding
more
maintainers
for
avahi
and
I
think
that's
happening.
Leonard
pootering
is
also
talking
about
putting
this
functionality
into
systemd,
which
would
be
terrible,
but
hopefully
even
if
that
does
happen,
the
avahi
work
will
continue
because
there
are
people
interested
in
it.
There's
like
a
huge
number
of
pull
requests
in
the
ovahi
GitHub
repo.
D
E
Stuart
chashire
a
quick
comment
on
this
topic
that
comes
up
a
lot
about
suppressing,
linked
local
addresses
or
suppressing
other
kinds
of
addresses
when,
when
we're
using
an
advertising
proxy
to
make
thread,
devices
visible
on
Wi-Fi,
the
thread
link
local
addresses
are
clearly
not
reachable
from
Wi-Fi.
It's
a
different
link.
E
There
are
other
use
cases
like
as
we
move
into
some
of
the
stuff
you're
talking
about
of
using
just
on
pure
Wi-Fi
migrating
away
from
multicast
towards
more
unicast
there.
You
might
be
discovering
things
that
are
actually
on
the
same
link,
so
we
need
to
think
carefully.
My
preference
is,
give
the
client
all
the
addresses
and
let
the
client
pick
I
know.
Other
people
have
a
different
view,
which
is,
if
we
think
an
address
might
not
work
for
the
client.
E
We
should
pre-filter
it,
so
the
client
doesn't
get
confused
and
I
know
there
are.
E
D
I
mean
I
think
the
one
thing
that
I
would
say
is
kind
of
pretty
important
here
is
to
not
make
constrained,
devices
do
happy,
eyeballs
and
but
that
said,
I
mean
I.
Think
I
agree
with
your
with
your
basic
Point
here
and
personally
I'm
inclined
to
say
that,
like
the
the
the
SRP
registrar
ought
to
be
able
to
handle
this,
but
we've
had
discussions
about
this
and
it
sort
of
depends
on
where
the
SRP
registrar
is.
D
If
it's
in
a
stub,
Network
router,
then
it
knows
that
the
the
update
came
from
a
particular
link,
and
so
it's
pretty
easy
for
it
to
decide
whether
or
not
to
to
to
leave
out
the
link
local
address.
But
let's
say
you've
got
a
home
router
that
supports
SRP
and
is
advertising
it
on
the
link.
D
In
that
case,
and
and
as
in
that
case,
the
thread
border
routers
would
actually
defer
to
the
to
the
main
SRP
server
they're,
the
main
SRP
Server
doesn't
really
know
which
networks
you
know
it
doesn't
know
for
any.
Given
query
whether
the
link
local
address
is
going
to
work
or
not,
and
so
having
it
make.
The
distinction
in
that
case
is
hard,
but
yeah
having
the
having
the
having
a
constrained
device
make.
That
decision
is
also
kind
of
chancy
anyway.
Next
slide.
B
Hold
on
sorry,
I'm,
David
Crosby
in
the
queue,
no
hats,
just
Happy,
eyeballs,
Enthusiast
I,
think.
Another
aspect
here
is:
when
you
send
a
DNS
response.
You
have
control
over
the
ordering
of
the
addresses
and
I
think
like
in
in
a
scenario
where,
like
you're
talking
to
an
iPhone,
the
iPhone
has
a
happy
eyeball,
stack
and
I.
B
Think
the
high
the
iPhone
would
be
happier
to
get
all
the
addresses
and
just
keep
trying,
but
you're
right,
there's
an
embedded
device,
that's
not
going
to
implement
that,
and
but
what
that
device
is
going
to
do
is
most
likely
pick
the
first
one,
because
at
the
end
of
the
day,
like
I
was
looking
at
6724.
You
know
how
you're
supposed
to
order
your
addresses.
Some
of
it
is
like
avoid
unusable.
Well,
I,
don't
know
that
this
link
local
is
unusable.
B
I,
don't
know
that
it's
a
different
rank,
so
I
think
we
might
be
able
to
get
out
of
it
with
like.
You
know
your
Nuance
simple
it
and
you
know
been
playing
with
the
ordering.
That's.
D
A
good
suggestion,
yeah
I
mean
one
thing
to
bear
in
mind-
is
that
it's
a
bit
Terra
Incognito
here,
because
we're
used
to
mdns
doing
this
and
in
the
mdns
case
it
improves
things,
but
we
don't
know
what
it
would
look
like
in
the
non-mdns
case.
But,
as
you
say,
if
we,
if
we
are
clever
about
how
we
order
things,
it
probably
would
be
fine.
G
Okay,
Mark
Andrews.
What
we
really
need-
and
we
keep
coming
across
this-
is
to
actually
get
rid
of
quad.
A
and
put
in
scoped
quote
a
scope.
The
dresses
actually
give
and
address
bits,
and
a
name
and
the
name
identifies
the
link
and
the
ra
has
link
name
in
it,
and
then
devices
can
look
at
the
RAS
and
filter
everything
every
link,
local
address,
which
does
not
match
what
the
ra
is
saying
is
the
name
of
this
link.
G
I've
floated
this
a
couple
of
times
on
DNS
and
V6.
Ops
I
think
it
was
before
16,
but
we
keep
coming
across
this
problem.
We
we
can
do
this
with
with
a
record
as
well
for
those
that
the
tena
for
roughly
1980
and
interesting
things
like
that.
It
allows
you
to
put
your
addresses
in
the
DNS
and
have
the
end
device
make
sensible
decisions
about
what
addresses
are
reachable
or
theoretically
reachable
by
looking
at
us
looking
at
a
name.
We
have
a
method
of
naming
things
which
is
unique.
G
D
G
D
Two
things
about
that:
one
is
I'm,
not
convinced
that
that
having
a
new
record
is
the
right
solution
to
this.
Maybe
the
discussion
we
were
having
earlier
about
how
to
name
links
was
more
the
solution
to
this,
at
least
in
this
case,
I'm,
not
saying
that
you're
wrong
in
general,
but
but
we
might
be
able
to
do
something
another
form
of
nuance
by
just
having
the
name
encode,
the
the
link
name.
The
other
thing,
though,
is
that
naming
links
is
actually
a
really
hard
problem.
G
G
D
B
Gonna
jump
in
his
chair
like
this
sounds
like
an
interesting
proposal,
but
it
is
that
it
is
definitely
not
in
scope
of
the
DNS.
B
That's
fair,
I
think
but
I
I
think
look
I'll.
Let
you
sync
up
with
our
formidable
ID,
who
might
be
able
to
pick
which
working
group
would
be
the
best
place
to
discuss
this
or
you
know
a
draft
in
dispatch.
B
But
I'm
gonna,
no,
and
so
so
I'm
gonna
say
we
move
on
also
as
a
time
check.
The
chairs
only
booked
an
hour
for
this
meeting
this
time.
Unfortunately,
well
because
all.
D
D
Okay,
so
basically,
this
is
a
list
of
things
that
I
think
we
need
to
discuss
like.
How
are
we
gonna?
Do
the
reserve
note
domain
thing?
How
do
we
do
the
suppression
of
Link
local
addresses
and
do
we
do
the
discovery?
Do
we
match
the
discovery
broker
and
advertising
proxy
documents
together?
I
think
we
should
probably
discuss
that
offline.
Given
the
amount
of
time
we
have
so
I.
Think
that's
probably
my
last
slide
is
there
more
on.
D
B
D
Is
a
long
deck?
Actually
it's
not
that
long.
So
next
slide.
So
basically,
the
the
goal
here
is
is
reliable,
SRP,
authoritative
service,
when
you
don't
have
infrastructure
support,
so
you
don't
have
an
authoritative,
DNS
server.
D
Next
slide,
I'm
really
going
to
rush
through
this
because
of
our
time,
so
we're
assuming
that
SRP
requesters,
which
is
to
say
things
that
are
advertising
using
SRP,
have
a
way
to
secure
securely
identify
themselves.
That's
part
of
the
SRP
protocol,
we're
assuming
that
any
individual
SRP
requester
at
any
particular
time
is
updating
exactly
when
SRP
registrar
might
pick
a
different
one
later,
but
at
any
given
time
it's
only
doing
one,
and
so
we
can
use
the
time
of
update
as
a
way
to
disambiguate.
D
If
we
have
two
pieces
of
data
about
the
same
host,
because
we
know
it's
the
same
host
and
we
know
what
time
we
got
the
data,
so
the
source
of
authority
is
the
requester,
and
so
we
don't
need
to
do
any
fancy
DMS
dbms.
So
that's
basically
the
pitch
for
SRP
replication.
An
SRP
replication
allows
us
to
just
completely
lose
an
SRP
server
without
losing
the
contents
of
the
zone
as
long
as
one
server
survives,
whatever
event
drop
the
other
one,
then
we're
good
next
slide.
D
So
we
got
two
documents
about
this.
One
is
the
SRP
replication
protocol,
one
is
the
mdns
TLs
TSR
terminating
stairways?
No
wait!
I,
don't
know
if
anybody
got
that
joke.
So
the
the
time
since
registered
document
which
allows
us
to
prevent
temporary
conflicts
next
slide
so
replication
protocol
spec
is
in
pretty
good
shape.
There's
been
several
implementations.
B
To
jump
in
as
chair
here,
Ted
the
we
had
talked
about
this
and
we
were
waiting
on
like
progressing
the
active
documents
before
adopting
this,
but
since
we
have
two
documents
almost
on
the
way
to
Eric's
plate,
we
think
the
working
group
has
the
bandwidth
for
this
one
now
so,
and
especially
like
clearly
there's
interest,
so
we're
probably
going
to
hold
an
adoption
call
pretty
soon,
but
maybe
actually
I'll
open
in
the
floor.
Briefly,
if
someone
is
opposed
to
adoption
here
can
come
and
explain
why?
B
D
B
And
especially
when
you
see
them,
let
us
know
if
you
think
they're
a
barrier
to
adoption.
The
the
gut
feeling
I
have
I
got
was
that
there
were
issues
that
we
could
resolve
as
a
working
group
after
adoption
and
that's
the
best
place
to
do
it.
So
yeah.
D
D
Yeah
so
TSR
quick,
elevator
pitch
when
an
SRP
update
happens,
the
SRP
server
publishes
new
data
replicates
the
data
of
the
other
replication
peers.
But
before
that
replication
has
happened,
a
conflict
occurs
because
we're
publishing
new
data
that
conflicts
with
the
old
data
and
mbns
assumes
the
old
data
is
more
correct
than
the
new
data,
which
is
the
exact
opposite
of
what
we
want
for
a
proxy.
D
So
the
goal
of
TSR
is
to
prevent
these
sorts
of
conflicts
and
also
to
prevent
conflicts
when,
for
some
reason,
SRP
replication
has
has
broken
down,
hopefully
temporarily
and
so
we're
we
might
actually
be
publishing
stale
data.
We
want
to
kill
the
stale
data,
not
the
new
data,
so
next
slide.
D
So
yeah,
so
the
solution
is
just
get
rid
of
the
incumbent,
authoritative
assumption,
and
this
is
done
by
adding
a
new
record
per
name
to
the
to
the
mdns
message,
and
so,
if
we
have
something,
that's
publishing
a
service
that
is
not
a
proxy.
It
just
doesn't
do
this,
and
so
it
gets.
The
old
behavior
only
proxies
get
the
new
Behavior
next
slide.
D
We
have
an
implementation.
The
document's
been
updated,
it'd
be
nice
to
get
a
second
implementation
and
obviously
we'd
really
love
to
have
people
in
the
working
group.
Read
it
and
see
if
it
makes
sense
to
them
and
see
if
they
can
spot
any
mistakes,
because
we
certainly
made
mistakes
in
the
first
version
of
the
draft.
Oh
my
god,
so
therefore
we'd,
like
the
working
group
to
drop
the
doc,
adopt
the
document.
B
So,
first
off
wow,
you
got
through
all
the
slides
in
five
minutes.
It's
well
done
so
this
one,
so
we
I
think
we
have
the
bandwidth
as
well.
The
only
slight
concern
we
see
is
that
it's
a
kind
of
only
Apple
folks
on
it.
B
So
we
want
to
invite
folks,
if
you
think
this
topic
is
interesting
and
you'd
like
to
you
know
either
if
you've
written
rfcs
before
you
want
to
do
it
again
or
you've,
never
done
it
and
you're
interested
in
putting
work
and
like
learning
how
about
about
this,
both
Ted
and
Stuart,
or
know
how
to
do
this
really
well
and
can
help
give
you
tips
so
come
and
talk
to
them
after
the
meeting.
B
That's
what
we
would
like
to
see
as
chairs
before
bringing
an
option
call
ideally,
but
otherwise
I
think
we
have
the
bandwidth
for
it
and
we'll
also
need
to
check
interest,
because
the
previous
one
had
clear
interest.
This
one
is
a
bit
less
clear
from
the
community
outside
of
apples.
That's
what
we
would
be
looking
for.
B
All
right
well,
thank
you,
Ted,
sorry,
folks,
for
running
over
thanks
again
for
another
successful
dnssd
meeting,
we
are
happy
to
see
some
documents,
shipping
on
their
way
to
the
ASG
and
have
a
flow
of
steady
new
documents
coming
in
with
like
real
world
use
cases.
So
thanks
everyone
for
coming
thanks
for
all
the
discussion,
and
please
see
you
on
the
list
and
read
the
documents.
I
hear
they're
interesting.