►
From YouTube: IETF110-DNSSD-20210312-1200
Description
DNSSD meeting session at IETF110
2021/03/12 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
I'll
I'll,
let
me
finish
up
this
just
one
second,.
B
B
E
E
B
C
Thank
you,
stuart
much
appreciated
and
so
there's
a
kodia
md
link
from
the
data
tracker
and
if
anyone
else
wants
to
help
stir
it
out
or
take
notes,
while
stewart
is
talking,
please
go
and
lend
him
a
hand.
That
would
be
helpful.
B
Okay-
and
that
is
the
really
small
agenda
wow,
thank
you,
and
so
we're
going
to
be
starting
with
dns
sd
and
just
a
quick
status.
We
do
within
the
nssd
have
some
drafts.
B
That
ted
did
update,
let's
see
and
we're
going
to
be
starting
with
ted,
and
so
I
need
to
pull
down
ted's
slides
so
that
I
can
present
them.
C
All
right
should
I
do
the
the
intro.
B
C
Could
ever
scrap
I'm
already
in
there
and
I'll
keep
an
eye
on
it
and,
as
usual
folk,
if
you
wanna
or
I'll
type
it
in
the.
F
B
F
Yes,
I've
not
used
this
before
it
tells
me
visit,
slash
features.
If
you
don't
know
what
to
do
happy
hacking,
it
seems
like
a
bit
of
a
text.
Adventure,
game.
B
B
B
B
There
now
is
there
any
way
I
can
I'm
sharing
through
the
browser.
I
hope
it's
just
large
enough.
C
While
you
figure
that
out,
maybe
ted
should
get
started
there,
we
go.
B
B
C
Yes,
stewart's
taking
notes;
okay,
thank
you,
stuart
and
ted.
If
you
go
into
the
audio
midi
setup,
app,
maybe
you're
on
the
wrong
microphone
or
maybe
just
in
the
mid
echo
settings.
E
G
B
Yes,
maybe
just
if
you
could
have
a
little
more
volume
on
your
mic
or
phone,
but
if
not
that's
okay,.
G
Let's
hope
that
I'm
actually
intelligible
when
I
start
talking,
so
I
actually
have
been
doing
a
whole
bunch
of
work.
That
is,
a
combination
of
home
net
and
dns
sd
related
work,
or
at
least
so.
I
claim
and.
G
So
can
you
guys
still
hear
me
my
all
of
the
video
just
died,
yeah.
G
B
G
Working
on
on
this
sort
of
project-
that's
that's
involved
a
bunch
of
stuff
having
to
do
with
with
home
net
and
dnssd,
and
so
this
presentation
is
actually
a
combined
presentation
with
all
of
the
stuff.
That's
on
the
agenda
for
both
working
groups
in
the
same
presentation
because
they're
deeply
interrelated.
G
I'm
there's
a
question
in
the
air
as
to
whether
some
of
this
work
is
home
network
or
whether
it's
not
partly
because
homenet
has
been
fairly
inactive
for
a
long
time,
and
so
it's
not
clear
that
there's
that
there
are
people
in
the
home
networking
group
that
would
like
to
work
on
this.
So
that's
something
we
need
to
explore,
but
it's
certainly
topical
for
home
that
and
it
comes
out
of
the
work
that
I
did
in
homenet
several
years
ago.
B
B
Yeah
and
it's
just
that,
I'm
pushing
buttons
for
my
slides
to
progress
but
they're,
not
oh
okay.
There
we
go
barbara.
G
E
D
D
D
B
Okay,
now
it's
sending
audio
really,
okay,
so
yeah!
I
was
about
to
discuss
that
with
head,
because
we
just
got
the
slides
well
rather
late
for
me
from
ted.
I
think.
C
Is
offering
to
present,
which
might
make
it
easier?
How
about
we
let
him?
What
do
you
think
barbara.
G
I
don't
know
what's
going
on,
like
I'm
just
having
the
worst
trouble
here.
I'm
hearing
you
through
my
computer
speakers,
not
through
my
headphone
speakers
for
some
reason.
B
B
I
noticed
that
your
dns
sd
update,
slides,
were
kind
of
embedded
in
the
middle
of
this
presentation.
D
G
The
slides,
but
I
was
like
I've-
just
been
completely
maxed.
So
can
you
go
back
one
slide?
G
G
So
what
I've
been
working
on
has
been
so
so
srp
is
actually
very
mature
at
this
point
and
is
able
to
be
used
by
so
the
use
case
that
we
have
right
now
is
iot
devices
registering
for
to
be
able
to
be
discovered
and
that's
that's
been
working.
G
We
had
an
independent
implementation
that
was
done
recently,
and
so
that's
that's,
really
quite
a
long
ways
along
and
I
think
it's
actually
pretty
close
to
ready
for
a
working
group
last
call
and
I'll
hit
that
on
another
slide,
I'm
just
going
to
give
you
the
overview
here
now.
So
the
service
registration
protocol
is
about
getting
information
into
the
dns
database.
G
That's
pretty
much
done
at
this
point.
The
work
that's
been
going
on
that
went
on
last
year.
Was
the
advertising
proxy
getting
an
advertising
proxy
which
can
advertise
what's
in
that
database
on
a
link?
So
the
idea
is,
you
have
you
know?
Normally
we
do
dnssd
with
multicast
dns,
because
it's
really
easy,
it's
permissionless,
etc,
but
that
doesn't
work
when
you're
going
across
subnet
boundaries,
and
that
was
one
of
the
issues
we
ran
into
when
we
tried
to
deploy
it
in
homenet.
G
So
srp
is
a
way
to
do
dnssd
advertisements,
that's
that
doesn't
rely
on
on
multicast
cns
and,
however,
the
reality
is
right.
Now
all
of
our
clients
are
doing
multicast
dns,
and
so
so
we
needed
a
way
to
and
and
by
the
way,
there's
no
way
to
to
permissionlessly
incorporate
a
new
dns
zone
into
your
into
your
network
configuration.
So
so
we
have
to
use
multicast
dns
for
advertising
right
now,
so
the
advertising
proxy
is
sort
of
the
other
half
of
the
service
registration
protocol.
G
It's
like
now,
we've
now
we've
got
the
database.
How
does
somebody
find
something
in
the
database
right
now
we're
doing
that
with
dns
multicast
dns?
So
that's
the
advertising
proxy
stuart
did
a
version
of
that
document
and
it's
pretty
complete,
but
it's
not
sufficiently
detailed.
G
So
that
needs
a
fair
amount
of
work
and
then
additional
work
that's
been
going
on
this
year
is
so
srp
was
originally
envisioned
as
something
for
updating,
stateful
dns
servers
and
the
idea
is
a
stable
dns
server
has
like
you
know
it's
on
some
kind
of
reasonably
sizable
computer.
There's
a
disk
drive
or
some
kind
of
flash
memory
to
store
information,
and
so
you
just
do
the
dns
update
and
then
you
can
do
dns
lookups
to
that
server
problem
is
in
reality.
G
When
you
go
to
try
and
deploy
this
there
aren't
any
dns
servers
like
that
in
homes,
and
so
in
order
to
make
this
work
in
homes,
we
need
something.
That's
equivalently,
hopefully
equivalently
stable
to
a
stateful
dns
server
but
is
not
doesn't
doesn't
require
that
there
be
support
on
the
home
router,
and
so
the
way
that
we
did,
that
is
the
idea
is
that
you
probably
have
multiple
stub
routers
in
your
home.
That
you
know
the
example
that
I
would
use
right
now
would
be
a
homepod
mini.
G
All
right
so
homemade
midi
is
a
subrouter
for
thread
networks,
so
you
have
multiple
subrouters
in
your
home
is
possible
at
any
given
time
that
one
of
those
subrouters
might
get
unplugged
or
whatever,
but
hopefully
at
any
given
time
at
least
one
of
them
will
be
alive.
So
all
of
the
service
registrations
that
occur
can
be
maintained
by
doing
replication
so
that
all
of
the
stub
routers
in
your
home
network
are
sharing
the
information
that
they're
getting
from
srp
registrations.
G
Any
one
of
the
sub
routers
goes
down
the
other
stub
routers
take
over
for
it.
You
know
seamlessly,
so
so
that's
that's!
The
goal
of
replication
is
for
all
the
stub
routers
or
doesn't
have
to
be
stub
routers,
but
that's
the
use
case.
We
have
right
now
for
all
the
subrouters
in
the
home
network
to
have
the
same
data
so
that
if
any
stub
right
any
one
stub
rubber
goes
away.
G
We
don't
lose
everything,
and
then
the
next
issue
that
we
that
that
I
want
to
talk
about
is
the
problem
of
doing
too
much
multicast.
So
suppose.
You've
got
like
an
iot
network
with,
say,
50
light
bulbs
on
it
and
or
you
know,
obviously
it's
not
all
giving
light
bulbs,
but
but
just
as
an
example,
50
light
bulbs.
G
Now,
when
you
try
to
use
an
advertising
proxy
to
advertise
those
50
light
bulbs,
you
may
find
that
you,
your
performance,
isn't
that
great,
because
advertising
proxies
are
using
multicast
and
now
we've
got
big
chunks
of
data
that
we're
trying
to
transfer
over
multicast
and
also
multicast
dns,
really
wasn't
designed
with
the
idea
in
mind
of
having
a
single
server
with
50
answers,
and
so
in
order
to
work
around
that
we
I've
been
working.
G
Actually
one
of
my
colleagues
have
been
working
on
a
feature
to
add
the
ability
to
discover
an
actual
dns
server
using
using
mdns.
So
so
that's
the
those
are
the
four
pieces
that
I
wanted
to
talk
about.
So
let's
go
to
the
next
slide.
G
Okay,
so
yeah,
so
so
this
is
this
is
this:
is
that
problem?
When
you
have
a
lot
of
devices
behind
a
stub
router,
the
answers
get
really
big.
It's
not
scalable.
G
Can
we
use
multicast
more
efficiently,
so,
rather
than
using
multicast
to
transfer
all
the
data?
Can
we
just
use
multicast
to
discover
the
place
where
the
data
is
and
then
use
unicast
to
get
the
data?
G
So
what
we
implemented
was
exactly
that
we
have.
We
basically
just
advertise
an
ns
record
for
whatever
zone
it
is
on
the
local
network
using
multicast
dns,
and
you
know
we
exclude
actual
real
dns
domains
so
that
we
don't
find
ourselves
answering
questions
about.
G
You
know
you
know,
bank
of
america.com
or
something
bad
like
that,
and
and
then
once
we've
once
we
get
that
ns
record
advertisement
over
multicast
dns,
we
can
get
the
the
a
record
also
over
multicast
dns
or
the
quad
a
record,
and
now
we
have
a
connection
to
a
dns
server
that
will
answer
for
that
zone.
G
So
this
is
something
that
we've
been
working
on
for
a
while.
This
year
we
have
one
implementation,
it's
in
the
mdns
responder
project.
That's
not
actually
been
pushed
out
yet,
but
it'll
be
pushed
out
soon
and
we
have
actually
a
fairly
good
document,
but
I
haven't
gotten
around
to
turning
it
into
an
internet
draft.
It's
actually
an
internal
design
dock
that
needs
to
be
turned
into
an
internet
draft.
So
this
is
work
that
I'd
like
the
dnssd
working
group.
To
consider.
G
I
think
this
is
a
really
useful
thing
to
be
able
to
do
it'd
be
nice
to
have
more
eyes
on
it.
I
think
it's
relatively
harmless
in
the
sense
that
we're
essentially
advertising
only
zones
that
you
would
the
only
information
that
you
would
typically
be
discovering
with
multicast
dns.
G
So
the
fact
that
we're
you
know
advertising
the
availability
of
a
dns
server
using
multicast
dns,
which
is
not
in
any
way
secure,
might
sound
a
little
alarming,
but
but
the
actual
thing
we're
doing
is
just
replacing
existing
multicast
dns
servers
with
that
dns
server.
So
let's
go
to
the
next
slide.
G
Okay,
so
service
registration
protocol,
as
I
mentioned
earlier,
we've
got
two
open
source
implementations.
I
did
an
implementation
about
two
years
ago,
which
matured
into
what
was
released
in
the
homepod
mini
and
then
independently.
Some
folks
at
google
did
a
very
nice
implementation,
open
thread
which
is
pretty
complete
at
this
point,
and
you,
if
you
were
following
the
mailing
list,
you
saw
the
comments
that
those
guys
had
on
the
document,
and
so
we
made
quite
a
few
improvements
to
the
document.
G
The
documents
had
tons
of
review.
We've
actually
got
deployed
versions
of
this
protocol
and
you
know
so
server
and
the
homepod
mini,
and
there
are
a
bunch
of
home
accessories
that
implement
it,
like
you
know,
eve
you've,
sensors
and
now
leaf
light
bulbs.
So
I
think
this
document
is
pretty
close
to
ready,
for
your
last
call
probably
needs
one
more
revision,
but
I
think
if
the
working
group
is
willing,
I'd
really
like
to
see
this
finished.
B
For
argument,
when
you're
well
yeah
we'll
open
up
the
queue
for
argument,
don't
worry.
G
Okay
cool,
so
so
I
mentioned
the
advertising
proxy
already
stateless.
It's
a
stateless,
srp
registration
database
that
advertises
its
contents
over
mdns
or
dnssd.
We
have
an
implementation,
mdns
responder.
I
think
the
open
thread
guys
did
one
too,
but
I'm
not
sure
where
that,
where
that
is
in
terms
of
maturity,
the
advertising
proxy
spec
needs.
A
bunch
of
work
definitely
would
appreciate
people
reading
it,
and
I'd
also
like
to
ask
the
working
group
to
consider
adopting
it
next
slide.
G
Okay
and
then
srp
replication-
I
pretty
much
already
gave
you
this
feel
on
this.
So
it's
a
it's
a
it's
a
my
implementation
is
a
state
machine
that
that
you
know
that
runs
through
the
srp
database
on
on
the
local
server
and
proposes
updates
to
the
remote
server.
G
The
road
server
does
the
same
thing
after
after
all,
of
those
updates
have
been
done,
and
principally
you're
in
sync,
it's
possible
that
there
might
be
conflicts
because
the
if
the
two
servers
had
been
operating
independently,
one
of
them
might
have
received
an
update,
that's
incompatible
with
an
update
that
the
other
one
received.
In
that
case,
there
needs
to
be
some
kind
of
conflict
resolution,
but
we
also
try
to
do
conflict
avoidance.
So
when
an
update
comes
in,
we
attempt
to
update
the
other
server
before
we
acknowledge
the
update.
G
So
if
the
other
server
has
a
conflict,
we
can
report
the
conflict
back
to
the
client
and
resolve
it
that
way.
Obviously,
we
can't
wait
forever
for
that,
but
this
gives
us
a
nice,
the
nice
quality
that
that
most
of
the
time
we
can
expect
things
to
work
correctly.
Occasionally,
we'll
see
some
glitches,
but
they
should
resolve
quickly.
You
know
within
within
the
least
time
of
an
srp
update,
so
the
goal
here
is
not
perfection.
G
The
goal
is
to
make
something
that
works
really
well
and
and
that,
when
it
fails,
fails
in
a
way
that
that
ultimately
produces,
you
know
a
good
result,
that
is
to
say,
the
failure
gets,
gets
sort
of
automatically
cleaned
up.
G
So
the
experience
you
would
have
on
this
is
basically
just
that
you
know
you're
going
to
see-
hopefully,
hopefully
right
now,
with
the
existing
srp
implementation,
you're,
not
seeing
a
whole
lot
of
instability
with
with
name
registrations,
but
this
will
make
the
name
registrations
a
whole
bunch
more
stable,
so
you
get
better
reliability,
better
user
experience.
G
I
haven't
described
this
this
thing
to
anyone
else.
So,
as
far
as
I
know,
it
would
be
kind
of
surprising
if
anybody
else
has
done
an
implementation.
I
need
to
write
a
document.
I
have
a
an
outline
of
a
document,
but
I
haven't
written
a
document
yet,
but
it
just
describes
what
the
protocol
does.
I
think
the
protocol
probably
needs
a
whole
bunch
of
eyes
on
it.
I
think
it
would
be
good
to
get
some
criticism
of
it
after
having
done
the
implementation.
G
I
already
had
some
ideas
for
what
I
would
do
differently
and
it's
not
casting
concrete
at
this
point,
so
it'd
be
great
to
to
to
get
some
working
group
eyes
on
that.
So
that's
that's
my
next
thing
and
the
next
slide.
G
G
No
that's
it,
so
I
guess
at
this
point
this
will
be
the
time
to
discuss
these
these
slides
and
whether
the
working
group's
interested
in
this
work.
B
Okay,
so,
as
you
said,
oh
yeah,
I
got
audio.
There
was
a
whole
lot
of
discussion
on.
I
guess
it
was
the
srp
draft
and
I'd
like
to
yeah
open
up
the
microphone
for
anybody
who
has
further
comments
or
who
would
like
to
voice
their
support.
Ted
has
asked
that
this
go
to
working
group
last
call.
So
if
you
have
technical
comments
or
questions
on
the
srp
replication
or
if
you
have
administrative
comments
like
we
would
love
to
see,
this
go
to
last
call
and
we
think
it's
ready.
That
would
be
welcome.
B
Since
ted
is
here,
the
mic
is
also
open
for
the
other
drafts.
There's
the
draft
you'd
like
to
suggest
that
we
adopt,
and
then
I
think
you
know
just
technical
comments
on
the
srp
replication,
because
that's
not
ready
for
adoption
or
anything.
So
my
line
is
open.
G
No,
that's
that's
basically,
work
that
I
have
just
been
working
on
it's
it's
the
reason
why
these
slides
are
so
okay,
why
do
slides
were
so
late,
so
yeah
that
that
I
have
a?
I
have
an
outline
of
a
document
that
describes
the
current
implementation
and
I
should
be
able
to
get
that
ready
within
the
next
month.
So
so
that's
that's
the
level
of
maturity
right
now,
which
is
to
say
not
much.
I
Okay,
so
that's
that's
coming
up
yeah
and
then
for
srp.
I
had
one
one
thing
in
mind:
you
mentioned
that
before
the
working
group
last
call
could
be
done.
You
wanted
to
have
probably
one
more
vision,
right,
yeah
and
I
think
that
that
at
least
fits
well
in
my
schedule,
because
I
would
like
to
check
the
latest
version
to
see
if
the
the
review
comments
I
had
or
addressed.
So
I
didn't
get
around
that
yet.
Okay,
maybe
I
can
do
that
just
before
the
the
next
revision.
G
Yeah
yeah,
I
I'd
like
to
get
that
one
revised
quickly
and
get
it
to
last
call
quickly.
We've
done
a
whole
bunch
of
work
on
it,
people
it's
in
people's
cash
right
now.
I
don't
want
it
to
fall
out
of
everybody's
cash.
So
so,
basically,
and
then
speaking
of
falling
out
of
cash,
I
think
there
are
a
little.
There
are
a
few
more
edits.
I
need
to
make
to
the
document
based
on
the
most
recent
comments
about
deletion
of
srp
updates,
but
I
haven't
I'm
not
positive.
G
But
let
me
just
do
a
pass
through
my
mailbox
and
make
sure
that
before
and
then
you
know,
if
that's
the
case,
I'll
do
a
rev
and
then
you
can
look
at
the
at
that
document
and
review
that
document,
and
you
know,
working
with
last
call
doesn't
mean
we're
done
working
group
last
call
is,
please
review
this
document
one
more
time,
so
it
would
be
perfectly
fine
if
you
were
here
at
that
point,.
G
C
Sounds
good
and
for
the
other
documents
before
we
even
start
talking
about
adoption,
we
would
like
to
know
that
the
document
exists
so.
B
G
B
Yep
eric
you
have
something
you'd
like
to
say.
D
G
Yeah
so
yeah,
I
can
talk
about
that
a
bit.
It's
actually
implemented
using
dns
stateful
operations.
I
thought
about
using
zone
transfers
for
this,
but
the
problem
is
zone
transfers.
The
way
that
zone
transfers
work
is
that
they
rely
on
a
on
an
agreed-upon
serial
number
for
the
zone,
and
so
basically
that
makes
zone
transfers
work
really
well,
because
when
somebody
says
you
know,
I
have
this
serial
number,
can
you
can
you
give
me
everything?
That's
changed
since
this
serial
number.
G
You
just
get
this
small
change
set
and
it's
really
clean,
but
that
doesn't
work
so
well
with
stateless
servers
because
there's
no
way
to
there.
We
don't
have
like
a
a
primary
server
in
secondaries.
Everybody
is
printing
principle
just
as
primary
as
everybody
else
or
just
as
secondary
as
everybody
else,
and
so
using
zone
transfers.
Just
didn't
look
like
it
was
going
to
work.
That's
how
I
wanted
to
do
it,
but
it
just
didn't
make
sense.
G
So
there
are
a
couple
of
assumptions
in
the
protocol
and
these
may
actually
be
bad
assumptions
and
worth
investigating.
One
of
them
is
that
there's
probably
not
a
gigantic
database,
because
if
you
have
a
gigantic
database,
you
probably
want
that
to
be
in
a
real
dns
server.
G
So
this
is
really
more
for
the
sort
of
you
know
home
environment
where
you
might
have
50
or
100
things
in
the
database,
not
thousands
or
tens
of
thousands
or
millions
of
things
in
the
database
and
so
making
the
protocol
efficient
in
the
way
that
incremental
zone
transfers
are
isn't
as
high
a
priority
because
the
you
know
you
could
get
into
a
situation
where
you
have,
you
know,
kind
of
an
n,
probably
not
n
squared,
but
maybe
n
log
n
kind
of
traversal
across
the
database
and
in
if,
if
that
was
gonna,
be
millions
of
records.
G
You
really
wouldn't
want
to
do
that.
But
that's
not
the
case
here,
so
so.
The
way
that
it
works
is
really
stupid
and
and
that's
sort
of
by
design
right.
I'm
not
trying
to
do
like
a
super
fancy.
You
know
state
synchronization
protocol
with
three
phase
commits
and
stuff
like
that,
but
but
basically
to
just
do
a
you
know,
let
me
see
what
you
have:
here's.
G
What
I
have
and,
let's
you
know
I'll,
take
the
new
things
that
I
haven't
heard
of
from
you
and,
and
you
know,
all
of
the
sort
of
the
the
things
that
you
would
be
concerned
about.
Like
you
know
what
happens
if
I
get
a
a
dns
update
or
an
update
from
from
a
server,
just
as
an
update
is
coming
in
from
a
client.
G
That's
for
the
same
record,
and
you
know
how
do
I
avoid
like,
when
I
get
an
update
from
the
server,
not
seeing
that
as
the
same
thing
that
I
have
to
send
back
to
the
other
server
and
getting
into
a
loop
that
way.
So
there's
all
kinds
of
stuff
like
that.
But
but
the
basic
replication
protocol
is
its
own
thing
and,
as
I
said,
it's
really
stupid.
It's
pretty
easy
to
implement.
G
My
state
machine
is
on
the
order
of
maybe
1500
lines
of
code
so
and
actually
I'm
kind
of
suspecting
that
it
could
be
made
simpler
and
that's
the
direction
that
I
would
tend
to
want
to
go
if
we
have
to
go
in
the
direction
of
remembering
states
so
that
we
can
do
incremental
transfers
based
on
based
on
differences
between
states.
I
think
that's
a
whole
different
topic,
possibly
an
interesting
topic,
because
we
haven't
really
solved
that
problem
for
dns
as
a
whole.
Yet,
but
that's
not
really
the
problem.
G
B
B
Just
to
gauge,
I
think
some
interest
in
it
and
if
there's
interest,
then
we
can
put
out
a
call
for
adoption,
but
I'd
like
to
at
least
see
some
discussion
on
it.
I
think
david.
What
are
your
thoughts.
C
I
definitely
agree,
I
don't
think
there's
been
enough
discussion
for
us
to
start
adoption
right
now.
So,
let's
see
ted,
if
you
can
maybe
drop
a
drum
up
some
interest
on
the
list
and
with
that
we
can
move
to
an
adoption,
call
sounds
good.
B
Replication,
okay,
and
I
think
then
that
really
is
a
summary
of
all
of
the
work
we
have
going
on
in
dnssb.
Do
we
want
you
know?
We
had
said
that
home
net
would
start
at
the
top
of
the
next
hour.
Do
we
want
to
take
a
five
minute
break
while
we
send
out
an
email
to
the
home
net
list
that
we're
going
to
be
starting
at
let's
say
at
45
past
the
hour
with
home
net
and
then
start
then.
B
Well-
and
they
can
stay
here-
your
your
stub
network
is
actually
pretty
interesting.
So
I
think
we'll
just
proceed
with
our
regular
plan,
but
we'll
I'll
send
out
an
email
to
the
home
net
list
that
will
start
at
45
minutes
past
the
hour.
We'll
take
a
small
break
and
reconvene
at
45
past
the
hour
and
get
going
on
home
net
and
stephen
is
that,
okay
with
you
two.
H
Pretty
much
yeah,
I
think
I
like
ted's
suggestion,
maybe
to
look
to
maybe
flip
the
homeless
agenda
so
that
ted's
sloth,
which
is
the
kind
of
new
thing
that
might
attract
people.
It
does
actually
start
around
the
top
of
the
hour.
So
if
you
do
daniel
michael
first,
that
might
make
more
sense
eric
does
that
kind
of
chime
with
the
interest
you
had
in
this
topic?
B
More
coffee,
okay
at
45,
let's
see.
B
Okay
and
y'all
are
all
free
to
come
back
at
45
and
I'll,
send
an
email.
B
H
So
barbara,
if
it's
some
stage
you
want
me
to
present,
then
I
can
do
that.
If
you
rather
do
that's
fine
too.
F
H
B
So
thanks:
let's
go
ahead
then,
and
get
started
home
net
session
where
session
one
not
two
but
other
than
that.
I
think
I
got
things
mostly
accurate
again.
We
are
still
under
the
note
well,
which
was
already
shown
at
the
start
of
the
dns
sd.
But
here
it
is
again
note
it
well
and
the
agenda.
B
This
was
the
overarching
agenda
for
the
two
sessions.
We
did
go
ahead
and
have
ted
lemon
talk
about
the
let's
see.
Oh
no.
This
is
just
the
home
net
agenda
right,
so
the
home
net
agenda
we
had
initially
put
ted
on
first
but
ted
and
others
have
suggested
that
if
daniel
and
michael
are
open
to
starting
that
it
would
probably
be
useful
if
they
went
first
on
the
aspects
of
the
the
delegating
names
so
daniel.
B
Okay,
then
that's
what
we're
going
to
do
and
we'll
have
the
wrap
up
at
the
end,
we
did
go
ahead.
Stewart
is
going
to
continue
with
notes
just
a
quick
comment
on
some
document
status
items.
The
the
babel
profile
is
not
yet
published.
It
is
still
waiting
specifically
for
the.
B
The
the
babel
item
on
the
oh,
what
was
the
name
of
that?
It's
just
so
early
the
source
address.
You
know,
source
right
source,
specific,
which
I
think
julius
said
that
his
current
intention
is
actually
that
technically
it's
correct.
B
He
said,
but
it's
very
poorly
written
written
in
his
opinion,
and
so
he
intends
to
rewrite
it
and
he'd
like
then
for
it
to
go
all
the
way
back
through
wglc
and
ietf
lc,
and
all
of
that,
so
that
one
may
be
a
while
with
that,
I'm
going
to
then
bring
up
daniel's
slides.
J
So
I
I
think
I'm
gonna
be
very
brief,
with
the
two
draft
on
that,
so
we
are
three
percent
very
actively
working
on
those
and
regularly
chatting
on
it.
We
we
try
to
report
what
we're
doing
on
the
mailing
list
as
well,
but
here
it
is
next.
J
Slide
so
just
a
quick
reminder
about
what
we're
doing
so,
we're
basically
defining
how
a
home
net
can
outsource
the
dns
service
to
another
infrastructure,
and
we
designate
this
infrastructure,
the
dns
outsourcing
infrastructure
and
so,
and
the
the
entity
within
the
home
net
that
is
orchestrating.
This
outsourcing
infrastructure
is
called
the
home
naming
authority
which
is
designed
designated
at
hna.
J
So
in
a
home
net,
there
are
basically
two
kind
of
zones-
the
forward
zone,
which
here
I
represented
with
home
net.example,
and
you
also
have
the
the
reverse
zone,
which
is
here,
ip.ipv6,
dot
opera.
J
J
There
is
no
assumption
about
who
is
that
dns
outsourcing
infrastructure?
It
could
be
a
third
party,
that's
the
party
we
we
took,
but
it
could
be
the
asp
as
well
and
then,
because,
in
this
kind
of
environment
the
isp
has
a
special
role.
We
we
we
defined
it
as
second
draft
which
helps
and
he's
how
an
isp
can
is
the
configuration
of
the
home
net
naming
authority
using
dhcp
and-
and
so
this
is
why
we
have
this
naming
architecture
dhc
options.
J
So
it's
clearly
only
intended
to
help
the
communications
between
the
an
isp
and
a
cpe
that
is
using
a
dhcp
next
slide.
J
So
so,
for
the
front
hand,
I
mean
the
document
is
a.
I
mean
relatively
stable,
now
we're
working
on
an
implementation,
and
currently
I'm
saying
it's
michael
because
he's
not
here,
probably
so
he
has.
The
ball
he's
polishing
his
implementation
and
we
will
take
the
feedbacks
from
the
implementation
to
to
the
draft.
J
So
that
we
can
check
everything
that
works
as
we
expect
for
the
dhcp
options,
we
we
we
had
some
discussions
on
the
mailing
list
and
we
recently
changed
the
design.
So
the
the
change
we
we
made
is
that
for
the
previous
years
the
hna
was
supposed
to
provide
the
key.
That's
going
to
be
used
to
be
authenticated
to
authenticate
the
hnf
to
from
the
dns
outsourcing
infrastructure.
J
J
Adapted
to
a
specific
client,
but
dhcp
is
not
being
used
to
upload
some
configurations
from
the
network
to
the
call
network,
in
which
case,
in
this
case
the
dns
outsourcing
infrastructure
could
be
seen
as
the
call
network
or
upstream
network,
so
what
we
ended
up
with
we
removed
this
option
public
key
from
the
the
current
specification.
So
we
believe
that
I
mean
the
intent.
Is
that
the
isp,
when
is
using
dhep?
J
He
knows
which
line
which
client
customer
is
on
on
the
other
side
of
the
wire,
and
so
there
is
no
need
to
provide
this
public
key
from
the
hna
next
slide.
I
think
that's
all,
but
I
just
want
to
make
sure.
J
B
Okay,
any
so
it
would
be
nice
if
we
did
also
have
additional
implementations,
and
I
think
that
applies
to
ted's
draft
as
well,
that
it
would
be
nice
if
we
got
additional
people
trying
to
implement
ted's
efforts
in
dnssd,
and
so
you
think,
maybe
another
revision
and
then
you'd
like
to
try
for
a
working
group.
Last
call
and
we're
going
to
have
an
overarching
discussion
about.
B
B
Okay,
so
we'll
have
that
discussion
about
where
this
work
should
live
in
order
to
make
sure
it
gets
sufficient
review
after
we
hear
from
ted.
If
no
one
has
any
questions
or
comments
for
daniel.
B
Okay,
then,
if
it's
okay,
I
will
bring
up
ted's.
B
H
Daniel,
actually,
you
said:
there's
an
implementation
is
that
available
and
if
so,
could
you
just
send
a
mail
to
the
list
or
something
with
the
pointer.
J
Yeah,
I
I
mean
it's
available
somewhere,
but
I
can't
I
don't.
I
don't
really
know
where.
K
G
All
right,
so
I'm
gonna
talk
about
the
sort
of
the
whole
stub
networks
problem.
Are
you
hearing
me
yeah.
F
Hi,
just
before
ted
starts,
I
wanted
to
take
this
opportunity
to
thank
ted
for
his
amazing
work
on
this
18
months
ago.
Apple
asked
us
to
look
into
doing
home
kit
over
thread,
and
what
we
found
was
that
the
the
big
gap
in
thread
is
they
have,
they
didn't
have
a
border
router,
the
equivalent
wi-fi
access
point.
F
The
thing
that
connects
your
thread
network
to
your
home
network
and
just
bridging
that,
like
the
way
you
do
with
wi-fi,
would
overwhelm
the
slow
threat
network,
so
ted's
work
on
srp,
plus
the
stub
v6
networks
is
what
made
that
possible
and
ted.
You
know,
in
addition
to
working
on
documents,
did
amazing
work
in
one
year.
Writing
the
code
to
go
from
concept
to
shipping
product,
so
that
was
pretty
incredible.
We
shipped
homepod
many
last
november,
there's
already
a
bunch
of
third-party
homekit
accessories
running
over
thread
using
srp
and
the
stub
networks
work.
F
Of
course
we
don't
it
just
to
be
the
homepod
mini.
We
don't
want
to
see
a
whole
market
full
of
other
third-party
border
routers
and
that's
why
standardizing
this
work
is
really
important.
But
I
wanted
to
thank
ted
for
his
amazing
work
over
the
last
12
months.
Getting
that
shipped.
G
Yeah,
that's
why
I
have
rings
under
my
eyes
and
late
slides
anyway.
So
what
I
want
to
talk
about
is
is
exactly
what
stuart
just
described:
sort
of
the
permissionless,
adding
of
a
stub
networks
to
existing
network
infrastructure
in
order
to
deliver
reachability
and
discoverability
to
the
devices
that
are
on
the
stub
network
and
from
the
devices
that
are
on
the
stub
network,
so
so
just
to
clarify
what
a
stub
network
is.
It's
a
leaf.
Node,
there's!
No
through
traffic
stub
network
is
not
a
transit
network.
G
In
any
sense,
it
connects
to
adjacent
an
adjacent
network
and
there
needs
to
be
some
way
to
get
packets
between
the
two
networks,
both
directions.
Obviously,
and
it
needs
to
be
possible
to
discover
devices
on
the
stub
network
from
the
adjacent
network
and
ideally
from
the
adjacent
network
discovered
by
on
the
adjacent
network
from
the
stub
network.
G
So
essentially
the
idea
here
you
know
considering
the
use
case
that
stuart
just
described.
The
idea
is
that
my
in
the
case
of
of
homepod
may
probably
be
a
home
kit
accessory
right.
My
home
kit,
accessory
that's
connected
to
the
the
stun
network
through
the
homepod
mini,
has
the
same
user
experience
the
same
discoverability
the
same
reachability
as
an
equivalent
device
that
was
connected
directly
to
the
wi-fi.
That
was
our
goal.
So
so
that's
like
the
minimal
required
functionality
gets
us,
basically
what
we
need
and
then
additional
functionality.
G
Some
devices
need
to
be
able
to
reach
out
to
the
cloud,
maybe
for
firmware
updates,
maybe
because
it's
like
a
cloud-based
iot
service,
not
a
home-based
iot
service,
so
reachability
of
the
cloud
and
when
I
say
reachability
cloud,
I'm
talking
about
the
equivalent
functionality
you
have
now
in
a
matted
home
network,
where
devices
that
are
sitting
on
your
home
network
are
not
reachable
from
the
cloud
you
can't
like
some
server
out
in
the
cloud
is
not
going
to
be
able
to
make
a
tcp
connection
to
a
device
on
your
home
network,
but
the
device
on
the
home
network
can
make
a
tcp
connection
out
to
a
device
on
the
cloud.
G
And
so
that's
that's
what
I
mean
by
reachability
of
the
cloud.
Full
routing
would
be.
You
know,
there's
two
aspects
to
full
routing.
So
you've
got
adjacent
now
an
adjacent
network
would
be
just
like
a
link.
That's
that
the
stub
network
is
directly
connected
to
the
sub.
Router
is
directly
connected
to
that
link.
You
could
also
have
non-adjacent
networks
that
are
reachable
and
that's
what
full
routing
is
about.
G
So
that
means
reachability,
suppose
you've
got
a
at
home
network
or
this
is
a
small
office
network
or
maybe
a
commercial
building
network,
and
you
want
to
be
able
to
discover
and
reach
devices
on
the
stub
network
from
the
from
anywhere
on
the
on
the
multiple
subnet
lan
and
vice
versa.
That
would
be
full
routing
and
then,
in
order
for
that
to
really
work.
G
Well,
then,
you
need
probably
some
dns
infrastructure,
that's
being
updated,
rather
than
you
know
the
the
advertising
proxy
stuff
that
that
I
discussed
earlier
we'll
be
going
over
the
stuff
I
discussed
earlier
in
case
there
are
late
comers
who
didn't
hear
that,
so
that's
the
goal
is
basically
first
of
all
minimal
functionality,
just
just
the
equivalent
of
what's
available
now
only
with
your
devices
that
are
one
hop
away
and
then
ideally
full
mesh
routing
and
all
the
sort
of
things
that
you
would
expect
from
from
a
home
net,
and
in
fact
it's
because
the
the
minimal
functionality
is
a
building
block
in
the
direction
of
the
functionality
that
we
wanted
for
home
net
that
I
think
this
is
relevant
to
home
net.
G
I
think
this
is
actually
like
the
problem.
Well
I'll
talk
about
it
in
a
little
bit.
Let's
go
to
the
next
slide,
getting
ahead
of
myself,
so
how
we
got
here,
so
we
started
out
trying
to
do
everything
right.
We
wanted
the
full
mesh
topology
for,
for
you
know,
we
wanted
to
automatically
discover
the
the
entire
home
network
mesh.
We
wanted
full
mesh
routing.
G
We
wanted
full
mesh
naming
that
was
a
really
hard
problem,
even
figuring
out
how
we
wanted
the
naming
architecture
to
look
was
hard
because
some
people
wanted
wanted
one
thing
and
some
people
wanted
another,
and
we
had
lots
of
discussions
about
that
and
never
really
came
to
consensus.
Hncp
was
published,
but
it
never.
You
know,
stuart
was
talking
about
the
work
that
it
takes
to
get
a
product
to
market.
G
Getting
the
the
spec
to
the
point
where
you
think
it'll
work
is
a
very
different
thing
than
getting
the
product
to
market
and
actually
having
it
be
usable
by
people,
and
we
never
got
there
with
hncp
hncp
was
originally
motivated
by
isps
who
wanted
full
mesh
routing
in
the
home
and
and
so,
but
the
problem
was
that
it
took
too
long
and
there
wasn't
like
there
wasn't
momentum
in
the
home,
router
community
and
so
that
enthusiasm
on
the
isp
side,
never
translated
into
implementations
on
the
home
router
side.
G
And
so
basically
we
did
all
this
work
and
we
didn't
at
least
thus
far.
We
haven't
gotten
anything
out
of
it,
and
so
you
know
the
babel.
Work
has
been
proceeding
and
that's
been
really
cool.
I
have
high
hopes
for
that
work.
Actually
I'd
like
it.
If
that
work
could
become
part
of
the
stuff
that
we've
been
doing
with
with
stub
networks.
I
think
that
that
would
make
stub
networks
a
lot
more
useful,
because
right
now
suppose
you
have
two
stub
networks
and
can
connect
to
the
same
adjacent
infrastructure.
G
You
have
reachability
to
both
of
those
sub
networks.
You
have
discoverability
on
both
of
those
networks
but
suppose
a
device
on
stuff
network
a
wants
to
configure
a
device
instead
of
network
b.
How
do
you
do
that?
You
have
to
have
routing
in
that
direction
too,
and
you
know
we
can
sort
of
do
that
with
router
advertisements,
but
it'd
be
way
better
to
have
a
real
routing
protocol
so
anyway.
G
G
So,
basically,
where
we've
been
going
recently-
and
you
know,
talk
a
little
bit
about
how
this
started
stuart
and
I
were
in-
were
at
a
thread
meeting
in
munich
a
couple
of
years
ago.
Actually
I
think
it
was
a
year
and
a
half
ago,
maybe
two
years
ago-
and
we
were
talking
about
like
how
do
we
get
this
stuff
into
homes?
How
do
we
actually
deploy
multiple
subnet
home
networks
because
we
have
to
have
multiple
subnet
home
networks?
G
For
iot
I
mean
it
was
a
nice
idea
for
like
general
purpose,
but
for
iot
it's
absolutely
required.
How
do
we
get
this
into
homes?
And
so
how
do
we?
How
do
we
in
a
permissionless
way
deploy
an
existing
infrastructure?
And
so
that's
where
we
came
up
with
the
requirements
that
I
described
earlier,
we
have
to.
We
have
to
have
equivalent
functionality
to
devices
on
the
home
network
and
it
needs
to
support
existing
use
patterns.
G
G
G
So
what
we
have
now
there
are
two
stud
network
implementations.
The
homepod
mini
has
a
complete
implementation
of
the
basic
functionality
that
I
described
earlier
and
open
thread
at
this
point.
I
don't
know
if
it's
merged
into
open
thread
yet,
but
we
have
a
really
nice
implementation
of
the
srp
stuff,
the
in
open
thread-
and
you
know,
I
think
that
that
at
this
point
the
open
thread
guys
also
have
routing
working.
So
that
would
that
those
are
the
two
bits
of
a
stub
network.
G
You
know
routing
and
discoverability,
so
these
are
in
independent
implementations.
I
didn't
actually
talk
to
the
guys
other
than
basically
the
conversations
that
we
had
on
the
mailing
list
that
that
so
this
was
on
the
dns's
dmail,
and
so,
if
any
of
you
were
on
the
dns
emailings,
you
probably
saw
those
conversations.
G
So
so
we
have
these
two
implementations.
They
are
not
full
implementations,
they
don't
do
everything
they're
evolving,
but
they
deliver
the
functionality
we
need.
We
can
control
accessories
that
are
connected
to
the
stub
network.
We
can
discover
accessories
that
are
connected
to
the
stud
network
and
so
on
next
slide.
G
So
this
is,
this
is
a
little
bit
of
a
wish
here.
I'm
not!
This
is
like
where
I
would
like
to
see
this
go,
I'm
not
convinced
this
is
where
it's
going
to
go,
but
but
I'm
mentioning
this
because
I
think
that
if
this
is
an
interest
home
net,
this
is
probably
a
direction
that
we
might
want
to
consider
going,
and
that
is.
Can
we
scale
up
this
stub
network
solution?
G
Can
we
use
this
as
a
building
block
to
to
actually
get
to
the
point
where
we
have
a
complete
home
net
solution
and
not
just
stub
networks?
So
in
order
to
do
that,
we
need
to
add
babel.
We
probably
want
to
to
have
srp
on
the
edge
router
and
we
need
some
way
to
get
prefixes
to
internal
routers.
G
It
could
be
hmcp
problem
with
using
dhcp
v6
is
that
dhcp
v6
binds
an
id
to
a
specific
ip
address
to
a
delegated
prefix
and
there
isn't
actually
a
way
to
set
up
routing,
so
babel
might
solve
that
problem.
If
we
can
advertise
routes
in
babel,
maybe
we
don't
need
to
solve
the
problem
of
how
how
routing
is
set
up,
but
we
still
have
a
problem
that
only
one
thing
can
own
a
prefix,
and
that
was
a
problem
that
hncp
tried
to
solve
and
I
think
some
degree
did
solve.
G
I
don't
think
it's
a
perfect
solution,
so
one
way
to
go
forward
with
that
would
be
to
actually
provide
hncp
and
try
to
make
it
into
something.
That's
that's
that's
actually
realistically
deployable,
but
these
are
things
that
I
think
are
topics
that
would
be
worth
discussing
next
slide.
G
So,
and,
and
to
get
a
little
bit
more
into
that
right
now
like
if
you,
I
talked
a
little
bit
about
the
cd
routers
customer
edge,
routers,
basically
don't
have
any
incentive
tempo
in
hncp
or
any
of
the
other
home
net
stuff,
because
most
of
the
time
they're
going
to
do
all
this
work
to
get
into
the
router
and
then
you're
going
to
plug
the
router
into
your
network.
There
are
going
to
be
no
stub
networks
connected
to
it
right.
G
There
are
going
to
be
no
other
routers
in
the
network
and
by
the
way,
if
they
made
it
really
work
well,
it
would
actually
cut
into
their
mesh
sales
right,
so
they
actually
have
a
bit
of
a
disincentive
plus
mesh
actually
gives
about
a
ux.
I
talked
about
this
a
couple
of
well
actually
a
lot
of
homemade
meetings
ago.
G
That,
like
you
know,
if
I
and
actually
I
had
this
experience
the
other
day,
I
was
thinking
about
the
talk
I
gave
at
ietf
a
while
back
that
you
know
I
was
on
a
voice
call
on
a
meeting.
I
had
my
iphone
in
my
pocket.
I
was
using
my
earbuds.
This
was
over
ip
and
I
needed
to
go
do
something
in
the
garage
and
I
right
now
I
have
mesh
networking
set
up
at
my
house.
G
G
So
so
that's
like
a
really
nice
ux
and
so
there's
a
reason
why
router
vendors
didn't
want
to
do
the
homenet
subnetting
model
for
that
particular
use
case,
because
if
that
had
happened
then
I
would
have
had
to
hold
entirely
re-establish
my
connection.
It
wouldn't
have
just
been
like.
Oh
I
missed
some
tcp
acts.
I
need
to
wait
to
catch
up
with
that,
and
then
everything
will
be
back
to
normal.
It
would
have
been.
I
need
to
tear
down
the
entire
connection
and
re-establish
the
entire
connection.
G
Of
course
we
talked
about
nptcp
and
other
technologies
for
addressing
these
issues,
but
the
bottom
line
is
right.
Now
the
ux
is
way
better
on
mesh
than
it
would
be
with
a
subnetted
home
network.
So
so
that's
not
going
to
motivate
router
vendors
to
put
this
functionality
in.
G
G
G
So
the
building
blocks
we
have
right
now
and
now
we're
back
into
the
stuff
that
I
presented
earlier.
So
if
you
were,
if
you
were
in
that
presentation,
there's
going
to
be
a
review
here,
we
have
a
bunch
of
naming
stuff.
We
have
a
way
to
register
names.
We
have
a
way
to
advertise
those
names
using
multicast
dns.
G
We
have
a
way
to
create
a
reliable,
named
database
using
devices
like
I've
been
talking
about
stub
network
devices
that
are
just
like
you
know,
homepod
mini,
I
mean
your
homepod,
you
don't
think
your
homepod
mini
as
a
server
right,
so
it's
perfectly
fine
to
power
cycle
it
or
you
know,
install
a
new
software
update
on
it.
There's
nothing
wrong
with
doing
that.
G
It's
not
going
to
break
your
network,
however,
if
it's
got
all
of
your
srp
registrations
in
it
you're
going
to
lose
all
those
registrations
and
you're
going
to
have
to
somehow
regenerate
them
and
because
of
the
way
that
srp
works
with
with
conflict
detection.
If
you
lose
all
of
your
information,
you
could
wind
up
getting
surprising
conflicts
when
you
recover,
it's
not
a
huge
problem,
but
it
is
a
problem
so
being
able
to
to
have
a
stable
store
of
name
information
service
discovery.
G
Information
will
create
a
better
user
experience,
and
so
that's
the
replication
piece
and
then
the
ability
to
discover
browsing
zones
so
that
you
don't
have
to
use
multicast
dns
for
every
query.
If
you,
you
know
normally
like
in
a
typical
home
network
prior
to
sort
of
you
know
everybody
getting
light
bulbs
that
had
wi-fi
in
them,
there
might
be
like
five
or
ten
services
on
your
home
network.
So
there
was
a
certain
amount
of
multicast
traffic,
but
it
wasn't
like
a
huge
amount
of
multicast
traffic.
G
Now
we're
talking
about
like
a
lot
of
a
lot
of
devices,
advertising
their
services
and
they're
being
advertised
by
the
the
srp
advertising
proxy,
and
so
all
of
those
answers
are
coming
in
in
multicast
packets
and
we're
starting
to
get
into
situations
where
they
might
overflow
and
might
wind
up
with
a
lot
of
packets.
And
so
is
there
a
way
to
to
to
use?
Is
there
is
there
a
way
to
to
get
as
much
of
that
traffic
into
unicast
traffic
as
possible?
G
So
and
then
the
fifth
item
on
the
on
the
on
the
agenda
here
is
the
actual
stub
networks
document.
So
this
is
this.
Is
the
you
know?
I
I
want
to
build
a
stub
network.
I
want
to
have
a
stub
network.
What
do
I
need
to
do
to
get
the
stub
network
working?
What
do
I
need
to
do
in
terms
of
addressability,
reachability,
discoverability
and
so
on?
So
those
are
the
topics,
and
so,
let's,
let's
go
on
to
the
next.
G
Slide
so
so
I
mentioned
discovery
browsing
zones.
The
deal
here
is
that
it'll
be
really
nice
to
not
have
to
do
all
of
our
service
discovery
with
multicast,
and
so
the
one
way
to
do,
that
is
to
add
a
level
of
indirection.
G
Basically,
I
would
like
to
discover
the
server
that
I'm
going
to
get
my
information
from
using
multicast
and
then
do
all
the
rest
of
my
discovery
using
unicast
traffic,
and
so
the
idea
here
is
that
will
advertise
an
ns
record
using
multicast
dns,
we'll
advertise
an
a
record
or
an
a
a
quad,
a
record,
or
you
know
more
than
one
that
that
answer
the
questions,
the
ns
record
and
that
gets
us
to
a
dns
server
that
we
talked
to
using
multicast.
Oh
sorry,
unicast.
G
So,
and
in
order
to
avoid
like
spoofing,
we
only
allow
home.arpa,
we
might
allow
service.org
as
well
that's
an
srp
zone
that
would
be
registered
when
srp
gets
published,
and
so
this
is
a
this.
Is
you
know
a
solution
to
the
problem
of
of
too
much
multicast
traffic
on
your
network?
I'll
talk
a
little
bit
about
the
problems
with
that
later,
but
because
there
are
some
issues
that
are
actually
kind
of
more
home
net
specific
than
they
are
dnssd
specific
about
how
to
reduce
multicast
traffic.
G
So
we
have
a
draft
on
this.
We
haven't
published
it
yet
you
know
drafted
draft.
I
should
say
it's
not
in
an
internet
draft
form
yet
and
that's
going
to
be
worked
on
dnssd.
But
I
mentioned
it
here
because
it's
relevant.
H
G
Okay,
similarly
service
registration
protocol,
this
is
a
unicast
protocol
for
doing
dns,
sd
advertisements
and
again
it's
a
service
that
needs
to
be
available
on
a
stub
router
in
order
for
discoverability
to
work.
So
if
you
want
to
be
able
to
discover
stuff
on
the
sub
network
from
the
from
the
adjacent
infrastructure
network,
which
would
be
typically
your
home
wi-fi
or
your
home
ethernet,
you
need
a
way
for
the
devices
on
a
stub
network
to
register
their
services
with
the
stub
router,
so
the
stub
router
can
advertise
them
on
the
home
link.
G
So
so
that's
srp
srp
is
a
it's.
It's
got.
This
thing
called
first,
come
first
serve
naming
which
allows
you
to
claim
a
name
using
a
cryptographically,
secure,
authentication
mechanism
and
and
then
you
get
to
keep
that
name
until
you
until
it
expires,
and
so
this
is
something
that's
already
been
implemented.
It's
on
the
homepod
mini.
There
are
a
whole
bunch
of
thread
accessories
that
support
it
and
that's
something.
G
G
Advertising
proxy-
I
talked
about
this
earlier.
Basically,
the
idea
is
you
have
this
database
that
you
built
up
with
srp.
Now
you
need
to
make
it
available
to
devices
that
are
on
the
adjacent
infrastructure
network.
The
advertising
proxy
is
how
you
do
that
it
just
basically
advertises
everything.
That's
in
the
database,
that's
being
maintained
using
srp
using
multicast
dns
or
using
the
ssd.
So
the
what
I
was
talking
about
earlier
with
discovering
multi
with
discovering
dns
ssd
zones
using
multicast
dns.
G
Now
we're
discovering
the
advertising
proxy
using
multicast
dns,
but
then
all
of
the
rest
of
the
queries
that
we
do
to
the
advertising
proxy
go
over
unicast,
and
so
that
saves
a
whole
bunch
of
multicast
traffic.
So
that's
another
thing:
that's
it's!
It's
we've
got
several
implementations
of
that
and
it's
in
pretty
good
shape,
but
we
still
have
work
to
do
in
the
dssd
working
group.
This
is
something
that's
going
to
be
part
of
the
stub
router
specification
next
slide.
G
Srp
replication
I
mentioned
this
earlier.
You
need
to
be
able
to
have
a
stable
database
or
you'd
like
to
be
able
to
have
a
stable
database
of
srp
clients
and
not
lose
them
when
there's
a
reboot.
So
that's
srv
replication
addresses
that
issue.
I
won't
go
into
great
detail
about
srp
replication
here
unless
somebody
wants
to
ask
more
questions
next
slide.
G
Okay,
so
now
the
stub
networks
document.
So
this
is
the
document,
that's
actually
the
the
the
core
work
that
I
wanted
to
talk
about
for
home
net.
There
are
actually
two
documents.
One
of
them
is
a
problem
statement
basically
says
here's
the
problem
we're
trying
to
solve-
and
here
are
some
ideas
that
we've
considered
for
how
to
solve
it,
and
I
don't
know
if
that
document
needs
to
become
a
working
group
document.
G
G
Information
michael
had
the
idea
of
actually
just
taking
that
information
and
putting
it
into
appendices
in
the
the
implementation
document.
So
that's
another
way
to
go.
The
implementation
document
currently
draft
lemon
stub
networks
describes
how
to
connect
stub
networks
to
existing
infrastructure
and.
G
That
document
is
based
on
the
work
that
we
did
on
the
homepod
mini
and
on
open
thread,
and
it's
it's
a
pretty
good
document.
It's
it
still
needs
some
work.
It
needs
like
it
would
be
nice
to
talk
about.
People
have
asked
about
a
state
machine
for
for
how
things
are
managed
I'll
talk
a
little
bit
about
what's
in
the
document
after
I've
sort
of
gone
over
my
field
about
maturity,
so
it's
not
ready
to
implement.
G
I
I
think,
is
work
that
would
be
interesting
to
do
in
homenet,
and
so
so
my
goal
is
to
to
see
at
home
that
is
interested
in
adopting
it
and
working
on
it,
and
you
know
the
big
question
mark
is:
are
there
people
here
who
are
actually
interested
in
doing
this
work,
and
is
this
a
place
where
they
would
be
willing
to
do
it?
It
feels
a
little
funny
to
do
this
work
in
iot
ops,
because
I
really
don't
think
this
is
iot
specific.
G
G
You
know,
obviously
if
it
gets
published,
and
so
that
would
be
something
that
could
be
done
in
v6
ops.
The
problem
is
v6
ops.
That
would
be
very
unfocused,
whereas
this
use
case
is
very
specific
to
home
networks.
So
really
the
question
is:
is
there
is
there
interest?
I
mean
I
think
the
question
is:
is
they're
interested
in
working
on
this
in
the
networking
group?
So
I'll
talk
a
little
bit
about
what
I
know.
Let
me
see:
I'm
gonna
look
at
my
own
copy
of
the
slides
so
yeah.
G
So
let
me
just
talk
a
little
bit
about
what
the
stub
networks
document
describes.
So,
basically
the
idea
is,
you
connect
a
stub
network,
a
stub
router
to
the
adjacent
infrastructure
network.
The
stub
router
looks
on
the
network
to
see
if
there's
ipv6
service.
So
one
thing
to
say
about
this
is
that
currently
there
isn't
an
easy
way
to
do
bi-directional:
permissionless
ipv4,
but
it's
actually
pretty
easy
to
do
bi-directional.
Permissionless
ipv6,
and
so
we
just
said:
that's
what
we're
doing
we're
not
doing.
G
Ipv4
for
bi-directional
connectivity,
you
know
it
would
be
no
problem
to
have
a
an
ipv4
net
behind
another
ipv
before
that,
and
devices
on
the
stub
network
could
connect
out
to
devices
that
are
on
the
home
network
or
out
to
the
cloud.
But
we
didn't
really
want
that
answer,
because
that
doesn't
give
us
the
ability
to
operate
devices
on
the
stub
network
from
the
home
network,
so
hence
ipv6
only
all
right.
So
how
do
we
make
that
work?
G
G
A
prefix
information
option
that
is
on
link
and
is
eligible
for
auto
configuration
or
has
dhcp
v6
support.
Those
are
the
two
options.
Sorry
I've
been
talking
a
long
time.
I
thought
it's
getting
dry.
I
should
have
brought
some
water,
so
so
so
is
there
ipv6
addressing
already
available
on
the
home
network?
If
not,
then
the
home
router
will
advertise
the
prefix
and
it
this
is.
This
would
be
a
little
dangerous
right,
because
what
if
ipv6
service
comes
back,
we
don't
want
to
steal
the
default
route
from
the
customer
edge
router.
G
That
would
be
really
bad.
So
the
way
we
advertise
this
is
using
using
an
ra
with
the
default
with
the
router's
default
lifetime.
Sorry,
the
router
lifetime
set
to
zero.
G
So
that
means
don't
use
this
as
a
default
router
and
so
devices
that
support
that
functionality
will
ignore
the
ra
in
terms
of
setting
up
their
default
route,
and
in
fact
this
this
is,
you
know
we
haven't,
had
any
issues
with
devices
that
don't
understand
this,
that
the
issue
that
we
have
seen
is
that
there
are
some
devices
that
when
they
see
a
router
lifetime
of
zero,
they
just
ignore
the
ra,
but
that's
less
of
a
problem
now
than
it
was
two
years
ago
through
efforts
that
we've
undertaken.
G
So
so
that's
that's
how
we
get
ipv6
addresses
onto
the
home
network
and
we
can
do
roughly
the
same
thing
for
the
stub
network
for
thread.
It
turns
out
that
there's
a
different
way
of
configuring
prefixes,
we
don't
use
r8,
but
but
basically
the
principle
is
the
same.
You
advertise
the
prefix
on
this
on
the
stub
network,
and
you
know,
and
by
the
way
the
prefix
is
being
advertised
here
in
sort
of
the
normal
case
is
just
a
ula.
The
home.
G
The
router
creates
a
ula
and
advertises
it
on
the
home
network
and
on
the
stub
network,
different
different,
slash,
64s
out
of
that
slash,
48
ula,
and
now
we
have
ipv6
addressing
on
both
sides.
So
that
means
that
the
nodes
that
are
on
the
home
network
have
ipv6
addresses
nodes
that
are
on
the
stub
network,
have
ipv6
addresses,
and
so
therefore
in
principle
they
could
talk
to
each
other
because
they
have
addresses.
G
The
next
step
is:
how
do
we
tell
devices
on
the
home
network?
They
can
reach
devices
on
the
stub
network
and
that's
by
again
doing
an
ra
with
the
route
information
option
so
ras
have.
This
is
something
was
added
after
the
original
ra
document
that
provides
the
ability
to
advertise
specific
routes
in
the
ra,
and
so
we
just
advertise
a
specific
route
to
the
prefix.
That's
on
the
sub
network
and
we're
done
now
now
a
host,
that's
on
the
home
network,
can
send
packets
to
the
stub
network.
G
So
then,
the
next
step
is
that
the
devices
on
the
stub
network
need
to
be
able
to
send
packets
to
the
home
network
and
that's
actually
sort
of
easy.
I
mean
one
way
to
do
that
is
to
just
have
any
stub
router
advertise
a
default
route
that
works
great,
except
what?
If
you
have
two
stub
routers
that
are
connected
to
different
adjacent
infrastructure
links
but
are
connected
to
the
same
stub
network
link?
G
Then
you
have
a
problem,
because
if
both
of
them
are
advertising
default
route,
then
you're
only
going
to
have
reachability
to
whichever
one
is
closest
to
the
accessory
reachability
to
the
adjacent
network
of
the
stub
router,
that's
closest
to
whichever
accessory,
is
trying
to
talk
to
that
device.
So
it's
if
we
want
to
support
that
use
case,
and
I
think
we
do,
then
we
actually
need
to
advertise
essentially
the
same
thing
on
this
on
the
stub
network
side
we
need
to
you
know.
G
G
If
it's
a
thread
network,
then
we're
not
using
ras,
but
basically
the
same
principle
applies.
So
so
that's
basically
the
idea
of
how
routing
works.
So
this
is
not
like
a
routing
protocol,
we're
just
using
router
advertisements
because
we're
just
talking
to
adjacent
links
we're
not
doing
anything
fancy.
It
would
be
nice
to
enhance
this
with
people,
but
but
you
know
this
basically
works.
G
So
the
next
step
is,
let's
see,
oh
right,
so
so
I
talked
earlier
about
dnssd,
so
all
of
that
functionality
is
required
in
order
to
provide
discoverability
of
devices
on
the
stub
network
from
the
adjacent
network.
One
thing
I
didn't
mention
in
the
slides
is
that
stub
network
devices
also
may
need
to
discover
devices
that
are
on
the
adjacent
network
and
the
so
in
the
adjacent
network.
Being
a
wi-fi
network.
You
know
it's
your
home
now,
usually
right.
G
So
so
those
devices
are
going
to
be
advertising
using
multicast
dns,
and
that
means
that
we
need
a
dns
sd
discovery
proxy
as
well
in
the
sr
sr
in
the
stub
network
router
and
by
the
way,
all
of
the
stuff
that
I'm
talking
about
is
already
in
stub
network
documents.
So
if
you're
totally
lost
and
you
you
know,
you
can
read
the
document
and
I
think
it's
pretty
clear,
but
anyway,
the
in
order
for
devices
that
are
on
the
stub
network
to
discover
devices
in
the
home
network.
G
They
need
to
be
able
to
send
dns
queries
to
the
discovery
proxy,
which
can
then
send
dns's
d
queries
out
on
the
home
network
to
get
back
the
answers
that
that
are
returned
to
the
to
the
sr
to
the
to
the
just
to
the
dnssd
client
on
the
stub
network.
So
so
that's
an
additional
piece
of
functionality
that
the
reason
I
don't
mention
that
in
these
slides
is
because
that
work
is
completed.
We
already
have
dns
push.
We
already
have
the
discovery
proxy.
Those
are
both
rfcs.
G
So
so
there's
no
further
work
to
do
on
that.
It's
just
something
that
needs
to
go
into
a
stub
network
router.
So
can
we
go
to
the
next
slide?
Now,
I'm
almost
done
honest.
So
one
of
the
issues
that
we
have-
and
I
alluded
to
this
earlier-
is
that
we
need
to
be
able
to
do
if
we
want
to
be
able
to
do
full
mesh
routing.
G
We
have
to
have
prefixes
that
are
that
are
valid
on
the
network,
so,
like
this,
the
subrouter
can
generate
a
prefix,
a
ula
prefix
and
use
that
on
a
link
that
it's
directly
connected
to
and
that
works
right.
But
if
we
want
routing
to
links
that
the
stub
router
is
not
directly
connected
to,
we
have
to
have
a
real
ipv6
address.
It
doesn't
have
to
be
a
gua,
it
could
be
a
ula,
but
the
ula
has
to
come
from
this
from
the
infrastructure,
not
from
the
sub
router.
G
So
the
infrastructure
knows
how
to
route
the
ula.
If
it
is
ula,
if
it's
a
gui,
that's
great
too,
it
just
needs
to
be
able
to
route
that
so
so
we
need
a
solution
for
pbx
delegation
right
now.
We
don't
have
one
dhcp,
v6
sort
of
gives
us
what
we
want.
Hncp
sort
of
gives
us
what
we
want.
The
problem
is,
hncp
is
doing
a
bunch
of
stuff.
We
really
don't
want
for
stub
networks.
We
don't
want
the.
We
don't
want
hmcp
to
be
blasting
out
multicast
packets
on
the
sub
network.
G
That's
a
really
bad
idea.
It's
never
going
to
reach
anything
so
so
we
would
need
to
to
have
a
profile
for
hmcp
if
we
used
hncp
and
similarly
we
would
need
extensions
to
dhcp
v6
if
we
use
dhcp
v6.
G
These
are
open
questions,
but
also,
if
we
use
dhcp
v6,
we
need
some
way
to
cooperate.
We
because
there
might
be
multiple
sub
routers
that
all
need
the
same
prefix
for
the
same
stub
network.
How
do
they
all
know
about
it?
How
does
that
get
into
the
routing
infrastructure?
That's
an
interesting
problem,
an
unsolved
problem.
So
this
is
something
we
could
work
on.
G
Another
problem
is
suppose:
we've
got
a
ce
router
that
supports
dns.
Ssd
supports.
You
know
supports
delegating
browsing
zones.
How
do
we?
How
do
we
actually
tell
it?
What
browsing
zones
to
delegate
you
know?
G
There's
two
there's
two
solutions
here:
actually
one
is
we
can
just
put
an
srp
server
in
the
stub,
sorry
in
the
ce
router
and
then
the
stub
network
devices
could
discover
the
srp
server,
that's
in
the
stub
router
and
then
they
could
just
forward
srp
requests
straight
to
the
stub
router,
and
now
those
devices
are
all
discoverable
using
using
dnssd
without
any
multicast
traffic.
At
all,
that's
one
way
to
solve
the
problem.
G
Another
way
to
solve
the
problem
is
to
have
the
keep
the
the
srp
server
and
the
dns
zone
in
the
stub
routers,
but
have
a
delegation
from
the
ce
router
so
either
way
we
solve
that
problem.
There's
new
text
to
write
and
it's
probably
text
that
needs
to
get
written
in
home
net
or
some
equivalent
working
group.
G
I
think
I
suppose
it
could
be
done
in
the
ssd
also,
but
it
seems
home
net
relevant
because
we're
talking
about
customer
edge
routers
in
a
multi-subnet
at
home,
and
that
seems
like
home
network
so
and
then
how
do
we
eliminate
all
this
excess,
multicast
dns
traffic
because
we're
starting
to
like,
if
we're
going
to
really
leverage
all
of
the
service
discovery
stuff
we're
going
to
start
to
see
more
traffic?
G
Multicast
traffic
is
already
a
problem.
It
slows
the
network
down,
it's
not
reliable,
and
so
you
know
one
way
to
do
that
is
to
just
like.
Have
the
stub
router
intercept
all
the
multicast.
Sorry
have
this
the
customer
edge
router
have
the
wi-fi
access
point,
intercept
all
the
multicast
traffic
so
when
you've
got
a
multicast,
dssd,
multicast,
sorry,
an
mds
multicast
from
a
client
on
the
wi-fi
network,
it's
just
consumed
by
the
by
the
access
point,
which
then
forwards
it
to
a
discovery
proxy
which
sends
back
the
answer.
G
If
we
need
to
discover
devices,
we
can
use
dns,
we
can
use
mdns,
but
it's
not
really
multicast
we're
just
sending
mdns
to
each
host
and
then,
if
that
host
has
one
of
the
services
it
will
reply
with
the
unicast
reply,
which
it
thinks
is
a
multicast
reply,
but
we're
intercepting
the
multicast.
So
we
can
basically
eliminate
all
of
that
multicast
traffic
from
being
actually
transmitted
as
wi-fi
multicast
traffic.
This
again
seems
like
something
that
would
make
sense
to
discuss
in
homeland.
G
So
those
are
other
topics
that
I
think
would
be
worth
working
on
in
the
future,
and
that's
that's
pretty
much
what
I
have
to
talk
about.
We
go
to
the
next
slide.
That
has
that
has
the
list
of
drafts,
and
you
can
talk
to
me
about
this
and
you
can
talk
to
stuart
about
this
and
there
are
actually
there
are
a
bunch
of
people
in
open
thread
that
you
can
also
talk
to
about
this,
but
but
stuart,
and
I
are
kind
of
the
main
co-conspirators
so
so
talking
to
us
would
be
good.
B
Thank
you,
ted
that
was
actually
really
cool.
Okay,
so
first
I'd
like
to
open
up
the
queue
for
technical
discussion
on
all
of
this
stub
network
topic.
I
have
seen
a
little
chatter
in
the
chat.
Would
anyone
have
additional
questions
or
comments.
G
I
noticed
that
oola
asked
the
question
about
what
I
mean
by
full
mesh
routing
is,
do
I
just
mean
routing
the
reason
I'm
drawing?
That
distinction
is
because
we're
sort
of
doing
riding
with
ras,
which
is
not
really
a
routing
protocol,
so
so
I
say
full
mesh
routing
just
to
distinguish
between,
like
you
know,
sort
of
routing
with
ras
versus
actual
routing.
So,
yes,
I
do
mean.
F
Stuart
yeah,
the
thing
I
would
add
to
that
is
the
distinction
when,
when
ted-
and
I
talk
about
full
mesh
routing,
we
mean
multiple
hops
within
the
home
network,
and
what
ted
is
talking
about
here
with
the
stub
networks
is
a
simplified
form
of
that,
where
you
assume
that
the
home
has
one
current
wi-fi
network,
which
is
in
a
sense,
the
backbone
network,
and
you
may
have
multiple
stubs
hanging
off
that
backbone.
F
But
it's
not
an
arbitrary
topology
of
interconnected
links.
It
is
a
backbone
with
some
number
of
stubs
hanging
off
it
and
part
of
the
complexity.
Ted's
talk
mode
is
some
of
those
stub
routers
might
serve
the
same
stub
network.
So
that's
where
some
coordination
is
needed,
because
you
want
multiple
stub
routers
for
reliability,
but
you
don't
want
them
to
step
on
each
other's
toes.
B
Okay,
is
there
further
technical
discussion,
if
not
we'll
launch
into
the
administrative
discussion
of
oh
eric.
D
Yeah,
so
that
first,
without
any
hat
at
all,
looks
like
the
cool
stuff.
Honestly
I
didn't
read.
I
didn't
write
your
slides.
That's
one
thing
I
will
do
over
the
weekend
for
sure.
Look,
there's
simple
ids!
Now
putting
back
my
ad
hat
just
curious
about
the
intended
status.
D
G
Yeah,
it's
it's
really
on
the
edge
because
for
for
you
know,
one
of
the
things
we
want
is
to
avoid
having
the
stub
router
step
on
the
home
network
right.
We
don't
want
the
stub
router
to
be
adding
a
bunch
of
stuff
to
the
home
network
that
isn't
needed,
and
in
order
to
avoid
doing
that,
we
need
a
state
machine
to
track
what's
happening
on
the
home
network.
So
in
a
sense
that
state
machine
looks
an
awful
lot
like
a
piece
of
protocol
work,
but
but
yeah.
G
This
is
really
more
in
the
line
of
best
this.
This
particular
the
the
stub
networks
document
in
particular.
I
think
you
know
the
reason
I
call
it
bcp
right
now
and
why
I
think
that's
maybe
the
right
name,
for
it
is
because
really
it's
mostly
here's
what
you
do
with
ras,
which
we
already
have
a
protocol
spec
for
you
know,
here's
what
you
do
with
dnssd.
G
We
already
have
these
protocol
specs
or
we're
working
on
these
protocol
specs.
So
so
in
that
sense
you
know
it
does
make
sense
to
call
it
a
bcp,
and
I
think
that
that's
a
question
that
we
should
answer
it
may
be
that
that
the
right
way
to
do
this
is
to
have
a
bcp
and
then
actually
have
a
little
document
that
just
talks
about
the
state
machine.
That's
that's
a
that's
a
standard
document.
B
I
was
just
going
to
say
you
know
as
someone
who
is
involved
in
all
of
the
ce
router
documents.
Actually,
what
I
was
thinking
was
that
what
you're
describing
sounds
rather
like
a
device
profile
type
document
which
has
often
been
published
as
informational.
B
D
G
No,
no,
the
goal
is
to
have
this
be
a
specification,
the
ietf,
and
by
the
way
I
mean
one
thing
that
I
would
like
to
emphasize
is
that,
although
this
is
shipping
and
products,
because
it's
sort
of
just
advice
about
how
to
do
stuff,
if
we
change
the
advice
a
little
bit,
I
don't
think
it
would
have.
I
don't
think
that
would
be
a
bad
outcome
like
we're
not
wedded
to
doing
it
exactly
the
way
we're
currently
doing
it.
So
so
this
is
not
like.
Please,
please
rubber
stamp
this
on
iatf.
G
D
Okay,
that
was
basically
my
next
point
and
my
last
command
is
way
too
early
to
to
decide,
of
course,
for
sure
it's
not
for
iot
ops,
I'm
not
sure,
though
it's
in
home
net,
we
need
to
check
the
charter
based
on
the
content.
Of
course,
we
can
start
working
here
right
so
like
every
community
in
the
ietf.
D
That's
for
sure
omnet
was
very
specific,
a
sling
somehow
in
the
mindset
of
many
people
to
hncp,
and
maybe
it
could
be
wise
and
again
it's
way
too
early,
and
maybe
I'm
removing
my
head
on
this
one.
D
It's
way
too
early
to
link
this
to
hncp.
Maybe
another
group
and
dissociate
hncp
from
your
ids
could
be
better
on
the
long
term.
Again,
a
little.
G
In
your
mind
I
mean
I
will
say
that
I
think
this
document
is
ready
for
adoption
in
some
working
group.
So
in
that
sense
perhaps
it's
not
quite
as
early
as
you're
suggesting
but
yeah.
I
agree
that
if
we
think
home
that
is
really
all
about
hncp,
then
it
probably
isn't
the
right
place.
That's
an
open
question
to
me.
I
mean
for
me,
is
about
the
multi-subnet
routing
problem,
but
it
really
depends
on
who's
showing
up
right.
G
G
Nobody
wants
to
talk
about
it,
we
shouldn't
do
it
at
home
yet,
but
you
know,
if
there's
interest
in
doing
the
work
I
mean,
I
think
that
you
know
there
are
some
experts
who
are
not
normally
attendees
at
home,
that
who
would
hopefully
show
up
if
we
did
it
at
home
that
if
we
did
it
in
v6
ops,
maybe
those
experts
would
already
be
there,
but
the
problem
is:
if
we
do
it
in
v6
ops,
then
we
just
have
like
it's
it's
just
it's
the
anything
working
group.
You
know
this.
G
F
D
F
G
B
H
Yeah,
so
I
mean
I
think
this
is
pretty
cool
stuff.
I
I
would
like
to
see
it
happen
in
the
itf
somewhere
and
home.
It
might
be
in
that
place.
I
don't
know
I
don't
it's
not
a
huge
deal,
it
is
or
isn't,
but
I
guess
the
question
I
have
is
how
many
other
people
are
interested
in
working
on
this.
That's
the
one
I'd
love
to
get
an
answer
to
which
you
might
not
get
today
for
sure
raising
the
list,
of
course,
but
I'd
really
love
to
know
from
this.
H
B
I'll
put
together
a
poll
on
that,
I
thought
we
had
another
in
the
queue,
but.
B
Yeah
did
you
want
to
okay,
while
he
talks
I'm
going
to
put
a
poll
together
and
we'll
see
what
sort
of
interest
we
have.
I
Yeah,
I
think
what
I
wanted
to
say
was
just
the
clarification
indeed
like
open
threads.
That's
the
open
source
software
project.
It
does
not
make
any
specifications,
there's
a
thread
group
who
it
doesn't,
make
the
open
source
source
software,
but
does
make
specifications
but
they're,
mostly
based
on
itf
specifications.
G
One
thing
to
say
about
asking
that
question
is:
I
was
planning
on
getting
the
open
thread:
people
sorry,
the
thread
group
people
to
to
come
and
participate
in
this
meeting,
but
I
just
didn't
have
time
this
week
to
arrange
that.
G
So
I
really
one
of
my
goals
here
is
actually
to
get,
because
we,
this
working
group,
has
been
a
little
bit
more
open
and
that's
been
a
little
bit
sad
to
me
because
I
think
the
work
we're
doing
in
this
working
group
is
really
interesting,
useful
work
and
I
feel
like
we
didn't
quite
make
it
and
that's
frustrating.
H
Barbara,
I'm
not
sure
if
that
poll
worked.
B
No,
I'm
redoing
it
because
I
found
it
was
ambiguous.
The
way
I
put
it
together.
B
And
so,
if
anybody
hasn't
used
the
poll
tool,
you
should
be
able
to
go
up
to
the
little
icon
at
the
top.
That
looks
like
a
vertical
bar
graph
and
click
on
that
and
vote
on.
One
of
the
options.
B
Okay,
so
it
looks
like
out
of
the
35
participants
on
the
call
today.
11
have
raised
their
hand
and
one
has
purposefully
not
raised
their
hand,
which
is
a
no
I'm,
not
interested,
and
I
guess
that
means
the
remaining
23
are
disinterested.
B
There
is
always
that
possibility,
okay,
so
let's
sort
of
then
talk
about
not
just
this,
but
also
daniel
and
michael's
work
on
the
name
delegation
and
how
to
best
get
good
review
of
that
topic.
So
maybe
let
me
do
another.
J
Just
a
clarification
me
and
michael
I
mean
they
are.
B
B
Fair
enough
y'all
are
simply
the
lead
authors.
That's
why
I
name
you
and
rey
is
also,
I
think,
one
of
the
authors
now
that's
listed
but
yeah.
So
let
I'm
going
to
just
do
a
poll
of
if
we
were
to
do
a
wglc,
how
many
people
would.
B
B
Does
it
make
sense,
steven
and
eric
then
for
us
to
just
go
ahead
and
proceed
with
the
wglc?
If
this
many
people
are
willing
to
review
it
here,.
H
Yes,
I
think
it's
if
we
got
nine
or
nine
decent
reviews.
It
would
be
great
if
nine
people
are
willing.
Today
we
may
get
less
than
nine
it's
possible,
but
I
think
it's
it's
worth
a
shot
so
yeah
when,
when
daniel
and
michael
think
it's
ready,
then
yeah
we
could
do.
We
could
give
it
a
try
and
see
what
happens
and
if
it's,
if
we
don't
get
enough
review,
I
think
then
we
just
pass
the
problem
back
to
eric
and
say
figure
out
what
to
do
so
yeah.
Thank
you.
B
Okay,
then
daniel,
do
you
think
it's
ready,
or
do
you
think
you
want
one
more
reb?
B
Okay,
then
we
will
you
know
if
you
get
it
in
soon,
then
I
think
you
know
we
can
ride
this
wave
of
interest,
so
I
would
prefer
sooner
rather
than
later
and
then
we
can
start
the
wglc
on
it.
B
B
So
eric
I'd
really
like
to
get
your
perspective
on
where
you
would
like
to
go
with
stub
network.
Since
you
know
there
are
a
lot
of
options
that
are
within
interior.
H
D
Absolutely
you
are
stealing
my
word.
I
just
basically
browsed
through
it
and
got
the
id
it's
a
way
to
take
any
decision.
I
do
think
it's
personally
right
as
an
individual.
I
do
think
it's
an
important
work
as
an
idea.
We
need
to
take
some
more
thinking
and
decide
which
is
the
best
place
right.
That's
it.
We
need
to
think
basically.
B
B
Then
why
don't
we
have
an
interim
on
home
net
both
on
the
stub
networks,
and
you
know
to
give
the
authors
of
the
name
delegation
a
target
for
having
their
drafts
out.
Where
we
can.
You
know
they
can
give
a
brief
presentation
on
what's
changed
and
we
can
agree
to
launch
wglc.
B
That
is
have
about
10
minutes
for
that
sort
of
thing,
just
to
give
it
a
push
and
a
date
and
then
spend
time
on
stuff.
H
H
Then
okay,
so
I
guess
he
actually
will
be
honest
as
chairs
to
try
and
do
a
doodle
for
six
weeks
each
time
or
something
like
that.
B
B
I'm
not
hearing
anything
in
that
case
I'm
going
to
thank
eric
and
david
and
stephen
and
all
of
the
authors.
I
think
there
actually
has
been
good
discussion
here
and
there's
definitely
good
work
being
done,
and
I
really
appreciate
all
of
y'all
attending
and
I'm
looking
forward
to
seeing
all
of
the
chatter
on
the
mailing
list.
B
No
I'll
be
going
in
and
looking
it
over
editing
it
and
then
pushing
the
publish.