►
From YouTube: IETF99-DNSSD-20170719-1520
Description
DNSSD meeting session at IETF99
2017/07/19 1520
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
A
B
D
B
C
Do
we
have
a
job,
a
real,
a
volunteer,
great
thank
you
and
Tim
Tim.
The
hero
of
the
revolution
is
going
to
he's.
Gonna
take
is
gonna,
take
minutes
for
us
and
feel
free
to
jump
in
on
the
etherpad
and
and
put
your
own.
If
you
oh
great
thanks
and
if
you
know
a
name
that
that
we
don't
get
in
or
something
else
gets
missed,
feel
free.
It's
a
collaborative
effort.
C
B
So
this
is
the
data
tracker
screenshot,
showing
the
status
of
the
various
documents.
So
what
we'll
talk
about
some
of
them
today,
but
the
requirements
is
obviously
being
published
for
some
time
now,
as
an
RC
hybrid,
come
on
to
in
a
moment,
there's
just
a
couple
of
things
that
need
doing
there,
whereas
discovery
proxy.
As
it's
now
called
before
that
gets
pushed
up
to
towards
the
is
G.
B
The
mdns
Interop
is
in
the
RFC
editors
queue
I,
don't
think
it's
popped
out
yet,
but
it
must
be
very
imminent
where
I'll
be
talking
about
the
pairing
and
privacy
drafts
today,
it's
the
first
item
on
the
agenda
and
then
push
is
also
very
close.
I
think
Stuart's
just
got
one
kind
of
key
question.
He
wants
to
ask
the
group
about
a
change
it's
made
to
the
last
version.
Ok,.
E
It's
basically
all
done
I'm
getting
it
sort
of
getting
all
the
formatting
because
I
very
much
stuff
at
the
the
normative
download
references
around
the
session
signaling
thing,
which
has
been
just
a
good
time
for
us
and
DNS
op.
So
that's
the
only
thing,
so
you
should
see
that
by
the
end
of
the
day
modular,
what
else
I
got
going
on?
Ok,.
B
So
I
thought
we'd
had
a
discussion.
Ok,
that's
alright!
Absolutely
fine!
So
yeah!
The
girls
today
have
we
finalized
the
submission.
What
we
need
for
the
submission
of
the
discovery,
proxy
and
Bush,
though
we
still
have
this
dependency
on
the
session
signaling.
As
mentioned,
discuss
the
DNS
SD
privacy
draft
and
the
outcome
with
working
last
call
that
we
did.
B
Okay
and
here's
the
agenda
for
people
that
have
got
fighter
pilot
vision
at
the
back
you'll
be
able
to
hopefully
read
this
so
twenty
minutes
for
the
privacy
draw
device
powering
30
minutes.
First
Stewart's
talk
about
some
of
the
new
items.
Ted
thank
got
15
minutes
on
the
mdns
relay
and
carry
15
minutes
on
the
dns
SD
rd
eatin
syrup,
okay,
seeing
any
violent
disagreement,
that's
good!
So
just
one
quick
slide
on
the
hybrid
proxy
draft.
It
might
be
that
Stewart
has
something
in
his
deck
about
this
as
well.
B
Essentially,
the
0-6
update
was
published
some
time
ago,
whose
renaming
the
hybrid
proxy
discovery
proxy.
As
we
agreed.
That's
up,
there's
just
a
I've
done
the
Shepherd
report.
It's
just
a
couple
of
things
to
iron
AG
one
is
changing
the
reference
from
home
to
home
DARPA
and,
secondly,
there's
a
little
bit
of
confusion.
It
seems
over
the
IP
our
statement
that
I
had
a
discussion
and
that
was
Stewart
and
we
just
emailed
the
Secretariat
check.
B
What's
going
on,
it
looks
like
they
might
have
erroneously
withdrawn
the
statement
on
this
document
when
they
were
withdrawing
other
than
the
requirements
document
that
originally
erroneously
had
the
IPR
statement
on
it.
So
anyway,
we're
in
touch
with
the
cataria
and
hopefully
will
resolve,
who
had
that
removed
and
then
take
it
from
there.
Okay.
B
And
then
DNS
Bush
again
I
think
Stewart
might
be
mentioning
this
in
his
deck,
the
the
there
was
a
very
small
number
of
changes
going
to
dr.
12,
which
is
the
version
we
intend
to
push
upwards
and
I've
just
emphasized
in
bold
there,
the
main
difference
which
was
allowing
the
client
to
talk
to
its
normal
DNS
for
cursive
resolver,
or
try
to
talk
to
it
first
before
talking
directly
but
I
think
sure
it
might
come
on
to
that
later.
So
heads
up
on
that
one,
okay,
so
that's
it
for
the
the
introduction.
C
Christian
Christian,
before
you
start
I
have
I
have
an
announcement.
This
is
going
to
be
my
last
meeting
as
working
group
co-chair
I'm,
going
to
step
down
if
you're,
if
you're
interested
in
becoming
a
co-chair
of
the
the
DNS
SD
working
group
working
with
this
guy,
who
makes
it
all
very
easy,
it's
really
a
pretty
straightforward
working
group
to
to
to
manage
and
run
please
contact
either
myself
or
Tim
or
our
fearless
area.
Director
Terry
thanks.
G
H
J
J
J
J
We
published
a
revision
that
answers
the
first
question.
I
hope
we
have
not
published
a
revision,
and
so
in
Ted's
question
yet
because
I
mean
time
so
I
have
here
a
couple
of
issue
that
Ted
waste
and
I
thought
it
was
be
good
to
review
them
one
by
one,
because
I
meant
I.
Don't
give
you
everything.
Some
of
the
test
comments
are,
as
he
thinks,
we're
kind
of
just
fixin.
There's
no
point
there,
but
some
we
need
to
maybe
explain
it
more.
J
The
privacy
exchange
rely
on
a
shirt
on
on
a
shared
key
between
pairs
of
hose
pairs
of
nodes
and
Ted
was
asking
the
questions
hey.
Why?
Don't
you
guys
use
public
key
technologies
since
more
modern
and
it
was
actually
a
very
deliberate
decision.
Is
that
public
key
technology
means
that
your
public
key
is
an
identifier
and
the
public
key
exchange
is
failing
out
to
the
public
key
exchange.
That
does
not
disclose
the
public
key,
and
so,
if
you
are
try
to
do
privacy,
public
key
is
not
inside
the
right
fit,
not
not
immediately.
J
So
that's
the
reason
why
I
mean
the
other
thing
is
that
a
private
key
exchange
it
that
is
known
as
a
shared
secret
between
two
nodes,
when
it
is
used,
provide
an
immediate
verification
that
you
know
with
the
other
guy.
So
you
know
what
to
disclose.
Why
so
as
the
public
key
man,
you
would
have
to
have
a
pair
of
public
exchange
to
do
that
and
so
death
currency
is
welcome
because
it
will.
It
will
force
us
to
check
back
at
the
text
that
we
have
to
make
sure
to
explain
the
rationale
properly.
K
J
J
We
make
the
Devonian
who
operates
on
an
M.
It's
basically
the
way
you
do
a
secret
handshake
is
that
you
have
the
knowns
and
and
and
and
a
shut
secret,
and
you
compute
a
hash
of
that
and
you
you
verify
that
they
both
know
the
harsh
and
it
can
let
much
what
you
expect
and
to
simplify
the
protocol.
We
decided
to
make
the
hash,
but
for
the
norms
the
function
of
time,
the
value
of
making
the
non
harsh
a
function
of
the
time
that
both
ends
can
predict
the
nonce.
J
J
Situation
needs
to
be
just
as
good
as
say
one
minute
or
something
like
that,
but
yeah
at
the
end
of
the
interval.
Yeah
people
are
going
to
switch
from
these
slice
of
five
minutes
to
the
next
size
of
five
minutes.
And
if
you
are
not
careful,
I
mean
one
will
believe
that
they
are
before
this
one
will
be
if
they
are
after
and
they
won't
get
too
much.
In
fact,
it's
something
we
sort
of
an
in
fact
in
the
prototype
implementation,
where
the
fix,
but
we
did
not
document
it
properly
in
the
text.
J
So
we
fix
that
in
the
Russian
two
by
saying:
hey
what
your
xxx
do
is
that
if
you
are
at
the
end
of
the
interval,
you
also
consider
the
next
hash
and
if
you
are
the
beginning
of
the
end
of
all
your
code,
also
consider
previous
ash
and
that's
why
you
you
eliminate
the
edge
condition.
So
we
documented
that
in
Indore.
J
For
the
issue
that
was
raised
by
Tara
say:
hey
these
business
of
updating
your
ash
F
at
a
short
interval.
That's
fine
when
you're
doing
broadcast,
because
there
is
no
state
and
nobody
cares.
Is
it's
a
bit
more
problematic
when
you
are
when,
at
the
end
of
the
interval,
you
have
to
push
an
update
to
a
server,
because
if
you
end
up
pushing
frequence
of
deaths,
every
five
minutes
to
the
server,
then
you
have
server
overload,
not
to
mention
a
peak
of
load
at
that
exact
time.
L
What
I
was
concerned
about
is
not
so
much
load
on
the
server
which
I,
don't
think,
is
really
a
serious
issue,
but
rather
that
the
caching
behavior
of
a
DNS
sd
client
will
be
such
that
it
will
remember
records
for
longer,
potentially
than
than
the
lifetime
of
these.
If
the
lifetime
of
these
things
only
five
minutes,
yeah.
J
L
L
That's
been
transmitted
multicast,
recently
yeah
and
when
you,
when
you
tune
things
up
so
that
you
have
two
multicast
more
often,
it's
really
not
that
good
of
a
thing
to
do
so,
unless
there's
a
serious
and
the
the
reason
why
I
made
the
suggestion
is
because
I
didn't
really
think
that
there
was
a
serious
risk
of
replay
attacks.
That
would
be
mitigated
by
making
the
interval
five
minutes
rather
than
30.
Well,
it's
I
mean
the
yeah.
J
So
basically,
what
you
did
was
a
replay
attack
is
that
you
can
discover
was
on.
Someone
is
at
the
location
yeah.
So
the
the
concern
we
have
is
that
someone
listen
to
a
hash
two
to
one
of
those
notes
at
one
location
and
then
replace
it
at
another
location
to
see
whether
your
body
has
moved
to
that
also
location
right.
L
L
J
You
make
it
for
you,
you
suggest
forty
minutes,
and
that
means
that
basically
I'm
exposed
that,
if
I
move
to
here
to
someplace,
as
in
forty
minutes,
that
move
might
be
discovered.
Now,
of
course,
in
40
minutes,
I
can
only
move
in
the
next
town,
basically
so
yeah.
That
risk
is
only
the
best
level
yeah
that
that's
what
it
is
yeah.
L
I
mean
there
there's
it
seems
like
there
are.
There
are
some
attacks
that
you
can
do
that
that
if
you,
if
you
have
that
degree
of
control
over
the
network
infrastructure
and
a
whole
bunch
of
different
hotspots
in
various
places,
there
are
a
lot
of
games
that
you
can
play
to
to
know
that
not
so
much
know
that
a
particular
device
has
moved.
L
But
if
you,
if
you,
if
you
know
about
a
number
of
devices-
and
you
can
watch
them
looking
at
each
other,
then
you
may
be
able
to
learn
a
fair
amount
about
about
their
associations
by
having
this
kind
of
overview
that
you're
talking
about.
So
that
seems
to
me
to
be
a
bigger
risk
actually
than
this.
It.
L
J
L
I'm
fine,
what
I
would
actually
suggest
is
is
that,
if
you're
using
the
the
registration
protocol,
five
minutes
is
fine,
because
it's
all
unicast
and
I
don't
care
the
load
on
the
server.
Isn't
that
much
if
it's
multicast,
then
I
would
want
you
to
use
a
longer
interval,
because
the
load
that
you're
creating
as
long
as
larger
you
see
what
I
mean.
Oh.
L
M
M
J
J
J
J
J
N
O
From
Jabba
cremated
life
Dave
Taylor,
so
if
there
are
use
cases
that
are
important
where
say
one
end
does
not
have
a
source
of
absolute
time.
I,
don't
know
if
there
some.
You
know
I
OT
case
amin.
Stewart
was
arguing
the
other
day
about
you
know
using
dns
SD,
for
you
know,
constrained
environments
and
things.
If
there
is
a
case,
have
you
actually
looked,
how
much
weaker
does
it
get?
And
I'm
not
saying
you
should
do
this.
This
is
actually
legitimate
question.
O
How
much
weaker
does
it
get
if
you
had
a
way
for
the
requester
to
put
in
its
guess
as
to
what
the
absolute
time
is,
which
should
be
public
information,
because
everybody
really
ought
to
know
that
right
and
if
the
receiver
then
just
simply
trusted
that,
because
that's
not
the
only
thing,
that's
computing,
the
hash
over
how
much
weaker
is
a
crypto
get.
Is
my
question
in.
J
O
O
Had
I
don't
know
if
it
already
does,
but
calling
that
out
in
the
privacy
consideration
and
the
security
consideration
section,
it's
probably
a
good
thing,
because
that
might
become
a
frequently
asked
question:
okay,
okay!
Well
perhaps
you
know
if
you
want
to
use
it
for
that,
here's
what
you
lose
right!
Yes,.
Q
Stuart
Cheshire
from
Apple
I
wanted
to
thank
uncial
for
her
comments
and
explain
a
bit
of
backgrounds
which
it
probably
l,
people
in
the
room
wouldn't
know
it's
very
easy
for
us
to
say.
Well,
we
assume
the
clocks
are
synchronized
and
Anne
Shiell
has
spent
a
long
time
working
the
TP
working
group
working
at
houses
how
to
synchronize
clocks,
yes
securely
so
there's
a
lot
of
thorny
issues
here
and
I.
Think
it's
worth
discussing,
probably
not.
We
shouldn't
rattle
on
it
right
now
in
this
meeting,
but
I
do
think
it's
an
interesting
area.
J
J
Fine,
so
we
will
link
to
so
longer
intervals
and
we
will
add
consideration.
J
When
a
device
advertise
itself,
it
advertised
the
list
of
instances
that
are
present,
which
is
F
activities
of
pairing
and
the
number
the
number
of
pairing
in
this
list
is
a
property
of
the
device.
So,
whether
you
have
eleven
of
seven
or
or
twelve
can
be
used
to
cannot
identify
you
and
third
suggestion
was:
should
we
do
some
kind
of
fuzzing
there
to
break
that
kind
of
fingerprinting
and
it
turns
out
that
in
our
prototype,
what
we
do
that.
J
So,
yes,
again,
that's
something
that
we
cannot
document
in
the
Security
section
as
one
of
the
mitigations
it
has
about
zero
cost
because
I
mean
you,
you
just
add
a
couple
of
random
numbers
at
the
end
of
of
your
thing,
and
people
will
compare
them,
but
it's
just
the
number
of
comparison
is:
doesn't
increase
the
cost
widely?
That's
so
we'll
do
that
and
another
suggestion
was
hey.
We
are
doing
discovery
there
for
services
and
it's
all
about
instance,
name
in
SS
of
the
SLV
recalls
and
things
like
that.
J
What
about
application
like
SSH
that
are
basically
just
using
the
host,
mem
and
and
yeah
and
in
fact
again
that
something
that
Daniel
implemented
in
his
in
his
moto
types?
What
he
says
is
basically
what
you
do
is
that
you
discover
the
privacy
service.
You
verify
the
IP
address
of
the
privacy
service
about
the
secure
channel
and
you
tie
that
IP
address
to
a
host,
a
private,
local
or
some
such
name.
That
can
then
be
used
as
a
host
name
basis,
I
a
simplement
ation
of
that.
J
J
P
J
Pairing
draft
Genesis,
D
pairing
basic
e-discovery
week.
We
license
all
shelf
secret
and
we
wanted
to
have
at
least
one
method
of
establishing
those
charge
secrets.
So
we
have
the
paragraph
explaining
this
explaining
a
photo
shoot
in
professors.
You
do
discovery
using
mdns
or
DNS
SD,
and
you
use
the
key
argument
protocol,
which
is
in
our
case
just
doing
of
a
TLS
anonymous
connection.
J
You
can
remember
a
secret
and
and
use
that
forward.
So
it's
very
straightforward,
there's!
No!
No
difficulty
can
be
implemented
in
a
very
simple
way.
So
the
appointment
that
we
had
very
few
with
you,
we
had
a
video
from
Steve
Kent
back
in
January
and
it
was
nice
I
mean
wait,
give
us
a
lot
of
feedback
and
we,
but
basically
steeper
said
yeah.
It's
fine
I
mean
the
document
is
fine
and.
Q
J
Yeah,
thank
you,
and
so
basically
we
are
very
few
reviews.
Demand
and
after
Steve
contribute
that
that
was
the
next
one,
and
so
we
did
a
revision
before
that,
with
the
mostly
clarification
based
on
owner
proofreading
and
all
that.
But
there
that's
what
you
request
was
a
couple
of
clarification
and
I'm
not
going
to
go
into
the
trifurcation
and
then
to
big
suggestion
relative
to
QR
codes
and
to
analyze
system
spec,
so
QR
codes
in
our
draft,
we
proposed
an
option
to
use
QA
QR
codes
as
a
way
to
speed
up
the
user
interface.
J
The
QR
code
are
grafted.
On
top
of
the
previous
protocol.
We
can
use
one
QR
code
as
part
of
the
discovery
in
which,
instead
of
doing
a
network
exchange
for
discovery,
you
read
the
QR
code,
and
that
gives
you
a
unique
private
name
that
you
can
discover
safely
and
the
at
the
end
of
the
exchange.
Instead
of
manually
reading
the
number
on
the
other
screen,
you
read
the
QR
code
and
then
you
compare
it
to
what
you
have
on
your
screen.
J
So
it's
really
UI
sauce
on
top
of
the
existing
protocols,
and
that's
pointed
at
a
it
feels
like
a
separate
thing.
It
should
be
separated
and
at
that
point
I
have
two
options:
I
mean
and
I
would
like
to
get
feedback
from
the
coupon
on
those
two
options.
One
option
is
to
leave
it
in
document,
but
maybe
move
it
to
a
another.
Chapter
of
the
document
says
hey.
If
you
can
tweak
your
code,
you
can
do
this
and
that
will
that
will
make
your
UI
simpler.
J
J
J
He'll
be
scared
as
a
I
need
to
analyze.
That
I
need
to
understand
that.
Let
me
read
that
for
week
or
two
and
then
I'll
tell
you
so
so
that
suggestion
was
a
split
to
two
draft,
but
the
analyst
is
informed
in
one
to
Avenue,
one
in
function,
ref
see
and
put
the
specification
in
a
shop
Standard
Oil
to
see
which
is
simpler
and
will
be
implemented
quickly
and
we'll
have
less
a
minute
will
guarantee
more
on
top
beauty
and
actually
stiff
can't
met
the
exact
same
second.
J
We
delayed
that
because
a
feedback
in
Chicago
was
a
wait
a
bit
until
we
do
that,
but
I
can
definitely
do
it.
The
fire
hose
is
that
if
we
split
the
document,
we
have
to
redo
all
the
last
hole
and
all
that,
but
it's
a
bit
okay,
so
that
that's
pretty
much
where
we
are,
and
the
next
step
is
basically,
if
my
understanding
is
that
the
private
discovery
gloves
is
basically
ready.
Emails
is
no
question,
but
the
doll
for
the
pairing.
J
B
That's
a
really
good
summary
that
Christians
produce
the
zero
three
I
think
it
is
for
the
privacy
and
check
the
people
who
made
the
comments
are
happy
with
those
resolutions
and
we'll
push
that
up
on
the
pairing,
yeah
I
think
Steve
and
Ted
have
both
made
the
comment
about
splitting
it
and
I
think
we're
on
the
fence.
So
to
speak
about
that.
I
I.
Think
your
comment
about
making
it
as
simple
as
possible
to
pass
to
someone
to
implement
is
actually
a
very
good
one.
B
L
Lemon
so
yeah
I
mean
I,
actually
read
the
doc.
I
deliberately
did
not
read
sections
two
and
three
I
saw
the
thing
in
section
1.2
about
you
know
the
rationale
for
maybe
splitting
and
I
thought.
Well,
let's
test
this
and
so
I
just
said:
okay,
I'll
start
I'll
start
with
section
4
and
I
read
section
4
and
I
was
like
wow.
This
is
really
easy,
see.
L
Not
capture
that
experience
for
other
potential
users
of
this
document,
the
the
explanation
of
the
theory
is
really
great,
like
I
really
enjoyed
reading
that
it
was
very
helpful,
so
I
don't
mean
to
say
that
it's
not
useful
I.
Just
think
that
if
you
put
it
in
the
same
document,
yeah
you're
you're
running
the
risk
that
somebody's
gonna
do
exactly
what
you
said.
They're
gonna,
look
at
it
and
they're
going
to
say
whose
is
hard
yeah.
B
I
L
On
the
topic
of
the
QR
code,
I
think
the
idea
of
actually
separating
a
tentative
section.
Five
is
a
good
one.
My
main
concern
about
the
QR
code
is
actually
that
the
UX
isn't
very
clear
like
it
would
be
good
to
actually
have
a
little
intro
section
in
section
5
yeah.
That
says
this
is
what
the
user
will
do,
because,
yes,
you
know,
I
can
tell
you
what
the
user
will
do.
I've
read
the
document,
but
but
it's
not
entirely
obvious
and
the
UX
is
actually
a
little
weird
yeah.
P
L
And
you
I
think
you
really
have
to
want
privacy
to
want
that
UX.
Yes,
so
so,
if
you
really
want
privacy,
then
yeah
absolutely
it's
nice
to
be
able
to
just
take
a
snapshot
of
the
SRV
record
yeah.
But
if
you
don't
like
it's
gonna,
be
really
hard
to
explain
that
to
somebody
who's,
not
savvy
about
security,
yeah
and
the
the
thing
that
you
lose
by
not
doing
it
is
relatively.
You
know,
it's
not
a
thing
that
I
would
be
concerned
about.
L
R
Carolyn
Christian
I
was
wondering
if
you
were
aware
of
the
EAP
newbs
proposal
that
was
presented
in
the
t2.
Trg
summary
you
know
working
group
or
research
group,
the
other
day
by
Malik
study
and
his
collaborators,
but
it
basically
is
based
on
this
idea
of
using
dynamic
QR
codes
for
network
admission
control
and
so
I,
don't
know
if
there's
some
may
be
shared
primitives
and
particularly
shared
UX
that
you
guys
could
potentially
talk
about.
But
as
we
you
know,
try
to
package
this
stuff
up.
For
you
know
just
unsophisticated
users
it'd
be
really
great.
J
B
S
J
S
B
O
P
J
P
I
P
B
B
B
J
J
J
P
O
You
can
leave
it
as
it
is
now
you
can
move
it
as
Christians
proposing
or
you
can
split
it.
A
separate
document
I
think
the
example
that
Kerry
gave
is
a
possible
argument
as
to
why
a
separate
document
might
make
sense
if
you
would
tend
to
say
exactly
the
same
thing
about
the
UI
as
you
would
in
the
other
draft,
and
maybe
a
third
one,
and
so
on.
You
know,
I,
don't
know
if
there's
value,
but
it
is
value
and
asking
the
question
that
way
to
see
what
they're
suppose.
B
D
B
Q
Q
So
bit
of
a
reminder
about
why
we're
doing
this
because
we
have
multicast
dns
multicast
is
expensive
or
unreliable,
or
both
on
many
newer
network
technologists
on
the
old
coaxial
Ethernet.
You
stick,
the
vampire
tap
in,
and
all
the
packets
go
everywhere
anyway,
so
it
doesn't
matter
on
Wi-Fi
as
we've
gone
to
higher
data
rates,
multicast
has
not
kept
up,
so
the
disparity
between
unicast
and
multicast
has
got
much
bigger.
Q
A
battery
savings
on
phones
and
tablets,
as
meant
multicast,
is
much
less
reliable
on
Wi-Fi
when
we
have
more
complicated
home
network
topologies
that
aren't
a
single
link,
link-local
multicast
doesn't
go
everywhere.
When
you
have
mesh
networks
like
a
to
2011's,
supporting
multicast
multicast
reliably
is
very
cumbersome
and,
of
course,
on
enterprise
networks.
Most
enterprise
networks,
I,
would
say
today
just
block
multicast
at
the
AP.
Q
So,
there's
a
number
of
reasons
we
want
to
get
away
from,
depending
on
multicast,
quick
state
of
summary,
Ted
and
I
have
been
working
hard
and
we
got
our
four
brand
new
dog
before
this
meeting,
and
there
are
now
enough
documents
that,
unless
you've
been
following
this
from
the
start,
it's
not
clear
how
they
all
fit
together.
So
that
really
called
for
a
road
map
document
and
I'll
talk
about
these
others.
In
a
bit
more
detail.
We
have
a
way
of
registering.
Q
Instead
of
using
multicast,
we
have
the
broker,
which
provides
a
layer
of
indirection
for
the
discovery
proxy,
and
we
have
something
that
Ted
came
up
with
the
idea
of
a
relay.
That
is
a
compliment
to
the
discovery.
Proxy
three
of
our
documents
have
been
updated,
yet
minor
updates
the
discovery
proxy
document
is
basically
finished,
not
expecting
any
changes.
There
is
this
issue
about
updating
the
reference
to
dot
home,
which
is
a
trivial
change.
Q
It
depends
on
push
which
depends
on
session
signaling,
which
is
currently
still
being
debated,
and
we
are
trying
to
push
that
along,
but
that
is
that
is
where
that
sits
right.
Now
two
documents
were
not
written
and
as
a
result
of
the
discussions
with
Ted,
he
has
kind
of
talked
me
around
to
the
point
of
view
that
we
don't
need
these
and
that's
why
I'm
mentioning
it
to
get
the
sense
of
the
room.
If
other
people
agree,
the
advertising
proxy
was
conceptually
the
mirror
image
of
the
discovery
proxy.
Q
The
discovery
proxy
is
what
lets
a
remote
device
say:
I'm
not
on
that
link
over
there.
But
can
you
do
discovery
for
me
on
my
behalf?
The
advertising
proxy
would
be
the
counterpart
where
a
device
offering
a
service
like
a
sensor
or
a
controller
like
a
light,
switch,
could
say
I'm
not
on
that
network.
But
can
you
advertise
the
service
that
I
provide
using
multicast
and
a
related
issue
is
when
you
have
multiple
links
in
the
home?
You
don't
the
names
to
be
duplicated,
so
we
want
to
waited
to
deduplicate.
Q
The
names
and
Ted
made
this
point
that
we're
doing
all
this
work
to
move
away
from
multicast,
because
there
are
a
number
of
reasons:
it's
not
just
desirable.
So
do
we
really
want
to
put
a
lot
of
effort
in
perpetuating
more
use
of
multicast
and
when
you
put
it
that
way,
I
thought?
No.
We
don't
so
unless
other
people
feel
strongly.
My
filling
right
now
is.
We
should
drop
this
and
and
really
consider
I'm,
seeing
nodding
from
Dave
Thaler
there.
So
that's
good.
Q
C
Q
Q
Because
of
all
these
little
pieces,
I
actually
think
it's
good
to
break
independent
things
into
separate
documents.
Ted
made
the
comment
that
if
you
want
an
implementer
to
look
at
something
something
that
seems
small
and
approachable
is
a
lot
more
attractive
than
a
hundred
page
spec
they've
got
to
wade
through
so
where
things
do
naturally
decompose
into
modules.
I
think
that's
great,
but
knowing
how
these
Lego
blocks
stacked
together
then
becomes
a
challenge.
So
I
have
taken
a
first
cut.
Q
This
is
just
a
draft
zero
zero,
but
this
is
a
start
at
doing
the
roadmap
of
how
these
fit
together-
and
this
is
a
few
pictures
to
elaborate
on
that.
So
a
client
gets
a
configuration
from
the
network
here
at
the
IETF.
The
network
is
telling
your
devices
you
should
look
in
meeting
dot,
IETF
dot-org
the
mechanism
for
that
is
in
RFC
67-63,
so
I
won't
spend
time
repeating
that
now,
but
the
client
gets
configured
automatically
or
you
can
do
it
manually
if
you
want
to
type
it
in
how
that
happens.
Q
Is
is
a
separates
question,
but
once
that
is
done,
the
client
then
follow
those
instructions,
and
it
says
I'm
going
to
query
link
1
dot,
example.com.
Well,
the
normal
DNS
NS
record
delegation
hierarchy
tells
the
client
and
that
this
device
on
the
network
is
the
authoritative
server
for
that
domain
name.
So
the
client
sends
its
query
there
and
the
discovery
proxy
instead
of
consulting
its
own
file
on
disk
like
a
normal
DNS
server.
It
uses
multicast
queries
to
find
the
answer
to
that
question.
Guess
the
replies
sends
them
back
to
the
client.
Q
Q
The
client
can
be
configured
to
look
in
more
than
one
domain,
which
has
a
number
of
useful
applications,
so
you
might
tell
it
to
look
in
three
domains
and
it
will
then
query
three
links.
Three
different
discovery
proxies
and
discover
three
different
sets
of
servers
and
get
all
of
those
results
back
and
present
them
in
the
UI.
This
is
done
and
implemented
today
and
works.
Q
Fine,
when
you
have
more
clients,
all
of
the
clients
are
talking
to
all
of
the
discovery
proxies
and
if
your
discovery
proxy
is
a
little
bit
of
software
built
into
your
Wi-Fi
access
point.
It
may
not
be
engineered
to
handle
thousands
of
connections
and
the
clients
if
they're
battery-powered
may
not
want
to
have
multiple
connections.
So
the
solution
here,
Oh
before
I,
get
onto
that
little
tidbit
I
wanted
to
point
out
because
it
may
not
be
obvious
clients,
don't
all
have
to
query
the
same
three.
Q
So
a
client
here
might
be
directed
by
the
network
to
query
three
different
links
and
a
client
here
will
query
links.
One
two
and
three
and
a
client
here
will
query
links
two
three
and
four.
So
if
you
had
say
like
a
long,
narrow
building
or
maybe
a
circular
building
that
sort
of
doughnut-shaped,
then
then
the
clients
in
each
segment
can
be
directed
to
the
network
to
query
their
segment
and
the
two
adjacent
ones.
Q
So
you
have
a
kind
of
sliding
window
effect
that
you're
discovering
things
that
that
are
nearby,
and
you
don't
have
the
issue
that
if
you
happen
to
be
right
at
the
edge
of
your
segment
you're
finding
the
thing
10
feet
away,
because
you've
got
this
plus
minus
1
overlap.
But
let's
go
back
to
my
simple
example,
where
all
the
clients
are
querying.
Everything
and
you've
got
this
big
mess
of
connections.
Q
This
is
where
the
discovery
broker
comes
in.
Instead
of
telling
the
client
to
look
on
this
link
and
this
link
and
this
link,
we
say
you
just
look
in
services
or
at
example.com
and
the
authoritative
server,
for
that
is
the
discovery
broker
and
where
it
gets.
Its
answers
from
is
not
a
zone
file
on
disk
and
it's
not
multicast.
It
is
unicast
DNS
queries
to
the
three
different
discovery
proxies
and
then
it
can
amalgamate
those
results
and
return
them
back
to
the
client
and
that
way,
if
you
have
multiple
clients,
each
discovery.
Q
Proxy
still
only
has
one
connection
to
one
discovery
broker,
which
is
a
big
iron
server
in
the
data
center,
and
each
client
only
has
one
connection
to
that
discovery
broke
up,
so
it
saves
battery
power
on
clients.
It
saves
CPU
load
and
resource
requirements
on
the
little
discovery
proxies
on
the
network.
So
that's
the
motivation
for
the
discovery
broker.
Is
it
lets
you
put
a
big
server
in
the
19-inch
rack
and
not
expect
every
little
access
point
or
every
router
on
the
network
to
support
thousands
of
clients.
Q
Q
Why
don't
we
do
that
so
here,
instead
of
having
a
full
heavyweight
discovery
proxy
on
each
link,
we
have
a
discovery
relay
which
is
like
the
bootp
relay
agent
for
service
discovery,
and
it
talks
to
one
client
and
that
client
is
the
actual
discovery
proxy.
So
we've
taken
this
piece
of
software,
the
discovery
proxy
and
split
it
in
half,
so
it
has
got
this
relay
agent.
Q
Q
So
that's
the
end
of
the
pictures
and
I'm
just
going
to
run
through
the
rest
of
what
the
roadmap
document
covers
and
how
that
relates
to
the
documents
and,
in
my
mind,
the
way
I
divide
this
up
is
in
three
parts
is
how
data
gets
into
the
namespace
so
that
it
can
be
queried
part.
One
is
all
the
legacy
multicast
dns
devices
that
we
have,
and
the
answer
is
the
discovery.
Proxy
is
the
backwards
compatibility
story
for
existing
devices
and
it
builds
on
these
other
two
documents.
Q
The
relay
is
not
a
modification
to
that
document.
The
behavior
of
the
discovery
proxy
is
exactly
the
same.
The
only
difference
is
instead
of
having
a
physical
en
zero
Ethernet
Ethernet
interface,
that
it's
sending
receiving
packets.
On
it's
now
got
a
remote
virtual
interface,
almost
like
a
VPN
tunnel
to
somewhere
else,
but
the
behavior
of
the
packets
sent
and
received
over
that
virtual
interface
are
exactly
the
same.
Q
So
that's
the
legacy
story.
Part
two
looking
to
the
future
is:
how
do
we
want
to
do
this
without
so
much
reliance
on
multicast,
and
that
is
active
registration?
So
to
that
end
we
have
a
draft
0/0
on
what
we
are
calling
the
Service
registration
protocol,
which
in
a
way
is
just
another
name
for
DNS
update
with
some
profile
or
set
of
use
cases
imposed
on
it.
We
use
DNS
leases
as
a
way
to
do
automatic,
garbage
collection.
So
if
a
device
goes
away,
its
data
doesn't
persist
forever.
Q
At
EDD
came
up
with
a
very
interesting
idea
of
how
to
do
useful
security
without
onerous
configuration
and
that's
first-come,
first-serve
security.
When
you
connect
a
device
to
the
network-
and
it
says
my
name
is
X,
then
if
that's
the
first
time
it's
been
on
the
network
and
it
has
physical
connectivity
on
your
link,
then
you
say:
ok,
I
trust
you!
Q
You
can
register
the
name
X
and,
along
with
doing
that,
it
registers
its
public
key,
which
has
a
much
longer
lifetime
that
the
key
might
have
a
week
or
a
month
lifetime,
whereas
the
other
records
are
only
an
hour.
If
you
then
turn
that
device
off,
it
will
disappear
from
your
network.
It's
not
there
anymore,
but
its
key
will
linger
and
if
something
else
comes
along
and
tries
to
masquerade
as
that
device,
the
registration
server
will
reject
it
and
say
no
you.
Q
You
can't
tell
me
your
Stewart's
printer,
because
I
know
Stuart's
printer
and
your
knots
to
us
princess
printers
turned
off
right,
but
I'm
not
going
to
let
you
jump
on
the
network
and
start
capturing
those
print
jobs,
so
that
is
described
in
the
service
registration
document
or
at
least
a
simple
outline
of
it.
I
like
that
idea,
because
it
gives
it
gives
better
than
no
security
without
difficult
keys.
Q
It
doesn't
replace
some
of
the
other
things
we're
talking
about
like
QR
codes
and
other
things
that
may
be
better,
but
I
think
there
are
cases
where
this
might
be
an
appropriate
solution
and
then
the
other
optional
addition
here
is
the
energy
saving
stuff,
because
power
management
is
really
important
in
today's
world,
especially
battery-powered
devices,
the
whole
Internet
of
Things
home
automation,
many
of
those
devices,
especially
door
locks
or
isn't
an
interesting
example,
because
it's
hard
to
run
a
power
cable
through
the
door
hinges.
So
almost
all
door
locks
have
to
be
battery-powered.
T
Q
The
model
there
is
that
you
would
have
to
go
to
the
administration
page
for
your
home
gateway
and
manually
erase
the
device,
so
it
could.
It
could
not
get
on
the
network
without
you,
as
a
human
author,
izing
that
exception
and
saying
yes,
I
actually
do
mean.
This
really
is
my
new
device
and
I
trust
it.
Thank.
S
You
make
sense:
yeah
Michael,
Lorenzen,
same
question:
I
like
I,
have
an
open,
WT
device
at
home.
My
factory
defaulted
and
my
ssh
key
goes
away,
and
I
have
to
do
these
ssh
keys
again.
So
this
is
a
very
common
case,
so
whoever
makes
this
administration
page
device
this
should
be
like.
It
needs
to
be
pretty
easy
for
people
to
understand.
What's
going
on
and
like
the
failure
case,
how
to
make
that
understandable
to
the
user
and
Camelot
is
interesting.
It.
S
P
O
What
wins
server
is
also
known
as
NetBIOS
name
servers
do
in
that
case,
specifically
for
enterprises,
because
you
do
have
to
be
able
to
span
well,
it's
temporarily
off
the
network
or
whatever,
but
I,
don't
remember
the
exact
details,
but
at
the
10,000
foot
level,
if
you
haven't
heard
from
it
and
so
long
where
so
long
might
be,
you
know
a
month
or
whatever
the
policy
is
a
week
or
a
day.
What.
O
Is
then,
when
you
need
to
know
you
unicast
to
that
guys,
IP
address
to
say:
do
you
have
this
name
right
and
if
it's
been
so
long
before,
you've
ever
heard
from
them
in
the
past
ring
that's
been
a
month
whatever
and
he's
not
there.
Now,
then
you
do
automatic
garbage
collection
and
you
just
throw
it
out,
and
you
pretend
that
you
never
got
it
in
the
first
place,
and
so
it's
like
having
a
TTL
on
that
record.
That
says
you
either
have
to
like
ping
me
or
re-register
or
be
on
the
network.
O
B
O
O
Q
V
Q
Think
if
you
implemented
it
only
in
RAM-
and
you
didn't
have
persistent
storage
that
survives
a
reboot,
you
would
get
weaker
security
properties
right
for
as
long
as
you
don't
reboot
it.
It
would
remember
the
keys
when
you
rebooted
it.
It
becomes
another
first-come,
first-serve
scramble
and
during
that
window
an
imposter
could
get
on
your
network.
So
it's
it's
a
it's
a
judgment
trade-off
whether
you
think
that
security
downside
is
acceptable
or
whether
you'll
pay
the
extra
for
a
bit
of
flash
storage
in
that
device.
I
think
both
work.
Q
Q
T
T
Q
Thanks
for
raising
that
point,
I'm
not
gonna,
try
to
answer
it
right
now,
because
we'll
run
out
of
time,
if
it
automatically
renames,
then
that's
one
solution,
but
that's
also
unpopular
if
your
computer
changes
its
name
against
your
will.
So
that
is
a
thorny
user
experience
issue,
certainly
if,
if
I
am
connecting
for
some
reason,
file
sharing
screen
sharing
some
kind
of
service
to
David's
MacBook
here
at
the
IETF
I
to
suddenly
get
the
wrong
one
tomorrow,
which
is
the
point
of
this
security.
R
Carolyn
I
just
wanted
to
raise
the
point
that
came
up
during
the
privacy
discussion
earlier
about
the
fact
that
this
is
a
persistent
identifier
that
might
expose
some
information,
so
you
might
want
to
at
least
note
that
the
security
concerns
section.
Why
not
take
a
look
at
the
secret
handshake?
You
know
sort
of
technology
that
we've
been
discussing.
Yes,.
Q
Q
Q
Q
F
Q
F
Q
They
have
some
similarities
in
terms
of
the
operational
issues
of
where
you
put
the
hardware.
They
both
have
the
advantage
of
putting
less
demand
on
the
little
nodes
out
in
the
edges
of
the
network,
the
discovery
relays
more
lightweight,
because
in
the
other
picture,
you
really
have
a
full-fledged
discovery.
Proxy.
That
knows
how
to
do
the
rewrite
rules.
It
may
have
some
application
specific
optimizations
in
it.
Q
F
Q
Point
of
view
it
is
using
standard
or
standard
ish
DNS.
If
you
can't
the
push
notifications,
it
is
using
those
standard,
ish
mechanisms
to
do
its
queries
and
the
client
doesn't
know
whether
it's
talking
to
an
authoritative
server
with
a
text
file
a
broker,
a
proxy.
It
could
be
talking
to
a
broker.
That's
talk
to
another
broker,
that's
talking
to
a
proxy.
The
client
I
mean
that's.
One
of
the
benefits
here
is:
is
those
arrows
on
the
left-hand
side
are
the
same
protocol
in
all
cases.
Q
F
Q
Q
The
Discovery's
broker
is
a
unicast
to
unicast
gateway
and
it
exists
to
do
a
fan-out
so
that
one
unicast
query
comes
in
for
services
on
example.com
and
that
may
be
fanned
out
to
two
three
four
five
individual
queries
on
the
other
side:
the
Discovery
proxy
never
does
a
fan-out.
It's
always
a
one-to-one.
A
query
comes
in
for
link
wanted
example.com
and
a
query
goes
out
on
one
link
using
multicast,
so
it
is
a
one-to-one,
multicast,
unicast
or
multicast
translator.
The
broker
is
a
one-to-many
unicast
to
unicast
fan-out
multiplexer.
Q
Now,
of
course,
these
could
end
up
being
folded
into
one
piece
of
software
that
is
doing
all
of
that
under
the
covers,
but
in
terms
of
the
specifications.
This
is
why
I
kind
of
made
the
allusion
to
Lego
bricks
is,
it
may
tends
to
decompose
those
or
separate
logical
functions.
You
can
combine
them
in
imitation.
Absolutely
thanks.
P
B
W
It's
sort
of
it's
sort
of
a
it
started
out
by
me
wanting
to
be
able
to
find
my
devices
in
the
network
and
so
what
I?
What
I
wrote
was
a
sort
of
DNS
update
proxy
server
that
sits
in
front
of
an
authoritative,
DNS
server
and
we'll
do
the
first
come
first
serve
slash
trust
on
first
use
registration
protocol,
which
is
identical
to
what
what
Stewart
was
torturing
about
and
then
that
will
and
then
it
will
apply
some
policies.
W
You
can
say
only
talk
to
these
IP
addresses
disallow
certain
names,
disallow
certain
address
ranges
and
then
it
on
the
other
side
that
proxy
will
be
normal,
TCH
signed,
updates
or
it
can
update
Unbounce
upstream
server.
So
you
can
also
do
like.
If
you
have
you
on
your
network,
you
can
put
internal
addresses
and
one
and
global
DNS
and
the
other,
and
then
the
client
will
do
most
of
the
lookup
dance.
I
didn't
it
doesn't.
W
Quite
I
have
not
read
any
of
these
drafts
before
implementing
this,
so
I'll
go
and
change
that
to
support
this
and
it's
about
2500
months
ago
next
slide.
So,
and
these
are
the
main
differences-
and
this
was
before
I
spoke
to
Stewart,
if
not
highly
accurate
anymore,
but
instead
of
the
update
leases.
I
just
overload
the
TTL,
which
has
some
sometimes
I,
don't
know
if
we
can
discuss
that
on
the
list
later,
whether
or
not
like
it
allows
you
to
do
per
record
lifetime
from
the
client
to
like.
W
So
they
become
the
garbage
collection
times,
whereas
the
update
lease
that's
for
the
whole
thing.
So
that's
that's
introduced
that
it
just
it
only
speaks
TCP
so
that
you
can
put
this
thing.
Theoretically,
they
could
live
in
the
cloud
which
I
think
when
Beauty
is
talking
about.
You
need
flash
to
implement
this.
Well,
you
cannot
have
it
in
your
root
and
you
can
just
have
it
in
the
cloud
and
then
because,
if
you
use
TCP,
you
get
a
collect
back.
W
Should
you
don't
have
to
worry
about
spoofing
and
then
there's
a
server
grab
and
it
doesn't
do
the
sleep
proxying
and
it
doesn't
do
full
dns
service
discovery.
So
I
created
this
just
for
a
and
records
and
but
other
than
that
it
it
works
and
I
use
it
to
sort
of
fight.
My
devices
on
my
network
with
ipv6
and
it
goes
into
public,
DNS
and
so
on,
and
it
also
has
this
like.
You
can
also
use
this
once
you've
registered
the
key,
so
the
client
can
tell
the
server.
W
How
long
is
my
P
don't
need
to
be
around?
So
if
it's
a
client
that's
only
running
in
RAM,
and
it
knows
it's
going
to
go
away,
consider
with
a
short
lifetime,
but
once
you
have
the
key
you
can
keep
that
p.m.
and
you
can
in
principle,
allow
updates
from
anywhere
so
I
can
have
like
my
laptop
mydomain.com
refer
to
an
IP
address
and
at
ITF
it's
great.
B
B
L
C
L
L
L
The
modified
discovery
proxy
that
speaks
to
a
relay
proxy
can
still
speak
directly.
The
link
that's
connected
to
it.
It
can
also
use
a
real
a
proxy
to
speak
to
the
link.
I
expect
that
in
the
home
net
use
case,
which
is
the
one
that
mostly
informed
this
for
me,
the
relay
proxy
and
the
discovery
proxy.
Sorry,
the
discovery
relay
and
the
discovery
proxy
will
be
separate
devices.
Even
on
the
same
on
that
router-
and
of
course
it
can
speak
to
the
two
links
that
it's
not
connected
to
using
a
relay.
L
The
discovery
relay
is
really
stupid.
It
doesn't
do
any
translation.
It
just
receives
multicast
packets
from
the
it
receives
the
content
of
a
multicast
packet
from
the
discovery,
proxy
and
and
multicast
sit
on
the
approp
when
it
gets
multicasts
from
the
link
it
sends
them
to
the
discovery
proxies
completely
stateless.
L
There
isn't
a
request
response
kind
of
thing
going
on
it's
just
one
it
when
it
gets
a
multicast
from
the
link
it
sends
it
to
whatever
discovery
proxies
have
subscribed
to
that
link
and
when
it
gets
a
multicast
to
send
to
a
link,
it
sends
it
to
the
link,
there's
no,
nothing
more
than
that.
Any
caching
that
occurs
happens
in
the
discovery
proxy.
The
discovery
proxy
talks
to
resolvers,
even
though,
even
though
the
discovery
relay
is
speaking
unicast
on
the
upstream
side.
L
Regular
devices
are
not
ever
supposed
to
talk
to
it,
and
in
fact
we,
the
the
draft,
has
details
about
how
to
set
up
the
operation
of
it,
so
that
that
doesn't
happen,
because
it's
kind
of
important
that
it
doesn't
happen
yeah.
So
there's
a
ton
of
stuff
about
management
in
the
draft
that
may
seem
like
it's
superficial
or
unnecessary,
but
this
is
a
to
make
this
work
cleanly
requires
clearly
specifying
how
the
how
these
devices
are
discovered,
how
they
agree
on
the
on
the
identities
of
the
links
and
all
of
those
things.
L
The
management
stuff
just
to
I.
Have
this
this
like
issue
with
the
discovery
relay
in
the
discovery
proxy,
that
it's
not
clear
to
me
that
you
really
to
Discovery
relay
right
discovery,
relays
nice,
because
it's
smaller
than
a
Discovery
proxy,
but
it
adds
a
fair
amount
of
complexity
when
you
put
in
the
Discovery
relay,
however,
that
complexity
wouldn't
go
away.
If
you
didn't
have
a
Discovery
relay
in
the
automatic
configuration
case,
you
still
need
all
of
this
management
stuff,
whether
it's
automatically
configured
through
a
management
console
or
whatever.
L
You
still
need
to
be
able
to
say
so
suppose
we
well
so
you've
got
devices
that
are
that.
Are
you
got
the
central
device
that
answers,
queries
and
you've
got
all
these
all
of
these
routers
on
your
network,
each
one
of
which
may
be
a
discovery
relay,
and
you
have
to
configure
that
it's
the
central
server
to
speak
to
the
discovery
relays.
L
L
You
know
I
lost
my
train
of
thought,
so
the
point
is
that
that's,
this
operational
stuff
needs
to
be
specified
because
it
needs
to
be
it.
It
needs
to
be
the
case
that
when
you
have
a
network
with
this
kind
of
setup
that
that
everything
connects
cleanly-
and
you
don't
have
anything
left
out-
and
you
have
a
clean
way
of
saying
what
connects
to
what
so
that's
why
that's
that
management
stuff
is
in
the
document.
Has
anybody
read
the
document
by
the
way?
Well,.
B
P
B
I
think
I
mean
the
explanations
here
have
been
fantastic,
I
think
it's
based
on
the
fact
that
any
four
people
have
read
them.
It's
a
bit
early
to
ask
where
they're
talking
this
working
group
items
but
yeah
I
think
we're
gonna
have
some
good
list
discussion.
You
know
now
that
we've
had
them
introduced
yeah.
L
I
guess
I,
don't
the
the
main
high
level
stuff
that
Stuart
presented
is
the
stuff
that
I
really
wanted
people
to
see.
I
I
wanted
to
call
your
attention
to
the
management
stuff
because
it
is
it's
more
than
half
the
document
of
the
relay
document
and
the
reason
it's.
It
doesn't
necessarily
belong
in
the
relay
document.
B
L
C
L
L
B
B
Anybody
else
would
like
to
say:
we
have
one
minute
left
on
this
say:
okay,
great
thanks,
Ted
and
and
stewardess.
You
know,
I
think
people
have
got
a
really
good
idea
of
the
future
items
now.
So
the
last
item
on
the
agenda
is
Kari
who's
going
to.
If
I
can
find
it,
that's
the
mapping
one.
Isn't
it
it's
going
to
talk
about
the
interactions
between
the
core
resource
discovery
in
the
SSD
Interop.
We've
also
got
Caston
in
the
room,
which
is
great
to
join
any
discussion.
B
B
R
All
right,
so
I
will
do
that.
Basically,
I'm,
not
sure
if
we
have
deliverable
in
this
group,
but
I
think
we
at
least
have
the
desire
to
sort
of
discuss
this
topic
of
interoperability
between
what
the
core
working
group
is
doing.
Visa
Vee
resource
discovery
and
what
we're
doing
visa
Vee
service
discovery.
So
I
guess
my
job
is
to
I'm
just
gonna
start.
R
So
anyway,
this
work
historic.
No,
this
work
goes
back
actually
about
six
years.
Oh
yeah,
sorry!
This
work
goes
back
about
six
years.
Originally,
when
the
core
working
group
was
chartered,
they
did
not
have
a
requirement
to
do
their
own
discovery,
but
to
demonstrate
how
it
might
be
used
with
existing
discovery
mechanisms,
namely
DNS
SD.
My
colleague
Peter
van
der
stalk
and
I
did
a
bunch
of
drafts
in
core
talking
about
how
this
could
be
done,
but
eventually
core
decided
to
go
in
a
different
direction,
and
so
as
kind
of
a
stopgap
we
said
well.
R
R
R
The
main
deliverable
of
core
of
the
core
working
group
was
the
coop
constrained
application
protocol
building
on
other
IOT
standards
that
had
come
before
such
a
6lowpan
for
supporting
ipv6
over
constrained
links
and
ripple,
which
was
the
output
of
the
role
routing
group
coop,
originally
was
rest
with
a
UDP
binding.
An
interesting
side.
Note
there
is
that
multicast
restful
operations
are
now
possible,
so
the
rest
world,
basically
is
a
set
of
architectural
constraints.
R
Okay,
so
to
talk
a
little
bit
about
the
resource,
the
resource
discovery
method
that
they
came
up
with
it's
based
on
core
link
format,
which
in
turn
is
based
on
web,
linking
it
makes
use
of
these
things
called
type
links.
It's
basically
a
relation
between
one
link,
which
is
typically
the
thing
you're
asking
you
know
what
other
links
to
you.
Do
you
provide
to
these
other
links
which
are
target
links
and
the
relation
between
you
know
the
anchor
and
the
target?
N
R
Right,
that's
what
I
meant
and
obsolete
target
attributes
so
in
the
core
world.
You
basically
can
query
a
server
and
say
give
me
all
the
links
that
you
provide
by
doing
a
get
operation
to
a
well
known,
URI,
which
is
not
well
known,
slash
core
optionally.
You
can
provide
a
query
string
and
what
you
should
get
expect
to
get
back
from.
That
is
a
set
of
links
that
match
your
query.
So
the
core
link
format,
document,
RFC,
66
92,
find
some
new
target
attributes.
R
So,
as
I
said,
if
you
consider
a
restful
api
entry
point
to
be
something
like
a
service,
then
this
is
the
sort
of
resource
that
you
would
want
to
potentially
export
from
the
core
world
into
the
dns
SD
world.
I
should
back
up
and
say
that
as
an
efficiency,
core
is
also
positon.
Sub
resource
directories,
which
is
a
repository
of
all
this
information
from
all
the
links
that
exist
on
that
network.
So
the
logical
place
for
this
mapping
agent
to
contact
would
be
the
resource
directory
and
we
have
a
draft
that
sort
of
describes
this.
R
But
that's
a
working
group
item
over
in
the
core
working
group.
It
basically
defines
two
new
target
attributes.
One
is
exp,
which
is
a
hint
that
the
the
server
who
registers
that
links
as
I
want
this
to
be
exported
to
a
different
naming
system.
The
second
thing
that
we
have
is
an
AI
NS
attribute,
which
is
the
instance
of
that.
R
So
there
are
other
hints
that
can
be
provided,
such
as
the
domain
that
you
wish
to
be
registered
in.
If
that's
absent,
then
the
mapping
agency,
tential
e,
has
to
figure
out
you
know.
Is
there
a
good
candidate
you
know
for
for
the
the
the
domain
to
put
this
in
dot,
local
being
probably
the
obvious
default
hostname
if
it
doesn't
already
exist,
has
to
be.
You
know,
sort
of
cons
DUP
in
the
in
the
DNS
world
next
slide.
It's.
R
Right,
so
don't
take
this
too
literally,
there's
probably
mistakes
in
this
example.
In
fact
I
know
there
are,
but
the
color
coding
is
meant
to
sort
of
show
how
the
mapping
could
potentially
be
done.
So
here
the
mapping
agent
has
has
basically
done
a
query
to
the
resource
directory
and
it
says
give
me
everything.
Give
me
all
of
the.
R
Give
me
all
the
links
that
have
this
exp
attribute
set,
and
then
it
gets
back,
for
example,
a
response
where
the
resource
type
is
oh
I
see
temperature,
and
this
is
one
of
the
mistakes
should
be:
oh
I
see
dot,
RR,
dot,
temperature
but,
and
then
the
instance
name
is
indoor
temperature
and
the
interface
type.
Is
you
know,
kind
of
a
semantic
tag,
application-specific
semantic
tag
that
tells
you
how
to
operate
on
this
thing,
the
resulting
our
ours
is
that
a
host
name
was
synthesized.
R
If,
if
it
wasn't
provided
the
quad,
a
record
is
registered
and
we
end
up
with
a
service
of
type.
Oh
I
see.
This
is
the
thing
that
I
presume
would
be
registered
with
the
register
of
the
service
type
registry,
but
then
below
that
the
subtype
of
that
would
be
a
temperature
sensor,
and
then
we
would
basically
take
other
things
that
have
been
provided
and
they
would
be
text
value
pairs
that
would
be
put
into
the
text
record.
So
that's
basically
in
a
nutshell,
so.
Q
K
Link
format:
there
are
two
registries
so
that
the
names
that
are
under
RT
equals
and
the
names
that
are
under
IFE
codes.
They
have
a
registry,
and
oh,
is
he
EF?
Is
there
court
now
has
registered
some
some
a
te
resource
types
there.
So
this
is.
This
is
the
name
that
is
registered,
but
it's
not
a
service.
U
O
Q
Q
And
when
you
ask
for
a
string,
you
don't
ask
for
a
string
with
an
ampersand
in
it.
If
you're
trying
to
wholesale
import
names
from
somebody
else's
registry
with
a
different
set
of
rules,
then
they
might
not
follow
the
existing
Ayana
rules
and
would
either
have
to
change
the
rules.
I
mean
that's
a
bit
awkward
to
change
the
character
set.
Q
O
O
Temperature,
and
so
where
is
the
r
dot
in
here,
and
so
I'm
guessing
it
would
be
our
temperature
underscore
subbed,
on
other
words,
the
RS
and
the
very
left
end
it's
another
sub
label,
even
beyond
that
right
or
you
have
to
escape
butter
or
whatever.
It
is
right,
so
that
the
question
is
how
safe
is
it
to
assume
that
the
leftmost
label
is
the
one?
That's
special
I.
R
Q
Q
Q
It
sounds
like
exactly
the
same
thing,
but
every
time
I
talk
to
the
corporate
when
caster's
changing
his
head
shaking
his
head
right
now,
it's
like
noticed
on
service,
it's
a
resource,
but
the
description
of
resource
sounds
like
exactly
the
same
words:
I
used
to
describe
a
service,
so
the
a
I
think
would
help
this
discussion.
If
we
could
actually
figure
out
why
resource
is
not
a
service,
certain.
K
B
B
Well,
it's
good
is
now
coming
to
light,
so
he
can
discuss
it
sowing
encourage
more
discussion
of
that.
Thank
you
to
everyone
just
to
quickly
wrap
up
on
the
actions.
I
think
we've
got
a
fairly
clear
idea
of
what
Christians
doing
from
the
huns
and
votes
that
we
took.
I'll
just
confirm
that
on
the
list,
Stuart
stuffs
and
Ted
stuffs
a
little
bit
early
to
adopt,
because
only
four
people
have
read
it
so
far,
but
I
think
the
explanation
he
has
been
fantastic
and
we're
making
some
headway
now
on
the
Interop
here,
which
is
great.