►
From YouTube: IETF111-DNSSD-20210727-2130
Description
DNSSD meeting session at IETF111
2021/07/27 2130
https://datatracker.ietf.org/meeting/111/proceedings/
B
A
Sharing
things
david:
do
you
want
to
start
us
through
the
slides
since
you've
got
control,
sure
yeah.
B
Let
me
oh
no,
because
there's
the
the
chat
windows
actually
cover
the
controls
for
the
pdf,
so
that's
unideal.
Okay,
so
good
morning
afternoon
evening,
middle
of
the
night,
everyone
and
welcome
to
dns
service
discovery.
My
name
is
david
kanazi
and
our
other
co-chair
is
barbara,
stark
and
we're
going
to
talk
about
dns.
B
C
C
B
For
that
yeah,
it's
no
and
we're
also
using
the
new
miraco
feature
to
share
slides,
which
means
that
presenters
will
be
able
to
control
their
own
slides.
No
more
next
slide,
please
without
anyone
having
to
share
their
screen.
So
this
is
pretty
neat
all
right,
so
buff.
B
Given
that
it's
the
second
day,
I
hope
that
folks
are
familiar
with
the
note.
Well,
if
you
are
not,
please
use
your
favorite
search
engine
to
go,
find
it
and
read
it.
It
defines
all
the
rules
for
our
engagement
here
at
the
ietf
in
particular,
when
you
come
to
the
microphone
and
say
things
that
has
implications
if
you
know
about
any
patents
related
to
it,
and
also
it
shows
your
the
code
of
conduct
under
which
this
meeting
operates,
which
pretty
much
says
be
nice
to
everyone,
and
everything
will
go
well.
B
Otherwise,
in
terms
of
enemies,
trivia
here
are
some
links.
If
you
want
to
follow
those
we'll
be
looking
for
someone
to
take
minutes,
please
can
anyone
volunteer
for
that
today.
B
All
right,
and
so
the
jabber
is
being
forwarded
to
the
medical
messages,
so
I'll
keep
an
eye
on
it
myself.
If,
if
you
want
to
say
something
there
just
say,
mick,
colon
and
I'll
relay
it
at
the
microphone.
B
B
And
here
is
our
agenda
for
today,
so
we're
going
to
start
with
a
presentation
by
tourists
on
compatible
service
discovery
in
generic
autonomic
signaling
protocol
and
then
we're
going
to
have
a
set
of
presentations
from
ted
lemon
over
a
set
of
drafts
and
then
we'll
keep
on
the
order
of
10
minutes
at
the
end
to
wrap
up.
Would
anyone
like
to
bash
this
agenda
before
we
start.
B
All
right
hearing,
no
objections.
Torrelis,
you
are
up.
Please
I'm
gonna!
Stop
the
slideshare.
Please
click
the
request
to
share
slides
on
the
top
left
next
to
sharing
camera
and
audio.
B
E
Go
ahead,
thank
you.
So
this
work
was
already
presented
to
dns
as
the
eternities
ago
before
corona
itf
100.
We
let
it
expire
because
we
had
to
finish
our
chart
around
one.
This
wasn't
chart
around
one,
so
we're
now
reviving
it
after
we
did
our
chart
around
one,
and
so
there
is
very
little
editorial
changes.
We
could
get
the
new
co-authors
on
it,
but
I
wanted
to
bring
it
again
to
the
attention
to
dns
ssd
to
look
for
interest
possible
collaborators,
and
certainly
you
know
later
on
reviewers.
E
So
the
basic
thing
is
that
we
have
you
know
our
new
good
pool,
for
our
use
case
is
a
transport
mechanism
for
flooding
which
is
grasp
and
signaling
mechanism.
So
we
want
to
have
you
know:
dns
sd
compatible
service
announcement
discovery.
So
that's
supposed
to
be.
You
know
at
the
api
level
so
that,
hopefully
one
in
the
same
api.
E
Could
you
know,
depending
on
deployment
which
network
it's
trying
to
do
it
into
use,
grasp
with
vns
ssd
or
you
know
any
of
the
existing
ones
like
6763
and
that
basically
is
kind
of
the
goal.
The
way
it
would
look
in
grasp
is
that's
a
very
simple.
You
know.
Messaging
protocol
based
on
seabor
here
is
basically
how
a
single
grasp
service
would
be
defined
in
the
definition
language
cddl
has.
E
Typically,
you
know
all
the
known
parameters
that
we
have
in
dns
sd,
except
that
they
don't
need
to
be
split
up
across
at
least
four
different
type
of
resource
records,
as
the
mapping
to
dns
requires.
So
it's
you
know
in
the
implementation
on
the
wire
should
be
a
lot
more
simple,
the
prototyping
code
that
brian
carpenter
did.
I
think
already
pointed
to
that
simplicity
and
yeah.
That
was
basically
the
pitch.
E
B
C
E
C
Okay,
it's
rc
6335.
If
it's
following
that
syntax,
then
it's
for
good
or
bad.
It's
what
we
inherited
from
the
srv
format.
It's
underscore
parenthood
understood
tcp,.
E
Right
so
I
think
that
I
considered
that
to
actually
be
part
of
the
mapping
right
in
the
in
the
service
registry.
It
just
says
printer
and
then
the
dns
sd
thing
says
you
know,
trend
convert
that
word
printer
in
the
into
underscore
printer
dot,
udp
dot,
something
I
think
that's
in
a
later
slide.
C
Protocols
that
define
a
tcp
and
a
udp
variant
that
are
not
the
same.
If
I
could
go
back
in
time,
I
would
erase
that
because
that
was
exactly.
I
think
that
was
a
design
mistake
in
the
original
srv
specification
that
the
service
string
has
to
reflect
the
construction
of
the
protocol
and
what
protocol
it
runs
over,
but
unfortunately,
that
ship
has
sailed
so.
C
And,
of
course,
in
a
compact
encoding
you
you
can,
you
could
omit
the
leading
underscore
because
that's
kind
of
bogus
and
you
can
compress
the
udp
or
tcp
down
to
a
single
bit
just
just
as
long
as
we're.
But
but
you
answered
my
main
question,
which
is
we're
not
inventing
yet
another
registry
of
service
types.
E
F
Yeah,
so
is
the
idea.
Sorry
is
the
idea
to
to
have
this
go
to
a
some
kind
of
translation
server?
That
then,
does
a
dns
ssd
query,
or
are
you
proposing
to
replace
the
dns
ssd
protocol.
E
The
dns,
as
I
said
right
so
to
to
me
this
is
yet
another.
You
know
way
to
provide
the
service
and
we
don't
need
the
dns
as
the
unicast
or
dns
as
the
multicast
or
mapping
of
the
service
information
into
its
srvs,
because
we,
you
know
grasp
is
its
own
transport
right.
So
this
was
basically
what
the
the
picture
was
trying
to
show.
F
E
No,
we
already
had
the
new
protocol
invented
and
I
was
trying
to
say
that
we
don't
need
to
duplicate
things
in
there
that
we
already
have,
and
that
is
specifically
the
definition
of
services
and
the
registry
for
it,
and
that's
basically
what
I
call
the
dns
service,
api
and
registry
and
I'm
not
sure
that
we
actually
have
anywhere
a
real
specification
of
even
the
abstract
dns
as
the
api.
You
kind
of
got
to
reverse
engineer
that
from
6763,
which
is
very,
you
know,
instructive
of
how
to
map
it.
E
You
know
the
the
service
definition
into
these
four
different
resource
types
resource
records.
Sorry
right
so
maybe
maybe
I
should
also
try
to
write
a
check
graph
of
saying
what
we
consider
to
be
that
abstract
service
api
that
dns.
But
you
can
see
the
concrete
instantiation,
of
course,
in
various
you
know,
dns
service
libraries
in
ssd
services.
F
E
E
Okay
right,
but
the
whole
point
was
that
I
mean
I
we
actually
our
you
know:
industrial
pre-standard,
you
know,
enema
implementation
was
using
mdns,
and
so
there
is
a
lot
of
experience
from
that
and
why
it's?
E
You
know
not
really
the
the
best
way
to
do
things
so
for
the
standard,
that's
who
was
also
one
of
the
starters,
while
we're
doing
this
with
with
this
product
called
so
the
the
actual
you
know,
enema
use
case
is
really
that
we're
building
this
autonomic
network,
so
you
plug
the
devices
together,
you
get
an
invent.
E
You
know
a
secured
virtual
network
for
all
oem
instructions.
So
that's
where
we
are
in
the
itf
and
the
piece
that
we're
missing
is
now.
How
do
we
discover
and
announce
services
for
the
infrastructure
itself?
So
the
typical
examples
are
syslog
radio
servers,
diameter
service
ntp
servers.
All
these
things,
of
course
we
want
to
automatically
configure.
E
So
it's
good
enough
for
you
to
bring
up
a
server
and
basically,
you
know
automatically
or
manually
say:
what's
this
priority
weight,
all
the
good
dns
things
and
then
it
should
be
discovered
there,
and
the
interesting
part
is
that
this
whole
acp
works
without
names,
because
every
node
gets
through
its
certificate,
a
lifetime
ipv6
address,
and
that
basically
means
even
the
whole
naming
stuff.
That's
also
you
know
in
dns,
sd
isn't
necessary
at
all.
We
can
simply
resolve
between.
E
You
know
the
service
and
the
ipv6
address
in
the
icp,
providing
further
simplification
yeah.
This
was
the
list
of
the
services
that
we
that
in
another
draft
I
I've
explicitly
listed
as
how
to
bootstrap
a
network
right.
So
those
are
the
the
most
important
ones,
but
there's
obviously
a
wide
variety
of
other
services.
I
list
on
the
last
line
for
for
centralized
or
decentralized
service
instances.
Maybe
the
this
is
kind
of
the
details.
Why
kind
of
I
hate
md
and
s
multi-hop
flooding?
E
I
don't
want
to
go
into
details
of
that
that
takes
forever,
but
I
think
the
and
the
grasp
stuff
also
maybe
yeah
everybody,
everybody
hates
dns
multi-hole
plotting.
There's
no
argument
right.
Okay,
so
what
we're
doing
is
actually
we're
having
we're
having
a
message,
identifier
and
we're
doing
loop
prevention
by
having
a
cache
of
recent
messages.
So
that's
how
we
can
flood
very
efficiently
without
looping.
So
this
was
the
register
right.
E
So
the
whole
thing
started
that
we
had
our
own
namespace
and
it
may
still
be
useful
whenever
what
we're
doing
with
grasp
has
nothing
to
do
with
the
service
that
we
announced
or
discover.
But
then
we
started
to
do
things
like
we
needed
to
have
est,
which
is
rfc
7030,
which
already
is
in
the
services
registry,
and
we
would
redefine
it.
E
So
you
know
the
proposal
of
the
current
draft
is
now
to
have
you
know
in
our
name
a
similar
mapping,
as
you
know,
so
we're
doing
srv
dot,
existing
service
registry
name,
which
would
be
similar
to
the
underscore
so
to
speak
in
in
indian
ssd
and
maybe
just
to
to
to
wrap
up
so
yeah.
E
So
there
is
prototype
for
this,
and
maybe
the
the
interesting
things
for
for
the
group
to
consider
to
look
more
into
it
is
this
acp
stuff
that
we're
doing
is
fairly
convoluted
and
complex
because
it
is
secure
with
certificates
and
everything.
But
if
it's
just
about
using
grasp
to
have
a
you
know,
network-wide
multi-hub,
flooding
mechanism
of
messages
that
could
then
be
used
for
for
for
service
discovery
of
services,
where
you
really
don't
want
to
have
a
third
party
right.
E
So
every
dns
unicast
server
is
a
third-party
dependency
that
needs
to
run
between
a
service,
announcer
and
a
consumer,
and
you
know
we
didn't
have
that
in
the
original
layer,
2
networks
right,
but
in
layer,
3
networks.
It
would
also
be
nice
to
have
something
without
that
third
party.
I
think
it
would
be
fairly
easily
possible
to
define
a
an
adoption
of
grass
that
could
be
easily
deployed
in
every
existing
network,
not
only
in
enema
networks
and
so
the
last
three
four
bullet
points
there
give
some
direction.
E
A
Thank
you
very
much
for
us.
Are
there
any
other
questions
or
comments
before
we
move
on
to
heads,
make
the
presentation
and
so
discussion
of
this
one
specifically,
this
draft,
specifically
that
you
just
saw
from
torlas,
is
going
to
be
happening
in
enema.
There
is
his
offer
that
if
you
have
interest
on
expanding
use
of
that
to
more
generic
use
cases
beyond
anima,
you
can
contact
him
thanks
ted.
Are
you
prepared
prepared
to
share
or
well
to
click
the
appropriate
buttons
to
start
the
slides
appearing.
F
Okay,
so
very
bold
statement
for
the
talk.
Basically,
we've
been
doing
a
bunch
of
work
over
the
course
of
the
life
of
the
working
group
to
to
kind
of
extend
the
different
use
cases
and
and
sort
of
solve
problems
like
the
one
tourist
was
a
was
alluding
to
with
with
multicast
flooding,
which
is
not
something
we
like.
So
I
just
want
to
go
over
kind
of
where
we
are
and
where
we're
going.
F
A
bunch
of
work
has
occurred,
and
I
think
I
hope
it's
of
interest
to
the
working
group.
So,
first
of
all,
you
know
what
is
the
nssd?
The
whole
idea
with
dnssd
is
automatic.
Advertising
and
discovery
of
network
services.
Permissionless
can
be
managed,
doesn't
have
to
be
it's
built
on
top
of
dns
and
that's
because
dns
is
also
an
advertising
and
discovery
service,
so
we're
basically
just
making
dns
better
so
how
it
works.
Some
devices
provide
services,
they
advertise
those
services
using
ptr
records.
F
Ptr
records
are,
you
know,
there'll,
be
multiple
ptr
records
if
there
are
multiple
servers
of
the
same
type,
and
so
you
can
just
do
a
query,
get
a
list
of
ptr
records
and
all
of
those
devices
provide
that
service,
and
then
you
can
do
a
resolve
to
get
the
information
about
the
service.
That
would
be
the
srv
record,
there's
also
a
txt
record,
which
has
additional
information
about
the
service
and
then
once
you
have
the
srv
record,
you
can
also
look
up
the
ip
address
of
the
device.
F
I
swanishly
used
an
a
record
instead
of
a
quad,
a
record.
I
apologize,
so
that's
how
you
publish
services
and
then
a
device
that
wants
to
look
at
services
or
find
a
service.
First
does
the
discovery
by
looking
for
the
ptr
records
and
then
it
results.
F
It
selects
a
service
by
choosing
one
of
the
services
listed
in
the
ptr
records,
possibly
through
configuration
or
whatever,
and
then
or
you
know,
normally
it
would
be
the
user
touching
it,
but
that's
only
if
it's
not
automatic
and
then
once
the
service
has
been
has
been
chosen.
It
resolves
the
service
by
looking
up
the
srv
record
and
once
it's
looked
up
the
srv
record,
that
tells
it
what
quad
a
record
or
a
record
to
look
for
and
that's
all
it
needs
to
know
to
talk
to
the
service.
F
So
as
of
about
2018,
there
were
kind
of
two
ways
of
doing
dns
ssd
one
of
them
was
to
multicast
dns,
which
is,
as
I
said
earlier,
permissionless
it's
limited
to
a
single
subnet.
So
it's
great
for
like
a
home
network.
That
only
has
one
subnet,
and
this
is
documented
in
rfc6763.
F
That's
the
dnssd
specification
and
rfc
6762,
which
is
the
multicast
dns
specification.
So
that's
work.
That's
already
complete,
obviously,
unicast
dns
very
similar,
really
only
works
for
managed
networks.
So
there's
no
automatic
way
as
of
2018
to
do
unicast,
dns
and
the
nice
thing
about.
Is
it's
not
limited
to
one
subnet,
so
you
can
have
like
a
whole.
You
know
campus
with
services
that
are
that
are
discoverable
across
the
campus,
and
this
is
documented
in
rfc
6763.
F
Again,
that's
the
core
dnsd
document
and
it
you
know
leverages
rfc
1034
1035..
So
I
realize
this
is
all
review,
but
I
just
want
to
kind
of
set
the
stage.
So
the
idea
with
the
nssd
over
mdns
is
you
have
all
these
devices
and
so
say
device
a
wants
to
discover
a
service
happ.tcp.
F
So
it's
basically
it's
a
it's
a
single
packet
exchange
for
for
the
most
part.
So
then,
with
dnssd
over
dns,
it's
a
little
different.
The
dns
servers
just
has
a
database
in
it.
None
of
the
devices
do
anything.
Somebody
has
configured
the
dns
server
with
the
databases
and
then
device
a
wants
to
discover
device.
You
know
wants
to
discover
the
same
sort
of
service
and
it
basically
does
the
same
set
of
queries.
It's
a
little
less
likely
that
the
additional
section
will
be
nicely
populated.
F
In
this
case
you
could
have
a
server,
that's
kind
of
set
up
to
know
that
you're
going
to
want
that
information.
But
normally
that's
not
going
to
be
the
case,
so
you're
going
to
have
to
probably
do
an
a
record
query.
Sorry
you're
going
to
have
to
do
a
ptr
record,
query
you'll
get
back
the
list
and
then
you'll
do
an
srv
record
query
for
the
one
that
you
want.
A
txt
record
query
for
the
one
that
you
want
and
then
you'll
start
doing,
quad
a
or
a
record
queries.
F
So
so
it's
a
little
bit
clunkier
in
that
sense.
But
but
it's
also,
I
mean
it's
unicast,
so
the
cost
of
sending
packets
is
low
and
it's
not
really
a
big
deal.
So,
oh
right
and
there's
your
answer
so
then
in
2019
I
mean
we've
been
working
on
this
for
a
long
time,
but
but
these
were
basically
finished
in
2019.
F
We
added
the
dnssd
discovery.
Proxy
and
dns
push
dnssd
discovery.
Proxy
gives
us
the
ability
to
do
instead
of
doing
cascading
multicast,
which,
as
turlets
pointed
out,
is
kind
of
crappy.
F
What
we
do
is
we
have
single
subnet
multicast
for
discovery,
and
then
these
discovery
proxies
act
as
authoritative,
dns
servers
for
specific
zones,
and
so
we
do
queries
into
those
zones
to
get
the
information
using
at
the
at
the
far
end.
It's
mdns,
but
all
the
queries
are
done
with
dns.
F
Dns
push
adds
the
ability
to
do
those
queries
asynchronously.
So
one
of
the
nice
things
about
mdns
is
you
send
a
multicast
packet
for
services
and
you
just
kind
of
keep
sending
it
every
so
often
and
you'll
get
back
new
information
and
also
services
come
on
to
the
network.
They'll
they'll
announce
that
they've
come
onto
the
network,
so
when
a
service
shows
up
it
just
shows
up
in
the
dialog
box
or
in
your
you
know,
in
your
little
internal
list
or
whatever,
and
the
problem
is
dns,
you
know,
regular
dns
doesn't
have
that
ability.
F
Dns
is
just
you
know,
single
packet
exchange,
so
so
dns
push
out
of
the
ability
to
say:
okay,
I'm
going
to
connect
to
the
dns
server,
and
I'm
going
to
ask
it
to
tell
me
whenever
there's
new
information
about
records
that
match
this
query
this
question
and
that
lets
us
say
you
know
give
me
all
of
the
give
me
answers
for
hap.tcp.whatever.
The
domain
is
and
we'll
get
back,
srv
records
as
the
services
register.
So
that's
really
nice.
F
F
The
device
that
actually
has
the
answer,
responds
and
bam.
We
got
a
dns
answer
and
it's
over
dns
push.
So
now,
if
some
other
device
see
device
f
shows
up,
it
sends
a
multicast
announcement,
saying
hi.
I
also
do
happ.tcp
and
then
bam.
We
get
another
dns
push
answer
going
out
to
the
device.
So
it's
it's
it's
nice.
It
implements
the
same
sort
of
functionality
as
we
got
out
of
mdns.
F
So
I
think
I
probably
covered
this
slide
pretty
well.
So
that
was
great,
but
you
might
have
noticed
that
we
added
some
new
stuff
that
was
srp
in
the
advertising
proxy
and
the
idea
with
srp
in
the
advertising
proxy
is
that
multicast
kind
of
sucks
on
constrained
networks,
because
every
device
winds
up
getting
every
clear,
every
question
and
these
are
devices
that
have
batteries
in
them.
You
don't
want
to
be
them
to
be
sitting
there.
F
All
the
time
listening
for
quest
queries
so,
and
the
other
issue
is
that
the
constrained
networks
are
usually
not
the
same
network
as
all
the
rest
of
your
stuff.
So
if
you've
got
like,
you
know
an
iphone
or
an
android
phone,
or
something
like
that,
you
want
to
discover
all
the
light
bulbs
in
your
house
and
they're
all
on
some
constrained
network.
F
That's
going
to
be
a
different
network,
so
we
thought
about
using
a
discovery
proxy,
but
we
didn't
want
to
use
multicast,
and
so
we
decided
that
what
we
really
wanted
was
a
stateful
service
kind
of
like
dhcp,
except
sort
of
backwards.
So
the
idea
with
this
service
is
that
you
just
announce
to
some
central
service.
F
F
So
so
the
two
drafts
that
do
that
are
the
srp
draft
and
the
advertising
proxy
draft,
which
I'll
talk
about
a
little
bit
more.
So
the
way
this
works
is
you
have
a
device.
It
sends
an
srp
update
to
the
srp
proxy
and
then
later
on.
Another
device
wants
to
find
out
about
devices
the
services
of
that
type.
F
It
asks
an
mdns
question,
because
this
is
this
is
an
mdns
proxy
and
it
gets
back
an
answer
and
we
wanted
to
use
mdns
in
this
case,
because
we
wanted
to
devices
that
already
work
to
just
work.
We
didn't
want
to
have
to
do
anything
special.
We
didn't
want
to
have
to
have
some
kind
of
infrastructure
to
support
this.
So
I
kind
of
rushed
to
this
point
because
I
wanted
this
is
the
most
important
slide.
I
think
right
now,
draft
srp,
replication
10
is
ready
for
last
call.
F
We
had
we
had
comments
on
the
document,
but
they
they
kind
of
petered
out.
We
got
lots
of
good
comments
and
a
lot
lots
of
changes
based
on
based
on
the
discussion
in
the
working
group.
F
But
the
last
comment
was
was:
oh,
you
know,
you
don't
have
a
way
to
deal
with
alternate
services
and
there's
some
stuff
in
6763
if
you're,
if
you
didn't
follow
it
on
the
message
on
the
mailing
list
and
you're
curious,
what
that
is
talk
to
me,
but
basically
the
idea
is
that
that
you
can
say
you
know
that
a
device
provides.
F
You
know
you
can
alias
services.
So
I
just
added
some
text
to
the
document
to
do
that.
F
Basically,
as
far
as
I
can
tell
the
document's
ready-
I
don't
I
mean
if
we
do
a
last
call,
I'm
not
even
convinced
that
there's
going
to
be
further
requests
for
changes
at
this
point,
although
I'm
I'm
open
to
that,
if
there
are
requests
so
I'd
like
the
working
group
to
do
a
last
call
at
this
point,
one
thing
that
I
noticed
when
I
was
preparing
for
this
is
that
we
have
a
normative
reference
to
a
document
that
we
never
adopted.
F
Drafts
a
car.
Dns
ul
is
the
the
the
something
lease
option.
I'm
blanking
on
the
name
stuart's
going
to
tell
me
it's
update,
least
update.
Thank
you
yeah.
So
basically,
it's
saying
how
long
the
the
srp
update
is
good
for
because
we
don't
want
it
to
be
clogging
up
the
network
database
forever.
C
It
will
name
that
way,
however,
many
years
ago,
it
was
because
it
was
a
companion
to
standard
dns
update
when
you
update
records
with
ns
update.
They
stay
there
until
a
human
comes
along
and
deletes
them,
and
we
wanted
this
to
be
a
bit
more
suitable
for
machine
to
machine
communication
kind
of
modeled
on
dhcp,
which
is,
if
you
don't
renew
it.
It
goes
away
when
your
lease
expires.
So
that's
why
it's
called
an
update
lease.
A
Okay,
so
you
have
some
requests
here.
Let
me
ask
the
working
group:
does
anyone
have
any
reason
why
you
should
not
start
wglc
for
the
srp
replication?
H
A
I'm
not
seeing
anybody
step
into
the
queue.
I
I'm
wondering
if
I'd
like
to
kind
of
get
a
sense
of
how
many
people
are
ready
to
and
willing
to
review
this.
That's
okay,
just
to
you
know,
get
some
commitment
here
in
the
meeting.
A
C
F
A
A
A
Okay,
so
let
me
start
a
new
one
and
of
course
this
gets
confirmed
on
the.
A
A
C
C
This
is
this
is
being
used
in
thread,
which
is
a
low-power
wireless
mesh
network
in
turn
being
used
for
home
automation
in
the
new.
The
new
home
automation
protocol
coming
out,
which
was
previously
called
chip
from
the
zigbee
alliance
and
has
now
been
renamed
to
mata
m-a-t-t-e-r
and
the
zigbee
alliance
is
now
called
the
csa.
C
So
there's
been
some
name
changes
and
we
are
already
using
a
precursor
of
this
in
the
apple
homepod
and
the
apple
tv
to
support
thread-based
home
kit
accessories,
and
these
are
little
battery-powered
devices
that
run
on
a
half
double
a
battery
for
two
years.
So
that's
why
the
stuff
that
ted
said
about
power
efficiency
is
super
important.
If
we
were
pinging
all
these
battery
powered
devices
with
multicasts
all
the
time
and
they
had
to
be
listening
for
them,
we
would
kill
the
batteries
in
two
weeks
instead
of
two
years.
C
So
this
has
a
big
big
impact
on
on
the
home,
automation.
A
Apparently
convinced
everybody
well,
at
least
there
are
seven
hands
raised,
and
there
are
no
people
who
purposefully
did
not
raise
their
hand,
which
would
be
the
I
guess
the
the
hum
opposed.
A
Well
now
that
you
know
that
you
can.
You
know
if
you
purposely
want
to
not
raise
your
hand,
you
can
oppose,
but
it
looks
like
there's
certainly
enough
for
us
to
call
for
adoption,
and
if
there
is
opposition
you
can
voice
it
there.
So
we
will
start
the
call
for
adoption.
A
Okay-
and
you
were
about
to
say
something
about
stewart.
H
F
Then,
oh,
I
was
just
going
to
say.
The
fact
that
that
exists
in
a
product
should
not
be
taken
to
mean
that
we're
wedded
to
doing
things
exactly
the
way
it
is
in
the
product,
because
you
know
we're
not,
we
can
do
updates.
So
that
said,
the
last
thing
is
drafts.
A
car
is
a
really
short
draft.
It
just
explains
the
update
lease
option
and
I'd
like
the
working
game
to.
B
A
D
Sorry
all
right,
just
allow
me
to
interrupt
a
few
things.
I
have
to
read
the
secure
draft
to
understand
the
content,
but
we
need
to
be
sure
it
fits
the
dns
sd
charter,
key
production.
D
D
C
Or
it
could
be
dns
yeah.
We
should
check,
I
agree
100
with
what
eric
said
and
eric
also
mentioned
ad
sponsored
as
an
option.
So
I
think
that
the
right
way
to
answer
this
question,
as
ted
said
it
is
really
short.
It
is
basically
you
do
a
dns
update
and
add
an
edinso
extension
giving
a
lifetime
in
seconds.
I
think,
and
and
it's
modeled
on
dhcp,
where
the
client
requests
something
and
the
server
grants
a
lease
which
may
be
more
or
less
than
that.
C
F
A
Trying
to
summarize
where
we
are
so
to
summarize,
we
we're
going
to
start
a
working
group
last
call
for
srp
service
registration
protocol.
A
We
are
going
to
do
a
call
for
adoption
for
the
advertising
proxy
for
dnssd
srp,
and
then
I
am
going
to
admit
that
I
got
a
little
bit
lost
on
the
other
document.
We
were
talking
about
for
potentially
having
a
d
sponsorship.
B
So
I
think
the
chairs
need
to
huddle
on
that
last
one
with
our
friendly
id
to
see
if
the,
if
we
think
this
matches
our
charter
and
then,
if,
if
it
does,
then
it
sounds
like
a
good
candidate
for
caller
for
adoption.
If
it
doesn't,
then
we
can
discuss
if
our
friendly
id
wants
to
sponsor
this
or
if
we
should
bring
it
to
a
different
ietf
working
group.
A
I
I'm
sorry
eric.
Can
you
say
that
again.
B
Summary
thanks:
okay,
so
well!
The
chairs
will
take
that
action
item
to
follow
up
with
with
our
id
after
the
meeting.
B
F
C
Oh,
thank
you.
While
my
mike's
live,
I
have
a
request
for
you
ted.
Let's
update
this
slide
to
put
the
right
draft
title,
because
otherwise
this
slide
will
go
into
the
meeting
records
would
be
confusing.
F
Okay
chairs,
if
I
send
you
a
new
copy
of
this
slide
deck,
will
that
can
you
still
upload
it.
F
Okay,
I'll
do
that
cool
all
right.
We
should
probably
move
on
we're
running
out
of
time.
So,
of
course,
when
you
deploy
new
stuff,
you
run
into
problems
and
we
ran
into
some
problems.
One
of
the
problems
we
have,
particularly
in
the
in
the
homepod,
slash
apple
tv
deployment
scenario,
where
these
are
devices
that
you
just
add
to
your
network.
F
That's
one
issue.
The
other
issue
is
you
know
if
you've
got
like
50
light
bulbs,
then
when
you
do
a
dns
query,
looking
for
ptr
records
to
describe
the
light
bulbs-
and
you
know
so
forth,
you're
going
to
get
a
really
big
answer
back
and
that's
a
lot
of
mdns
traffic.
It's
really
not
efficient
to
do
that
with
mdns
you'd.
Really,
rather
do
that
over
tcp
like
say,
dns
push,
so
I
mean
it'd,
be
fine
in
principle
on
you
know,
wired
networks,
but
most
people
are
using
wi-fi.
F
So
that
would
be
fine
is
not
particularly
applicable,
so
we
did
some
new
work.
This
year
I
came
up
with
a
replication
protocol
that
allows
multiple
srp
servers
to
cooperate
with
each
other
to
share
their
database
so
that
when
one
server
gets
an
update,
it
reflects
that
update
to
all
the
other
servers
and
and
so
they're.
Essentially
it
means
that
we
don't
see
conflicts
because
you
know,
if
there's,
if
there's
an
issue
where
the
srp
client
connects
to
a
new
server,
we're
going
to
get
a
new
communication.
F
That
communication
is
secured
with
the
same
key
that
was
used
for
the
previous
update,
and
so
we
know
that
it's
the
same
client
and
so,
and
the
fact
that
it's
more
recent
means
that
it's
more
recent,
and
so
we
can
throw
out
the
old
information
and
use
the
new.
So
it's
a
nice
little
protocol.
It's
this.
It
turned
out
that
srp
was
a
pretty
simple
thing
to
do
replication
on
as
compared
to
all
the
other
things
we
do
replication
on.
That
are
a
lot
harder,
at
least
that's
my
theory.
It'd
probably
be
good.
F
If
the
working
group
checked
my
theory
so
and
then
the
scalability
thing,
basically
the
solution
to
that
is
something
that's
actually
described
in
rfc
6763,
but
but
rfc
6763
doesn't
give
much
detail.
So
I
wrote
a
document
along
with
joey
deng
who's,
a
co-worker
of
mine
at
apple,
and
that
document
describes.
Joey
did
most
of
the
implementation
on
this.
That
document
describes
the
a
mechanism
for
for
advertising
the
availability
of
a
dns,
authoritative
server
for
an
ad
hoc
zone
into
which
you
can
do
queries
using
dns
push
to
get
answers
about.
F
You
know,
services
that
are
available
on
the
network
rather
than
using
mdns,
and
so
that's
a
work
in
progress.
It's
still
pretty
young.
I
think
it
needs
a
lot
of
discussion.
I
think
this
is
the
right
place
to
do
that
discussion
and
so
I'd
like
to
do
that.
As
I
said,
I've
written
or
I
didn't
know.
If
I
don't
know
if
I
said
I
did
say
I've
written
drafts
about
this,
and
so
you
know
I'll
just
describe
it
a
little
bit
so
the
dns
proxy.
F
Basically,
the
idea
is
that
you
know
a
device
that
wants
to
do
this.
This
discovery
asks
the
srp
proxy
using
multicast
dns.
F
F
You
go
and
sends
a
ptr
record
with
that
information,
and
then
the
device
establishes
a
dns
push
connection
with
the
srp
proxy
and
it
says
that
it
wants
to
look
for,
say:
happ.tcp
I've
been
using
that
all
over
the
place
and
device
b
happens
to
do
hap.tcp,
and
so
it
registers
with
the
srp
proxy
and
then
as
soon
as
it's
registered
with
the
srp
proxy,
the
the
srp
proxy
tells
device
a
which
has
that
open,
dns
push
connection.
F
Here
you
go
so
the
open
issues,
as
I
said,
srp
replications.
I
think
it's
pretty
solid,
but
it
could
definitely
use
more
more
eyes
on
it.
I'm
sure
there
are
things
I
haven't
thought
of
in
there,
and
also
maybe
it's
too
complicated
so
be
nice
to
have.
You
know
the
working
group.
Look
at
that
and
then
zone
discovery.
There
are
some
issues
that
are
sort
of
unresolved
as
yet,
how
do
we
agree
on
a
domain
name?
F
There
are
some
ideas
in
the
draft
for
how
to
do
that,
and
you
know,
and
also
like
yes,
you
know
we
want
this
to
work
in
a
sort
of
a
permissionless
environment.
We
also
want
it
to
work
in
a
more
managed
environment,
whether
it's
sort
of
autonomously
managed
or
whether
it's
you
know
managed
by
a
network
management
team.
So
so
that's
that's
kind
of
some
stuff
that
needs
to
be
fleshed
out
in
the
document.
F
So
again,
you
know,
obviously
it's
a
little
it's
a
little
soon
for
the
working
group
to
say
yes
to
these
questions,
I'm
just
announcing
that
this
is
something
that
I
would
like
the
working
group
to
consider
once
people
have
time
to
read
these
documents
and
figure
out
whether
they
think
they're
worth
adopting.
Obviously,
it's
premature
to
ask
to
adopt
right
now,
but
this
is
something
that
I
would
like
to
see
happen.
F
You
know
personally
I'd
like
to
see
it
happen
really
soon,
because
I'd
love
to
see
you
know,
work
done
on
these
and
for
us
to
make
progress
on
this
stuff.
So
I
don't
know
I
don't
know.
If
there's
really
a
need
barbara,
do
you
think
we
need
to
actually
ask
the
working
group
a
question
right
now
I
mean
I'm
not
really
asking
for
immediate
adoption,
I'm
just
saying:
let's,
let's
you
know
and
I'll,
send
some
mail
to
the
mailing
list
and
ask
people
to
review
this
so.
A
Yeah,
I
think
that's
enough
you're,
just
introducing
it.
B
Yep
yeah:
let's:
let's
get
the
dress,
published
and
give
people
some
time
to
review
them
and
then
they're.
B
Yeah
so
yeah,
please,
please
email
the
list
and
asking
for
reviews,
and
if
we
have
enough
interest
and
reviews,
then
that
that
makes
us
want
to
consider
adoption.
But
we'll
want
to
see
if
there's
interest
from
various
folks
before
we
do.
Okay,.
F
All
right,
so
we
have
about
three
minutes
left
of
the
time
slot
that
you
proposed.
So
I
just
wanted
to
talk
about
some
of
the
remaining
issues
that
I
think
would
be
nice
for
the
working
group
to
work
on
and
that
we're
certainly
thinking
about
and
working
on,
you
know
stuart
and
I
and
some
of
the
other
folks
on
the
discovery
team
are
working
on
so
currently
we're
still
very
reliant
on
mdns,
and
we
can't
totally
fix
that.
F
But
it
would
be
nice
if
we
could
have
if
we
could
at
least
describe
how
say
a
stub
network.
Resolver
like
like
a
thread
network
resolver
excuse
me
could,
in
principle,
announce
the
availability
or
register
the
availability
of
the
stub
network,
discovery
service
to
some
kind
of
central
authority
like
your
customer
edge,
router
or
some
other
device
in
the
home.
F
That's
managing
the
dns
in
the
home,
so
this
kind
of
is
now
straying
into
home
that
land,
although
I
and-
and
maybe
maybe
actually,
this
should
be
something
that's
done
in
homenet,
but
but
I'd
like
to
see
it
done
somewhere
in
the
itf.
F
So
so
we'd
like
to
be
able
to
do
that,
we'd
like
to
be
able
to
get
away
from
using
multicast
at
all,
on
wi-fi
really,
except
to
support
legacy
stuff
and
we'd
like
to
we'd
like
to
one
of
the
things
there
are
some
multicast
dns
like
like
site-wide
multicast,
dns,
hacks,
that
various
companies
have
released
that
actually
break
mdns
on
local
links,
and
it
would
be
nice
to
be
able
to
just
bypass
that
crap
so
being
able
to
set
up
a
dns
infrastructure
that
does
the
right
thing
would
be
nice,
so
those
are
kind
of
motivations
for
moving
moving
away
from
dns.
F
What
we're
going
to
need
is,
as
I
said,
the
ability
to
register
stub
network
dns
resolvers
to
be
able
to
tell
devices
that
service
discovery
is
available.
They
don't
have
to
use
multicast
on
this
particular
link
right
and
and
and
to
have
all
services,
not
just
stub
network
services
check
to
see
if
srp
is
available
and
use
it
if
it
is,
and
then
this
is
a
kind
of
a
big
ask
and
I'm
not
sure
how
how
doable
it
is.
F
But
it
would
be
nice
to
to
to
think
about
whether
we
can
describe
how
to
do
this,
and
I
think
we
can,
which
is
that
it
would
be
nice,
if
suppose,
you've
got
a
device
that
supports
multicast
dns
only
because
it's
a
legacy
device
and
it's
connected
to
your
wi-fi
network
or
to
your
ethernet
and
you'd
like
to
be
able
to
do
discovery
on
that
device
and
you'd
like
other
devices,
to
be
able
to
discover
it.
But
you
don't
want
to
screw
up
the
mdns
service.
F
You
don't
want
to
screw
up
the
the
the
other
devices
that
are
listening
for
mdns
packets
on
the
network.
So
what
you
really
want
to
do
is
arrange
to
get
an
mdns
packet
to
that
device,
asking
it
if
it
has
that
service.
But
you
want
it
to
really
be
a
unicast
and
obviously,
if
it's
on
wi-fi
unicasts
are
actually
sorry,
multicasts
are
always
unicast
towards
the
wi-fi
access
point.
F
So
if
you
can
receive
that
multicast
at
the
wi-fi
access
point
and
have
a
special
rule
that
says,
whenever
you
get
a
multicast
of
this
type,
you
send
it
here,
you
don't
just
re-multicast.
It
then,
essentially,
we
can
get
rid
of
all
of
the
multicast
on
the
wi-fi
network
while
still
supporting
legacy
devices.
F
A
So
we
it
does
look
like
douglas,
has
a
comment.
E
Yeah
so
I
mean
the
the
better
enterprise
level.
Wi-Fi
access
point
already
should
be
constraining
multicast
to
only
the
members
that
do
igmp
and
then
unicast
them
out.
Instead
of
doing
link
local.
E
B
E
F
E
F
So
yes,
you're
right
in
environments
where
you
can,
where
you
have
wi-fi
access
points
that
have
this
functionality,
that's
awesome,
you
can
just
you,
can
you
can
set
up
that
igmp
setup
and
and
direct
it
to
the
to
the
to
the
discovery,
proxy
and
everybody's
happy,
but
remember
it
has
to
go
both
ways.
That's
one
thing
and
you
have
to
describe
how
the
discovery
proxy
behaves
in
that
situation,
so
so
yeah
you're
right
I
mean.
I
don't
think
that
this
is
a
super
heavy
lift
for
that
type
of
device.
F
I'd
also
like
to
see
it
on
home
home
gateways,
though,
and
those
those
devices
might
require
a
little
bit
more.
You
know
it
may
not
require
special
specification
work
to
speak
of.
I
don't
know,
I'm
not
stating
an
opinion.
I
think
the
working
group
should
look
into
this
and
figure
out
whether
it
requires
how
much
work
it
requires
and
what
worker
requires.
And
then
we
can
either
decide
to
write
a
document
or
conclude
that
there's
no
work
to
do,
and
so
we
don't
have
to
write
a
document.
C
I
want
to
add
something
a
little
bit
more
to
what
you're
saying
about
that
last
point:
ted.
There
are
enterprise
access
points
that
do
I
I
didn't
catch
who
asked
the
original
question,
but
it
doesn't
matter.
There
are
access
points
that
do
that
and
they
completely
break
multicast
dns
and
somehow
they
ship
them
anyway
and
don't
seem
to
have
noticed
that
they've
broken
it
and
the
reason
they've
broken.
It
is
one
of
the
efficiency
mechanisms
in
multicast
dns,
because
multicast
on
wi-fi
is
so
expensive.
C
It's
centered
at
a
low
data
rate
and
it
can't
make
use
of
mimo
because
it's
just
not
targeting
a
single
station
stations,
listen
for
each
other's
queries
and
answers.
So,
if
ted
is
looking
for
a
service
and
the
service
answers,
I
see
it
similarly
to
eliminate
stale
data
without
rapid
polling.
C
F
I
B
So
thanks
ted
for
the
presentation,
let
me
press
the
there.
We
go
so
yeah
thanks
everyone
for
a
good
dnssd
session
and
some
so
we
have
some
good
action
items
to
make
progress
on
several
documents,
one
last
important
announcement.
That
makes
me
personally
very
sad
at
the
end
of
this
session.
Barbara
is
stepping
down
as
chair
of
the
nssd.
A
And
so
yeah
I'll
be
around
still
through
the
end
of
the
year,
but
I
am
stepping
down
as
chairs
so
that
you
know
we
can
do
a
graceful
transition
and
hand
over
to
somebody
else
who
you
know.
Maybe
I
should
give
eric
some
time
to
talk
about
that.
I
don't
know.
D
D
Basically,
I'm
trying
to
look
for
a
mission
impossible,
I
would
say,
find
a
substitute
on
alternate
server
as
a
working
group
chair
for
this
working
group.
So
if
somebody
wants
to
experiment
and
basically
try
to
get
a
working
group
chair
position
to
learn
more
about
the
atf,
it
requires
some
time.
But
it's
not
a
big
big
amount
of
time
so
feel
free
to
talk
to
david
or
barbara
or
myself.
B
That
would
be
a
a
great
idea
to
have
a
new
person
join.
The
ssd
was
my
first
working
group
and
I'll
say
now.
I
also
chair
another
one
and
have
like
have
taken
up
way
too
much
work,
but
that's,
I
guess
my
fault,
but
I'll
say
that
the
ssd
has
been
a
great
working
group
that
doesn't
have
drama
like
some
others,
and
so
it's
a
great
place
to
start
where
people
are
actually
doing
useful
work
that
lands
in
billions
of
devices,
and
that
is
fun.
B
B
All
right
on
that
note,
I
think
that's
unless
anyone
has
final
things
to
bring
up.
I
think
that's
a
wrap
thanks
everyone
for
coming
and
see
you
on
the
mailing
list.
There
is
going
to
be
some
docs
to
review
all
right
cheers
everyone
thanks.