►
From YouTube: IETF112-DNSSD-20211112-1600
Description
DNSSD meeting session at IETF112
2021/11/12 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
All
right
folks,
remember
standards.
Work
is
a
contributive
process
that
we
all
do
together
and
we
need
volunteers
to
keep
things
moving.
So
it's
not
a
whole
lot
of
work.
It's
just
for
one
hour.
You
kind
of
keep
track
of
the
conversation
and
write
it
down
on
a
shared
document
and
barbara
will
help
and
fill
in
bits
if
you
missed
where.
But
we
need
someone
to
do
this.
B
A
If
you
haven't
read
that
I
highly
encourage
you
to
in
a
nutshell,
it
says,
be
nice,
be
kind,
be
professional
and
anyone
who
doesn't
follow
these.
You
know
whether
in
the
chat
or
on
the
microphone
or
on
the
list
will
be
asked
to
leave.
So
we
have
never
had
a
problem
in
this
working
group,
but
just
want
to
always
highlight
this
okay.
So
as
as
we
mentioned,
we
are
looking
for
a
volunteer
from
the
audience
to
take
minutes
and
we
can't
start
the
session
without
one.
A
Thank
you
so
much
that
is
extremely
appreciated
and
barbara
will
be
there
to
assist.
I
can
take
care
of
jabber
scribing
because,
like
with
the
meet
echo
chat,
that
is
a
very
small
responsibility
anymore,
and
so,
but
if
you
want
to
say
something
and
you
don't
like
want
or
don't
have
a
microphone,
you
can
say
mick
mic
colon
in
the
chat
and
I
will
repeat
what
you
said
for
you
all
right
here
are
some
useful
links.
If
you're
looking
at
the
pdf
later
that
you
can
click
on.
A
As
a
reminder,
we
have
a
working
group,
github
organization
in
other
working
groups.
The
switch
to
github
has
been
incredibly
useful
for
tracking
comments
on
documents.
I
personally
really
enjoy
it,
because
it's
very
easy,
with
email
to
like
forget
one
of
the
12
comments
that
were
sent
to
one
email,
whereas
if
they're
issues,
it's
pretty
clear
when
the
issue
is
still
open,
that
you
need
to
address
it,
this
we're
not
forcing
anyone
to
use
github.
It
is
the
responsibility
of
the
editors
of
a
given
document
to
choose
if
they
want
to
use
it
or
not.
A
We
have
some
news
today,
so
I'd
like
to
introduce
our
new
co-chair
chris
box,
so
thanks
chris
for
stepping
up
to
join
dnssd,
looking
forward
to
all
working
together,
and
the
sad
news,
unfortunately,
is
that
barbara
is
stepping
down
at
the
end
of
this
meeting.
So
I
would,
if
you're
so
inclined,
please
unmute
and
join
me
in
a
round
of
applause
for
barbara's
three
years
of
service
thanks
so
much
barbara.
It's
been
great
co-chairing
with
you.
B
A
In
terms
of
working
group
adopted
document
status,
we
currently
have
three
documents,
so
the
one
that
we've
had
for
the
longest
time
is
srp.
It's.
We
started
working
group
last
call
in
july,
so
this
one's
almost
done.
We
had
a
recent
round
and
recent
revision,
which
addressed
those
comments
a
few
weeks
ago
and
some
more
comments
since
then,
so
that
one
seems
to
be
pretty
close.
We're
mainly
waiting
on
you
know,
authors
addressing
comments
to
make
progress
on
them
here.
A
We
did,
however,
notice
a
bit
late
in
the
game
that
that
draft
had
a
normative
reference
on
an
individual
draft
which
would
block
publication.
So
we
adopted
that
individual
draft,
which
is
the
second
item
here,
the
update
lease
in
september-
and
there
were
so
we're
right
now
we're
waiting
on
the
on
the
editors
to
take
into
account
some
comments
that
were
made
during
the
adoption
call
and
then
the
third
one
is
the
advertising
proxy
document
which
we
adopted.
A
A
The
first
two
at
the
top
on
replication
and
discovery
of
zones
were
first
published,
like
at
the
last
meeting
in
a
little
bit
discussed
there,
and
then
we
have
a
new
one
that
ted
just
published
a
few
weeks
ago,
and
our
agenda
really
flows
from
this
list
of
documents.
We're
going
to
start
off
with
the
three
that
are
that
are
adopted
by
the
working
group
and
then,
with
the
time
remaining,
the
three
that
are
individual
drafts.
A
A
A
D
D
Conveniently
there
is
already
another
document,
so
so
just
a
few
things
about
this,
so
reasons
for
removing
it,
it's
not
ready
to
go.
It's
not
really
the
same
thing
as
srp,
although
it's
related,
we
have
sorry,
we
have.
We
have
another
document.
We
could
do
it
in
really
easily
the
eds
zero
owner
option
is
basically
the
thing
that
was
originally
done
to
document
the
mdns
sleep
proxy.
D
So
we
could
just
shovel
the
you
know
section
whatever
it
is
into
that
document
and
advance
that
separately,
which
I
think
would
make
sense,
and
then,
let's
see
yeah
so
and
smaller
chunks
of
work
is
good
and
yeah
eds
zero
owner
like
we
might
actually
want
to
to
be
able
to
put
that
into
into
regular
dns,
not
just
for
advertising
proxies.
So
when
I
hang
up,
that
means
I'm
not
ready
to
answer
the
phone,
not
that
I'm
bitter.
D
D
A
D
D
D
It's
you
know,
we
would
need
to
revive
it
anyway
if
we
were
going
to
advance
this
in
srp.
So
it's
not
like
you
know
we
we
might
as
well
we
might
as
well.
I
think
we
might
as
well
shovel
the
work
in
there
as
well
and
and
finish
that
as
a
separate
as
a
separate
item,
because
then
it
just
decouples
these
two
pieces
of
work.
F
A
So
it
sounds
like
what
everyone's
or
the
proposal
is
like
leave
it
out
of
this
and
then
bring
it
in
another
document
either.
You
know
revive
that
expired
one
or
or
a
separate
one
at
some
later
date.
If,
if
someone
wants
to,
is
there
any
objection
to
this
in
the
working
group
or
any
other
stops
by
the
way.
D
G
A
Sorry
so
we
are
actually
we
already
did
that
so
that
sorry,
the
sleep
proxy
section
was
removed
in
version
11
or
12
during
working
hoop
last
call,
and
when
that
version
was
submitted,
we
extended
the
working
group
last
call
by
two
weeks
and
we
are
in
the
middle
of
those
two
weeks
right
now.
So
I
should.
A
D
Kind
of
the
whole
point
of
of
bringing
this
up
here
is
just
to
make
sure
that
we
don't.
You
know
somebody
doesn't
miss
the
fact
that
we're
talking
about
removing
this
and
then
later
say
well
so
anyway,
so
the
eds
zero
update
lease
option.
This
is
basically
just
like
a
piece
of
of
plumbing
that
we
need
in
order
to
get
srp
to
work.
The
problem
is
that,
and
it's
sort
of
a
general
problem:
it's
not
just
srp
when
you
do
a
dns
update.
D
D
Srp
is
a
specific
refinement
of
dns
updates,
specifically
for
doing
sort
of
permissionless
advertising
using
dns
updates,
and
so
it's
not
the
only
dns
update
type
that
exists
and-
and
we
might
want
this
for
others
as
well.
So
we
have
this
this
new
option.
It's
got
a
lease
time
in
it.
It's
actually
got
two
lease
times
got.
D
One
is
the
lease
time
for
the
resource
record
that
you're
adding
and
the
other
is
at
least
time
for
a
key
record,
which
you
might
also
provide-
and
this
is
generally
specific
to
srp,
because
srp
uses
the
key
record
plus
60
to
authenticate
the
update
and
the
idea.
There
is
just
that
the
key
record
is
going
to
allow
us
to
keep
ownership
of
the
name.
Even
if
the
service
being
advertised
is
not
hasn't,
been
renewed
and
therefore
is
assumed
not
to
be
present.
D
So
it's
just
a
way
to
avoid
names
being
sort
of
snarfed,
just
as
the
service
that
was
advertising.
The
name
is
you
know
away
from
the
network
briefly,
so
so
that's
that's
the
basic
idea
and
then
the
document
is
in
pretty
good
shape.
I
think
david
mentioned
there
were
some
comments.
I
haven't
actually
had
a
chance
to
to
look
at
the
comments,
but
I
don't
get
the
sense
that
there's
anything
that's
likely
to
be
a
show
stopper.
D
D
So
I
think
the
document's
ready
to
read
my
personal
feeling
is
I'd
like
to
make
the
document
as
lightweight
as
possible,
but
I'm
curious
to
know
what
the
working
group
thinks
about
that
and
whether
we
can
make
progress
on
this
quickly.
If
the
working
group
wants
to
you
know,
depending
on
what
the
working
group
decides,
so
that's
kind
of
that's
kind
of
where
it's
at
I.
I
guess
I
didn't
actually
put
this
in
the
slides
because
it
didn't
occur
to
me.
But
what
does
that
I
do?
D
The
question
of
the
working
group
is
kind
of
do
we
do
we
want
to
just
like
cut
out
all
the
fat
and
progress
this
quickly
or
should
we
really
get
the
you
know,
dns
update
part
of
this
solid
so
that
we
can
publish
that?
I
don't
think
it's
a
big
problem
to
do
the
the
second.
So
I'm
not
I'm
not
really
advocating
against
that.
I'm
just
saying
you
know
there
is
some
additional
work.
If
we
go
that
route.
A
D
B
D
E
A
Is
chairs
is
to,
and
we
we
had
a
discussion
when
we
first
adopted
this
document
between
all
the
chairs
of
the
various
dns
working
groups
and
your
corresponding
ads,
and
the
conclusion
was
that
we
would
adopt
and
progress
this
document
indian
ssd,
but
that
the
working
group
last
call
would
be
sent
to
the
nsop.
Absolutely
so
that's
that's
definitely
going
to
happen
perfect.
Thank
you.
F
F
So,
instead
of
editing
his
own
file
with
vi
and
reloading
the
name
server,
you
could
use
the
ns
update
command,
but
all
the
edits
were
permanent.
There
was
sort
of
an
unstated
assumption.
It
was
being
done
by
a
human
and
what
the
update
lease
does
is.
It
makes
it
more
suitable
for
machine-to-machine
style
communication,
just
like
a
dxep
lease
has
to
be
renewed
or
it
goes
away
automatically.
F
A
Quick
background,
stuart,
that's
helpful,
so
it
sounds.
Let's
see
so
I
have
a
poll
open
if
you
like
either
it
popped
up
somewhere
on
your
screen.
Otherwise,
if
you
click
on
the
show
of
hands
tool
on
the
top
right
on
whether
or
not
you've
people
have
read
this
draft
and
I'm
going
to
end
it.
It
looks
like
we
have
nine
people
who
have
read
the
deaf,
which
is
good,
so
I
would
say
in
terms
of
next
steps.
A
I
think
the
responsibility
right
now
is
on
the
authors
to
address
the
comments
that
were
raised
during
adoption
published
a
new
revision,
mention
it
to
the
working
group
and
then
see
we
can
have
a
discussion
on
there
to
see
if
folks
like
it.
If
there's
not
too
much
contention,
we
can
then
progress
the
document
pretty
quickly
move
on
to
work
group
last
call
which
will
then
trigger
review
from
various
other
working
groups.
So
at
that
point
I
ideally
perhaps
we
have
that
timed.
A
D
D
So
the
idea
is
for
those
who
aren't
aware
the
advertising
proxy
is
a
way
that
we
can
do
srp
updates
and
then
advertise
the
result
of
those
srp
updates
using
mdns
rather
than
using
dns,
and
the
reason
for
doing
that
was
primarily
to
enable
stub
networks
to
advertise
services
on
infrastructure
networks.
So
this
stub
network
being
like
an
iot
network.
That's
just
one
hop
away
and
doesn't
have
any
transit,
but
just
provides
reachability
to
clients
that
have
different.
D
You
know
802.15.4
radios
or
something
like
that,
and
then
another
nice
feature
of
this
that
that
comes
up
is
that
it
makes
it
possible
to
to
sort
of
eliminate
using
mdns
but
still
allow,
that
is
to
say,
eliminate,
allow
a
client
to
stop
using
mdns
to
advertise
stuff,
but
allow
clients
that
do
use
mdns
to
still
discover
the
stuff.
So
those
are
kind
of
the
two
things
the
document
does.
D
It's
been
adopted,
I
haven't
uploaded
it
yet,
as
I
said
it's
in
pretty
good
shape,
but
there
are
some
issues
with
name
conflicts
that
we
haven't
really
addressed,
and
so
in
fact,
you'll
notice.
There's
a
new
document
that
I'm
proposing
the
tsr
document,
which
addresses
some
of
the
name
name
conflict
issues.
The
problem
is
that
our
model
for
for
dealing
with
name
conflicts
in
mdns
is
not
really
oriented
towards
proxies
and
I'll
talk
more
about
that
in
the
tsr
document.
D
A
Thank
you,
ted.
I'm
gonna.
Similarly,
do
a
poll
just
to
get
a
feel
for
who's.
Read
it
oh
well!
I
guess
I
forgot
to
put
a
title
sorry,
so
this
one
is:
have
you
read
this
document?
I
don't
know
where
that
window
went,
but
you
can
raise
hand
to
say
you've,
read
this
one
or
or
not
raise
well,
while
we're
doing
that.
If
anyone
has
any
questions
comments
on
this
document,
please
join
the
mic
line.
D
D
H
A
A
D
D
A
I
wanted
to
just
sounds
good
just
just
to
answer
to
that
quickly.
I
think
that's
a
great
idea,
because
I
think
you're
pretty
and
both
steward
and
you
are
bandwidth
limited
these
days,
which
I
totally
understand.
We
all
have
day
jobs,
and
so
adding
a
co-author
before
asking
for
adoption
sounds
like
a
great
idea.
It'll
definitely
give
us
more
confidence
that
the
document
will
be
worked
on.
So
that
sounds
absolutely
great.
D
Thanks
all
right
go
ahead
sure,
so
I
just
wanted
to
give
a
quick
overview
of
what
what's
going
on
here,
because
you
know
there
there's
a
lot
of
stuff
in
fly.
You
know.
Obviously,
dnssd
has
been
working
on
dnssd
generally
for
quite
a
while.
We
have
mdns
we've
had
that
since
before
the
working
group
started
dnssd
on
dns,
we
had.
These
are
all
in
the
base
document,
6762
and
6763..
D
D
So
then,
there's
srp
replication,
srp
replication
addresses
the
problem
that
when
I
started
doing
the
the
srp
work,
I
was
just
assuming
that
we
were
updating
like
by
nine
or
something
like
that.
I
wasn't
really
thinking
about
it.
In
terms
of
of
you
know,
home
networks
and
so
srp
assumes
an
authoritative
server,
but
that
turns
out
not
to
be
a
very
realistic
assumption
on
a
home
network
on
a
home
network,
the
home
router
is
usually
some
little
like.
D
Each
one
of
them
is
doing
srp
replication
if
any
one
of
them
gets
an
update.
All
of
the
other
ones
get
that
update.
It's
really
nice.
So
that's
kind
of
the
goal
of
srp
replication
is
just
to
like
fill
that
that
that
box,
in
the
block
diagram
with
something
that
doesn't
have
to
be
managed
by
a
network
administrator.
D
And
then
the
other
work
that
I'm
going
to
be
talking
about
permissionless
advertising
of
dns
zones
is
basically
once
you
have
that
stable
dns
server
or
reasonably
stable,
dns
server.
Wouldn't
it
be
nice
to
be
able
to
just
query
it
using
dns
or
dns
push
rather
than
multicast
dns.
You
can
eliminate
some
of
the
dns,
so
so,
basically,
what
this
allows
us
to
do
is
what
the
the
permissionless
advertising
work
is
going
to.
Allow
us
to
do
is
to
allow
dnssd
clients
to
query
srp.
D
D
It
didn't
just
come
from
a
rogue
srp
replication
server.
So
that's
kind
of
why
I
invented
a
new
protocol,
sorry,
so
the
new
protocol.
The
idea
is
that
there's
an
arbitrary
number
of
srp
replication
peers
which
can
come
and
go.
We
could
limit
the
number
if
we
wanted
to,
and
I
think
that
might
make
sense.
But
I
don't
know
what
the
limit
would
be.
There
is
no
authority
we're
trying
to
maintain
a
common
data
set.
D
D
We
can
identify
the
client
using
crypto
because
it
has
a
public
key.
So
we
know
if
we
get
an
update.
We
know
that
it's
from
the
same
client
or
that
it's
not
from
the
same
client
for
any
given
host
record,
and
we
know
when
we
got
the
update.
So
so,
if
a
client
sends
an
update,
it's
either
newer
than
what
we
have
or
it's
older
than
we.
D
But
if
we
received
an
srp
update,
it's
always
going
to
be
newer
than
what
we
have
so
so
essentially,
the
the
client
winds
up
being
the
authoritative
server
for
its
data,
and
we
just
maintain
this
data
set.
We
try
to
keep
the
data
set
in
sync:
it's
not
a
catastrophe.
If
it's
not
in
sync
the
worst
case
scenario,
if
we,
if
we
totally
lose
a
client
update,
is
that
we'll
get
that
information
the
next
time
the
client
renews?
D
D
D
So
so
you
guys
can
read
the
slide
again
later,
if
you,
if
you
want
to
get
more
details,
but
that's
the
basic
idea
so
so
the
flow
of
the
protocol
is
that
first,
when
an
srp
server
comes
online,
it
needs
to
figure
out
what
data
set.
It's
replicating
and
that's
somewhat
situationally
dependent
and
there's
some
language
in
the
document
that
talks
about
how
to
do
that.
But
but
it
may
be
implementation
dependent.
D
We
can't
necessarily
specify
it
in
full
detail
or
there
may
be
sort
of
documents
that
specify
like,
if
you're
trying
to
do
srp
replication
in
this
situation.
This
is
what
it
looks
like
so
in
other
words,
for
example,
the
stub
networks
document's
probably
going
to
have
some
text
about
that.
So
we
choose
a
data
set.
We
try
to
find
srp
replication
peers
that
are
replicating
that
data
set
and
if
we
find
them,
then
we
start
we
just
join
in.
D
D
So
so
and
the
other
thing
is
it's
possible
that
that
an
srp
replication
peer
might
have
gotten
an
update,
replicated
it
around
and
then
gone
offline,
and
so
during
rep
during
during
the
reconciliation
process.
Those
updates
are
still
going
to
be
part
of
the
reconciliation
process,
even
though
they
weren't
received
by
the
server.
D
We
don't
expect
this
to
happen
a
lot,
but
you
know
happens
from
time
to
time,
and
during
this
period
we
don't
do
secondhand
updates,
because
at
this
point
these
are
live
updates.
So
so,
if
something
goes
wrong
in
this
process,
it's
basically
going
to
have
to
be
resolved
at
the
srp
level,
not
at
the
replication
level.
But
generally
speaking,
it's
you
know.
Usually
stuff
won't
go
wrong
in
the
situation.
D
D
When
you're
inventing
new
protocols,
open
thread
has
done
an
implementation,
I
haven't
looked
at
the
implementation
yet,
but
I've
had
some
conversations
with
the
implementers
and
it
sounds
like
they're
doing
a
great
job
and
I'm
looking
forward
to
us
doing
some
interop
at
some
point.
So
so,
basically
I
don't
know
if
I
put
it.
No
that's
so.
Basically,
my
goal
is
to
ultimately
get
this
work
adopted
by
the
working
group.
This
is
probably
the
biggest
ask
that
I'm
ever
going
to
make
of
this
working
group,
because
this
is
a
fairly
complicated
spec.
D
D
You
know
david
made
the
good
point
that
we
don't
want
to
overload
the
working
group
given
how
many
people
are
participating,
but
but
this
is
to
me
it
seems
clear.
This
is
the
place
to
do
the
work.
So
basically,
this
is
kind
of
your
fair
warning
that
this
is
there's
I'm
going
to
be
asking
for
adoption
at
some
point.
You
know
if
I
thought
or
if
I
thought
david
wouldn't
laugh
at
me.
I
would
ask
for
adoption
now,
but
he'll
probably
laugh
at
me.
So
so
that's
where
we
are.
A
That
that
sounds
good
from
the
church
perspective.
I'd,
say:
yeah,
let's.
If,
if
you
could
prioritize
going
through
the
action
items
you
have
on
the
adopted
working
group
drafts
and
those
look
like
they're,
no
longer
blocked
on
you
and
making
good
progress,
then
I
think
you
know
then,
and
taking
a
co-author
then
bringing
this
back.
I
think
the
problem
there
should
be
appetite
at
that
point
as
long.
A
Know
as
long
as
my
only
concern
is,
I
want
to
make
sure
that
this
new
work
doesn't
delay
the
existing
work.
But
as
long
as
it
doesn't
do
that,
assuming
there
are
multiple
folks
from
different
affiliations
that
are
interested,
then
we
can
definitely
consider
adopting
this
I'll
double
check
the
charter.
But
I'm
I'm
not
yet
worried
I'll
double
check
that
with
our
id
and
everything.
D
D
D
D
So
so
we
we
still
using
mdns,
but
we're
only
doing
one
query
instead
of
50..
So
it's
a
big
improvement
and
also
like
you
know,
if
you're,
if
you're,
using
a
device
that
sleeps
a
lot
your
iphone
or
your
watch
or
you
know,
I'm
sure
there
are
equivalent
products
and
other
from
other
companies.
Then
dns
push
is
a
much
it's
much
easier
to
make
that
work.
D
Even
if
you
have
to
re-establish
a
connection
every
time
you
wake
up,
you
can
get
a
complete
list
of
all
of
the
data
that
you
want
to
know
about
very
easily.
But
ideally,
the
connection
just
survives
your
sleeps,
because
you're
sleeping
momentarily
right,
you're,
like
sleeping
for
a
second
at
a
time
and
waking
up
every
second
or
something
like
that,
and
so
so
when
there's
an
update,
you'll
just
get
it
as
soon
as
you
reconnect
and
the
wi-fi
the
wi-fi
base
station
will
probably
have
remembered
it
for
you.
D
F
Just
add
something
which
I
don't
think
you
actually
said.
The
idea
here
is
that,
instead
of
multicasting
a
query
to
every
device
on
the
network,
the
client
that
wants
to
do
discovery
talks
to
a
server
using
unicast,
which
is
much
more
efficient
on
wi-fi,
and
the
bootstrapping
issue
is:
how
does
it
figure
out
what
entity
on
the
network
is
the
unicast
server?
It
should
be
talking
to.
D
So
therefore,
we'll
allocate
a
zone,
that's
only
for
this
purpose,
and
so
it'll
just
be
devices
that
are
doing
the
same
thing
competing
with
each
other
and
if
one
of
them
is
malicious,
that's
not
great,
but
at
least
it's
not
going
to
be
able
to,
like
you
know,
do
a
man-in-the-middle
attack
on
your
bank
transaction
or
something
like
that.
So
and
then,
basically
the
idea
is
you
advertise
data.
D
Sets
that
you
have
so
you
might
have
an
srp
database
data
set
if
you're
doing
srp
replication,
you
might
have
one
or
more
discovery
proxy
links,
and
so,
if
you
have
any
of
those
you
just
advertise
them
with
mdns,
the
client
goes
out
and
tries
to
find
the
list
of
zones
that
that
have
data
sets.
It
cares
about,
and
and
then
so,
when
a
when
a
dnssd
query
comes
in
that,
doesn't
specify
what
domain
to
look
in
you.
You
know.
D
The
current
implementation
is
not
doing
exactly
what
I
think
we
should
do.
It's
using
ns
records
and
advertising
legacy
browsing
domains
and
it
only
works
with
mdns,
and
my
for
you
know,
after
after
having
played
with
that
for
a
while,
I
came
to
the
conclusion
that
we
probably
wanted
to
just
advertise
this
as
a
service,
so
the
service
will
say
hi,
I'm
a
service
that
that
does
you
know
you
can
use
to
do
to
do.
D
A
A
A
D
Everyone
so-
and
that's
that's
the
intention-
my
goal
here
is
actually
to
to
so
remember
like
I
was
trying
to
do
the
home
net
naming
architecture
back
in
the
day
and
that
basically
failed
because
we
tried
to
bite
off
too
big
a
chunk
at
once.
So
what
I'm
trying
to
do
is
address
each
of
the
things
that
we
want
the
home
net
naming
architecture
to
do
piecemeal,
so
you
could
say:
well
you
know
it's
a
matter
specific
thing,
but
no
it's
not!
D
The
idea
is
to
to
fill
in
all
of
those
little
building
blocks
so
that
then
we
get
to
the
point
where
we
actually
can
have
what
we
were
trying
to
do
in
the
beginning
with
the
naming
architecture.
So
so
it's
more
that
I'm
using
matter
as
an
excuse
to
to
to
to
succeed
in
this
hobby.
Then
it
is
the
opposite,
but
that.
A
F
F
Thread
is
being
used
by
mata,
which
used
to
go
by
the
working
title
project
chip
connected
home
over
ip,
and
that
work
is
done
by
the
csa.
The
connectivity
standards
alliance,
which
also
changed
its
name,
that
used
to
be
the
zigbee
alliance,
and
it
changed
its
name
recently
to
reflect
its
new
focus
on
ip
technologies,
so
mata
will
be
using
thread
as
one
of
its
lower
layers.
F
It's
also
using
wi-fi
people
in
mata
are
looking
at
the
work
done
on
thread
using
unicast
discovery,
to
make
it
more
reliable
and
less
expensive
on
the
network,
and
there's
now
been
discussions
about,
we
should
do
the
same
for
wi-fi.
Wi-Fi
access
points
should
all
have
srp
servers
in
them,
so
I'm
not
pre-announcing
anything
there,
because
this
is
a
long
way
from
being
done,
but
there's
already
discussions
going
on
there
that
mata
would
like
to
see
wi-fi
doing.
A
Thanks
for
the
backup,
stuart
and
thanks
for
like
doing
that,
work,
I
think
having
a
fresh
set
of
new
eyes
and
new
ideas
in
the
working
group
is
always
a
good
thing.
So
that's
what
we're
looking
for
in
terms
of
bringing
new
work,
great,
all
right!
So
ted!
You
have
your
last
document.
We
have
four
minutes
left
and
I
want
to
keep
like
one
for
the
chairs.
So
if
you
could
just
zoom
through
it,
please
go
ahead.
D
D
Mdns
assumes
that
if
something
has
registered
a
service
and
something
else
comes
along
and
tries
to
ever
register
a
service
under
the
same
name,
that
the
something
else
is
the
interloper
and
should
be
rejected
and
the
original
should
stay,
but
with
a
proxy,
the
new
update
is
we're
able
to
validate
with
srp
that
it
came
from
the
same
device.
So
it's
not
an
interloper,
it's
the
same
device,
but
we
still
get
a
conflict,
and
so
the
idea
is
in
the
case
of
proxies
to
have
a
resource
record.
D
Then
it's
going
to
not
report
a
conflict
because
the
new
and
the
information
is
newer
and
so
it'll
ultimately
just
drop
the
information,
the
stale
information
that
it
has
and
allow
the
new
information
to
be
advertised
and
with
srp
replication.
Of
course.
Ultimately,
both
of
them
will
wind
up
advertising
the
same
information,
but
this
gives
us
this
just
prevents
all
these
messy
conflicts
that
can
occur
and
the
renamings
that
can
occur
so
so,
as
requested.
I
don't
think,
there's
a
reason
to
go
into
too
much
more
detail
about
that.
D
The
slides
are
up
on
the
on
the
server
and,
of
course,
you
can
read
the
document
which
I
think
explains
the
situation
pretty
well.
So
the
request
to
the
working
group
is
to
take
a
look
at
this.
It's
pretty
simple.
I
think
it's
pretty
necessary
for
actually
for
the
advertising
proxy
work.
So
I
think
we
we
want
to
include
this
in
the
advertising
proxy
work,
but
I
don't
think
this
is
a
really
big
task
for
the
working
group.
D
A
All
right,
thank
you,
ted
we're
gonna,
take
questions
on
this
specific
presentation
to
the
list,
boop
and
then
put
these
back.
There
done
all
right
so
and
I
think
same
kind
of
conclusion
as
the
other
ones
ted.
This
looks
interesting.
It
appears
to
be
in
scope,
especially
if,
in
the
context
of
advertising
proxy,
if
the
working
group
thinks
that
advertising
processes
should
have
a
dependency
on
this
that'll
help
motivate
bring
it
in
but
similar
to
the
previous
ones.
A
We
want
to
see
progress
on
the
other
drafts
and
we
would
love
to
see
some
co-authorship
with
diversity
of
affiliation.
All
right
thanks.
Everyone
for
joining
our
dnssd
session
and
this
great
ietf
week
now
comes
to
an
end.
We're
all
going
to
be
able
to
sleep.
It's
going
to
be
amazing
and
best
parting
words
see
you
all
on
the
list
and
thanks
so
much
barbara
for
everything
we're
going
to
miss
you
here,
and
I
hope
you
still
show
up,
even
if
you're,
not
in
the
at
the
chair
table.