►
From YouTube: IETF100-DNSSD-20171115-0930
Description
DNSSD meeting session at IETF100
2017/11/15 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
Our
chairs
today
are
gonna,
be
Tim
Lozinski
and
myself,
since
our
other
co-chair
Tim
shown
couldn't
make
it
all
the
way
to
Singapore
I
wanted
to
start
it
off
to
give
thanks
to
Ralph
drums
who's
been
chair
of
DNS
SD.
Ever
since
we
started,
and
so
I
think
he's
been
doing
a
great
job
and
I
would
love
if
the
room
could
give
him
a
quick
round
of
applause
for
his
years
of
service.
So
thanks
Rob.
A
Little
bit
about
myself,
I've
been
working
at
ball
for
three
years,
not
necessarily
on
DNS
SD
per
se,
but
closely
related
topics
and
happy
to
be
taking
out
this
new
position
of
chair.
This
is
going
to
be
fun
so,
first
and
foremost,
please
note
well
in
case
you
haven't,
read
this:
please
go
and
read.
B
A
You
ever
want
to
contribute
or
say
anything:
it
does
have
some
rules
related
to
it,
but
everyone
should
know
this
by
now.
Hopefully,
so
we
have
minutes
in
driver
scribes.
So
thanks
to
bjorn
barbara
for
taking
notes
in
the
ether
pad.
If
anyone
wants
to
look
at
it
and
feel
they
want
to
add
something
feel
free
to
do
so,
and
thanks
again
and
thanks
to
Michael
for
being
or
jabber
relay.
A
A
Useful
links
here
just
for
future
reference.
If
so,
you
want
all
the
slides
are
up
on
the
on
the
data
tracker
and
all
the
document.
Information
is
up
there
as
well
quick
update
on
status.
The
author's
will
go
into
more
detail,
but
DNS
habit
proxy
one
through
the
isg
Dennis.
Does
the
push
is
about
two
and
we're
still
working
on
getting
at
the
pairing
info
through
the
SR,
but
that
should
be
happening.
Sorry,
it
says
it
you
know.
A
Sessions
are
on
our
goals,
for
today
is
to
discuss
the
the
drafts
I
just
mentioned
and
kind
of
review
status
since
you
were
everything's
at
possibly
the
minor
changes
that
we've
seen
recently
do
a
quick
review
of
how
all
or
a
new
architecture
what
we're
trying
to
do
and
how
all
this
fits
together
into
a
very
useful
package
and
we're
gonna
have
a
longer
conversations
or
around
the
end
of
the
session
to
discuss.
Privacy
also
told
us
we'll
give
a
talk
on
grasp
and
how
that
integrates
with
gen
SSD.
C
D
C
C
C
C
C
C
Some
DNS
update
clients
require
you
to
put
in
the
address
of
the
server
you
want
to
send
the
update
to,
but
we
don't
like
configuration
and
we
don't
like
making
the
user
type
in
something
that
the
computer
or
failed
to
work
out
for
itself
and
the
DNS
has
this
wonderful
delegation
hierarchy
where
you
start
at
the
root
and
you
find
out
who
is
the
server
authoritative
for
a
given
domain?
So
that
was
the
logical
thing
to
do.
C
If
I
want
the
hostname
of
my
laptop
to
be
Stewart's
laptop
mobile,
Apple,
comm
I
shouldn't
need
to
tell
the
computer
what
server
is
responsible
for
that?
The
computer
should
work
it
out
using
the
DNS
hierarchy.
So
that's
what
we
did.
Basically,
the
algorithm
is
very
simple:
I
look
for
the
SOA
record
for
Stuart's
laptop
mobile
Don
Apple
comm
chances
are
that
SOA
record
doesn't
exist
because
that's
not
his
own
cut,
so
I
will
get
a
negative
answer,
either
an
X
domain
or
a
nowhere
and
no
answer
negative
response.
C
You
can
then
iteratively
chop
one
label
at
a
time
until
you
do
get
a
positive
answer
and
then
you
have
discovered
the
closest
enclosing
zone
as
an
optimization
for
negative
answers.
Servers
are
supposed
to
also
include
the
SOA
of
the
authoritative
server
that
says
this
name
doesn't
exist
and
that
lets
you
shortcut
the
iterative
steps
to
go
straight
to
the
SOA
that
you're
looking
for.
C
So
that
was
one
page
in
the
document
and
as
a
response
to
the
last
call
comments
that
got
significantly
changed
in
a
way
that
I
fear
doesn't
make
sense
anymore
and
removes
the
shortcut
to
avoid
the
iteration.
So
it
generates
a
lot
more
packets
and
it
actually
has
cases
that
don't
work.
So,
unfortunately,
we're
going
to
have
to
fix
that.
Hopefully,
we'll
have
time
at
the
end
of
this
meeting
to
do
that.
B
C
What
useful
session
signaling
is
now
called
stateful
operations.
That
document
is
pretty
stable
right
now
we
had
one
recent
change
about
whether
all
requests
require
responses
or
not
the
consensus
is
they
don't
require
responses,
but
some
of
the
places
in
the
document
were
not
updated
to
reflect
that.
So
this
week,
I
initially
did
a
thorough
review.
We
re
reading
that
document
from
start
to
end
and
found
a
few
of
those
inconsistencies.
We
will
fix
those
and
DNS
op
chairs
a
promise
to
do
a
last
call
in
December.
C
C
We
did,
however,
do
a
lot
of
work
on
the
multicast
DNS
relay.
This
was
an
inspiration
of
Ted's
Ted.
Has
all
the
background
in
DHCP
and
DHCP
uses
boopie
relay
agents
to
avoid
having
a
DHCP
server
on
every
physical
link,
and
that
concept
applies
quite
naturally
here
as
well,
so
Ted
and
I
have
been
working
on
defining
a
simple
lightweight
protocol
analogous
to
a
weekly
relay
which
we're
calling
a
multicast
DNS
relay.
We
submitted
Raph
0
0
for
last
night.
C
We
planned
this
year
on
having
a
table
at
the
hackathon
which
we
did
and
we
announced
it.
Many
of
the
regular
contributors
to
DNS
SD
are
not
here
in
Singapore
for
various
reasons.
So
in
the
end
it
ended
up
being
Ted
and
me
having
a
table
for
ourselves
and
two
days
of
focused
face-to-face
time.
We
did
some
coding
and,
as
a
result
of
that,
we
realized
things
that
should
be
changed
in
the
relay
document
and
I
submitted
that
Monday
morning,
which
I
know
is
too
late
for
anybody
here
to
regret
it.
E
E
All
right,
so
why
am
I
talking
about
home
that
here?
This
is
the
SSD
working
group.
The
reason
is
because
one
of
the
main
things
that
you
need
in
order
to
make
a
home
that
work
nicely
is
service
discovery
and
dn.
Ssd
is
how
we're
doing
service
discovery
on
home
nets,
so
HMDA
is
kind
of
the
the
simplest.
Maybe
simple,
isn't
the
right
word?
E
It's
the
it's,
the
least
managed
to
use
case
for
dns
SD,
and
so
it's
a
pretty
interesting
use
case
to
be
looking
at
if
you're
interested
in
DNS
SD
the
we
call
home
that
home
net,
because
because
that
was
kind
of
the
the
the
motivating
use
case
for
forming
the
working
group,
but
what
we're
producing
is
actually
probably
applicable
to
more
than
just
home
networks
by
the
way
Stewart
I,
don't
Stewart
asked
me
to
come
up
and
give
this
talk.
I
don't
actually
know
what
his
goals
were
so
I.
E
E
Let's
see
so
the
main
difference
is
the
main
things
that
make
this
interesting
are
we're
doing
DNS
SD
without
any
professional
management.
So
there's
no
there's
no
there's
no
IT
staff
managing
the
network.
It's
just
got
to
work.
Another
thing
that's
interesting
is
we
have
a
name
hierarchy,
but
we
don't
actually
have
a
global
domain
name,
so
that
creates
an
interesting
set
of
problems
that
are
worth
working
on.
I
think
DNS
is
dihybrid,
currently
depends
on
there
being
a
mapping
between
the
physical
hierarchy
of
the
network
and
the
network
topology.
E
And
stuff
like
that,
and
we
don't
have
that
we
don't
have
any
way
to
establish
names
like
that
on
a
home
net,
so
that
creates
some
interesting
problems.
Then,
of
course,
trust
establishment
on
the
home.
That
is
a
problem,
so
the
other.
The
problem
that
motivated
DNS
is
do
you
relay
is
that
we
want
to
be
able
to
support
routers.
That
may
not
be
quite
as
high
functioning
as
so
DNS
SD
is
running
essentially
on
home
net
routers.
E
B
E
E
As
a
Stewart
just
said,
Stewart's
certain
I
came
up
with
the
the
Service
registration
protocol,
which
uses
trust
on
first
use
name
claiming
so
you
publish
a
name
with
a
signature
on
it
and
you
sign
the
update
using
that
signature
and
then,
if
somebody
else
tries
to
claim
the
name
they
can't
because
they
don't
have
the
key
that
you
use
to
establish
the
signatures.
That's
a
nice
nice
way
to
do
stateful
management
of
service
publication.
E
Let's
see,
we
have
to
automate
the
management
configuration
of
discovery
proxies
and
relays,
which
is
actually
a
lot
of
text
and
the
hybrid
proxy
document
look
at
the
document.
The
document
is
well
when
I,
when
I
did
the
original
version
of
the
document,
it
was
actually
about
25
pages,
and
it
wasn't
done
yet
and
about
10
of
those
pages
were
om.
E
The
document
is
now
more
like
15
pages
of
meaningful
text,
I
cut
down
the
om
quite
a
bit,
because
I
thought
it
was
a
little
bit
impenetrable
and
a
little
bit
too
detailed.
But
so
the
point
being,
that's
that's
a
big
part
of
setting
up
the
discovery.
Proxy
hybrid
proxy
thing
is
just
getting
it
to
work,
getting
it
configured
to
work
and
then
the
other
thing
that
we're
doing
at
home
net,
which
is
not
really
a
DNS
sd
thing-
is
trying
to
automate
trust.
E
E
B
E
E
I'm
not
sure
quite
how
to
I
didn't
put
a
link
here,
but
send
me
email,
and
hopefully
people
know
how
to
find
me
on
email
and
I'll.
Send
you
a
link
to
the
github
repository.
You
can
take
a
look
at
it,
so
he's
actually
repeat
of
a
lot
of
stuff
who's
on
the
previous
slide,
one
thing
I'm
not
going
to
read
everything.
E
That's
on
this
slide,
because
you're
already
probably
bored
but
I,
did
a
couple
of
presentations
in
the
DNS,
I'm,
sorry
and
I'm
networking
groups
that
are
relevant
to
this
topic
and
that
you
may
find
interesting
if
you're
interested
in
this
product
project
based
on
what
I've
said
so
far.
So
if
you
are
interested,
please
go
look
at
those
presentations.
Even
if
you
just
look
at
the
slides
that'd
be
great.
Those
totals.
F
F
F
B
F
C
E
You
might
want
to
mention
we
we
hate,
you
and
I
have
actually
had
discussions
about
how
to
how
to
how
to
discover
IOT
devices
on
hum
net,
which
is
something
that's
that's
you
know,
I
think
highly
relevant
and
not
particularly
known
to
I
mean
people
aren't
necessarily
using
mdns
right
now.
For
that,
so
don't
be
something
to
talk
about.
F
Yeah
I
didn't
I
I,
think
you
know
going
to
whoever
is
potentially
building
home
net
equipment
or
even
equipment.
That
does
something
similar
like.
Oh,
maybe
you
know
who
would
say
hey
before
we
saw
it's
all
net.
We
didn't
even
think
about
having
you
know
to
bother
about
services
every
right
so
that
table
people
said
right,
I
mean
they're.
Obviously
people
a
you
know,
building
theorized
solution
that
don't
employ
all
the
other
HomeNet
pieces,
but
hopefully
the
service
discovery.
C
Yeah
I
I'm
actually
cautiously
optimistic
about
the
use
of
DNS
service
discovery
in
current
products,
but
partly
this
is
based
on
just
personal
anecdotal
data.
I
bought
a
new
house
a
couple
of
years
ago
and
as
part
of
the
process
of
buying
a
new
house,
you
end
up
buying
a
bunch
of
new
stuff
and
I
was
actually
shocked
about
how
much
stuff
I
bought
had
multicast
DNS
service
discovery
in
it.
I
bought
a
surround,
sound
amplifier
for
the
speakers
in
the
ceiling
in
the
living
room
and
it
has
a
web
UI.
C
E
Yeah
I
mean
I,
think
I
think
you
know
the
the
point
I
was
making
about
home,
that
relating
to
be
an
SSD
and
it
being
an
interesting
place.
Is
that
and
I
guess?
I
didn't
actually
explain
this
in
as
much
detail
as
I
as
I
perhaps
should
have
the
fact
that
we
need
to
be
able
to
support
stupid,
routers
and
smart
routers
on
the
home.
That
is
actually
what
motivated
me
to
have
the
conversation
with
Stuart
that
produced
the
hybrid
proxy
stuff.
E
So
so,
essentially,
the
the
sense
in
which
I
think
home
that
is
interesting
is
not
so
much
that
it's
necessarily
what
everybody's
trying
to
do,
but
it's
it's
sort
of
a
crucible
right.
It's
it's!
It's
it's
a
place
where,
where
the
absolute
minimum
support
for
getting
things
working
is
present,
and
so
can
we
get
DN
SSD
working
reliably
in
that
environment
I
think
that's
a
really.
F
G
Michael
Abramson
so
I
think
when
you,
what
I
was
going
to
say
was
a
lot
what
you
just
said
it
when
it
comes
to
crucible
so
home
that
shares
a
lot
of
mechanisms
or
the
need
for
searching
mechanisms
with
like
IOT
you,
you
were
talking
about
the
trust
establishment.
That's
like
shared
widdy's,
enrollment
of
new
IT
devices.
G
Small
medium
enterprise
probably
want
to
use
very
similar
technology
as
home
net
and
DNS
SDEs
should
be
present
in
the
solution
space.
For
all
these.
What
we're
talking
about,
we
shouldn't
have
the
whole
yeah
I
I
mean
it
like
a
matrix
of
things,
you've
put
together
to
create
a
working
solution,
and
what
home
that
has
is
that
the
there
is
no
professional
management,
but
you
still
need
some
kind
of
minimum
interactive
and
of
saying
yes,
I
trust
this
device
or
yes,
I
trust
that
person's
devices
or
whatever
they
come
to
the
process.
G
B
C
I
think
that
one
of
the
areas
of
overlap
here
is
one
of
the
key
parts
of
home
that,
as
I
understand,
it
is
home
networks
that
are
more
than
one
link
so
routed
networks
rather
than
bridged
and
on
bridge
networks.
Link-Local
multicast
is
fine,
but
when
you
move
to
multiple
links,
you
need
some
way
to
glue
those
together
and
that's
what
this
working
group
is
focused
on,
not
just
the
home
networks
but
for
enterprise.
Large
Wi-Fi
installations.
C
Mesh
networks
are
the
technologies,
but
the
overlap
is
what's
common
in
both
of
those
cases
both
home
net
and
here
is
you
can't
assume
a
single
link
and
link-local
multicast
anymore,
so
there's
definitely
synergy
there.
While
I'm
aware
the
microphone
a
comment,
I
was
going
to
make
about
the
relay
to
build
on
what
you
said:
I
don't
see
it
just
as
for
less
capable
home
gateways
that
can't
run
a
full
discovery
proxy.
C
The
other
benefit
here
is
often
your
home
gateways.
Don't
get
updated
very
regularly
and
you
might
have
three
or
four
different
Wi-Fi
access
points,
maybe
from
different
vendors
and
if
all
they
have
to
do
is
implement
the
relay
once
and
it's
a
pretty
simple
thing
like
a
bootp
relay
and
the
SPECT
really
doesn't
change.
C
There
aren't
bug
fixes
there
aren't
new
enhancements,
then
that
bit
of
gear
can
be
five
years
old,
but
you
can
be
running
the
latest
discovery
proxy
on
your
controller
for
your
main
gateway
or
whatever
the
device
is,
and
that
can
get
regular
software
updates
that
add
new
features,
new
capabilities,
new
user
interface
configuration
options
so
that
you
can
filter
what
services
are
visible
in
what
places
and
and
all
of
that
innovation
can
happen
in
one
place
without
having
to
do
a
forklift
upgrade
of
every
router
on
the
network.
Every
time
you
add
a
new
feature.
E
F
Okay,
so
yeah,
so
this
is
basically
something
that
we
are
doing
at
the
end
of
our
a
and
I
work
in
the
nml
working
group,
which
is,
you
know,
coming
towards
our
FC
side
and
doing
all
these.
These
details
that
are
very
specific
to
the
NSS
T,
because
we
kind
of
felt
that
there
was
more
details
than
we
could
do
in
the
basic
graphic
themselves.
It's
like.
F
Okay,
so
quick
overview
of
what
the
NMR
working
group
does
with
respect
to
a
service
discovery.
So
what
actually
actually
builds
through
something
called
a
and
iacp
is
an
automatically
built
hop-by-hop
encrypted
ERF,
considered
in
the
burette
light,
with
encryption
to
manage
and
control
networks
right
so
management
and
control
traffic
for
network
services
agents.
All
that
stuff
is
meant
to
go
through
whether
it's
a
fully
autonomic
network.
F
You
know
protocols
using
the
a
and
I
expect
to
have,
and
that's
only
ipv6,
unicast
routing
and
forwarding,
so
there
is
no
definition
of
dns
or
expectation
that
dns
must
be
available
and
no
IP
multicast,
so
which
begs
the
question:
how
do
you
do
service
discovery
then,
because,
obviously,
and
something
that
is
meant
to
be
self
configuring
and
self-organizing
like
an
autonomic
network?
You
need
that,
and
so
this
is
a
part
that
a
grasp
does,
which
is
a
new
protocol
defined
in
the
animal
working
group,
which
does
a
bunch
of
things
but
for
discussion
here.
F
It
provides
service,
discovery,
upload,
yeah
kind
of
half
an
hour
ago,
or
so
there
was
this
one.
There
was
some
better
words
music.
So
what
we
have
in
grasp
is
the
ability
to
do
announcement
and
request
messages,
not
only
for
service
announcement
like
en
SSD,
but
for
any
type
of
you
know,
group
communication
that
requires
that
type
of
flooding
in
and
they
are
hot
by
heart,
reliably
flooded
across
that
secure,
automatically
build
infrastructure.
F
So
the
header
of
these
messages
has
an
element
called
the
objective
name
that
specifically
not
service
name
but
more
broader
term
encompassing
services.
As
you
know,
a
possible
subset
hop
count,
sequence
number
for
the
loop
free
flooding,
and
so
you
can
consider
the
objective
name
really
as
the
address
for
endpoints
that
are
trying
to
do
group
communication
via
grasp.
The
payload
itself
is
undefined
right.
G
F
A
link-local
multicast
for
this
discussion
is
not
used
and
not
required
and
not
assumed
to
be
there
in
in
this
particular.
You
know
ni
ACP
in
grasp
in
general,
we're
also
supporting
the
ability
to
do
the
flooding
through
the
use
of
link-local
multicast,
but
in
the
end,
it's
always
a
layer,
3
network,
so
it
needs
to
be
flooded
across
multiple
hops,
so
link-local
multicast
itself
wouldn't
be
sufficient.
F
G
F
D
Carpenter,
author,
one
of
the
authors
of
the
gross
protocol.
Yes
and
no
I
mean
if,
if
you
happen
to
be
running
on
a
point-to-point
link
between
two
nodes,
which
is
the
way
the
autonomic
control
plan
works,
then
strictly
speaking,
there
is
no
multi
casting,
but
if
you
send
the
link
local
multicast
address,
the
packet
will
be
delivered
anyway.
So
so
the
answer
is
yes.
The
grasp
demon
can
believe
that
has
a
link-local
multicast,
although
in
practice
its
emulated
over
us
over
a
point-to-point
link,
yeah.
A
C
Think
it
would
be
helpful
right
now
you're
diving
into
a
lot
of
details,
which
is
good.
We
should
continue
this,
but
it
would
help
me
understand
how
these
fit
into
the
big
picture.
If
you
could
give
some
background
about
what
kind
of
network
this
is
and
what
kind
of
devices
are
these
bits
of
equipment
connected
by
serial
ports?
Is
it
Wi-Fi?
Is
it
Ethernet?
Is
it
802.
C
F
So,
basically
to
all
the
questions
that
you
are
asking,
the
answer
is
yes,
except
for
home
net,
where
we
wouldn't
want
to
introduce
a
lot
of
the
complexity
of
the
solution
overall
hairs,
because
a
lot
of
that
complexity
is
meant
to
support
the
well
management
of
the
network.
So
it's
gonna,
be
an
enterprise
network,
a
service
provider
network
with
all
the
possible
underlying
connectivity
options
that
you
were
mentioning,
except
that
we
right
now.
B
F
C
F
It's
been
a
fate,
you
know
second
invent
virtual
management
network
and
that,
of
course,
as
you
can
easily
imagine,
is
a
layer
of
complexity.
That
is
really
helpful
when
you
start
in
you
know,
multiple
application
developers
writing
all
type
of
crazy
CDN
software,
and
it's
not
that
necessary
if
you're
looking
at
the
ultimate
goal
of
HomeNet,
which
really
tries
to
be
as
simple
as
possible,
either.
C
F
So
I
mean
when
we've
been
looking
at
the
you
know,
urgent
or
the
you
know,
value
of
this
technology
in
different
use
cases-
and
you
know
the
work
on
where
you
know,
pre
standard
versions
of
this
have
been
developed
and
implemented.
Then
the
data
center
was
kind
of
at
the
tail
end
of
that,
but
rather
something
that
has
wide
area
network
links
where
it's
starting
to
ship
equipment
that
potentially
is
unconfigured
to
places
where
you
don't
have
any
intelligence
in
the
room
and
trying
to
have
that
stuff
work
reliable.
F
F
Mean
platforms?
Yes,
so
there
is
an
autonomic
networking
feature
set.
Insist
you
can
look
that
up.
That
is
pretty
much
across
all
the
enterprise
product
lines,
so
you
can
have
that
in
campus
equipment
in
white
area,
enterprise
equipment.
So
that's
basically
the
implementation
I'm
familiar
with
okay.
C
So
this
is
in
in
Cisco
products
right
now,
so
you
can
just
like
plug
a
bunch
together
and
power
them
on
and
they
self
configure,
and
you
don't
need
some
Cisco
IT
guy
to
tell
you
how
to
set
it
up.
If
that
the
idea,
that's
the
autonomous
part,
is
look
plug
it
together
and
you
have
a
CDN
automatically,
not.
D
F
F
Would
draft
ITF
and
in
my
autonomic
control
plane,
the
answer
is
in
draft
and
in
idea
venema
autonomic
control
plane.
It's
it's
longer.
It's
kind
of
beyond
the
kind
of
only
got
limited
time
here,
so
really
high
level.
For
this
you
know
autonomic
infrastructure
that
provides
ipv6
routed
connectivity
to
operate.
We
have
two
services
that
need
to
be.
F
You
know,
announced
by
the
server
instances
and
need
to
be
discovered
by
all
the
you
know:
network
equipment,
all
the
routers
and
switches
in
the
network,
and
one
is
for
bootstrap,
because
every
device
in
the
network
is
fine
to
provide
proxy
support
for
new
devices
coming
along
for
the
devices
that
don't
have
credentials
and
obviously
because
without
credentials
they
can't
get
whole
IT
connectivity.
So
you
need
proxies
and
that's
basically
discovered
through
one
service
and
then
the
second
one
for
certificate
renewal.
F
You
also
need
to
discover
a
certificate
renewal,
server,
we're
using
EST,
RFC,
70/30
and
announcing
that-
and
there
may
be
more
service
for
that
and
then
for
the
traditional
Sdn
or
you
know,
traditional
network
management
model
well,
you've
got
all
type
of
servers
in
the
NOx
data
centers.
However,
you
want
to
call
them,
and
typically
you
know
today,
you're
creating
on
every
device,
the
magic
initial
network,
infrastructure
config,
where
you
have
the
bloody
IP
addresses
of
ten
of
these
different
servers,
and
most
often
you
can't
even
nicely
figure
out
failover.
F
If
one
IP
address
goes
down
so
you're,
then
you
know
going
to
another
server
in
the
data
center
and
changing
their
to
use
exactly
the
same.
Ip
I
mean
if
you've
only
dealt
with
service
discovery
in
the
user
space.
You
don't
even
want
to
know
how
bad
it
is
often
in
operations
of
networks
in
their
management
right,
so
syslog
time,
net
front,
DHCP,
DNS
service.
How
do
you
configure
them
on
routers
radio
server
diameter
tactics
for
authentication
of
access
to
the
routers
themselves?
Yadda
yadda
right,
so
all
that
stuff?
F
So,
okay,
so
hopefully
we
cleared
up
a
little
bit
the
background,
the
use
cases,
but
why
they
strapped
again
right.
So
we
do
not
want
to
reinvent
in
for
a
ni
a
CP
grasp
any
aspect
of
service
discovery
that
we've
already
know,
and
hopefully
love
from
DNS
SP,
and
there
was
to
page
one
right.
Every
grass
objective
must
come
with
its
own
name
and
how
to
encode
any
attribute.
F
Wasn't
really
working
well
because
you
know
every
time
I
said
well
in
actual
deployment.
I
think
we
need
this
other
parameter.
Let's
call
it
the
priority
of
the
server.
Then
there
was
the
long
discussion.
Why
do
we
really
need
this?
And
something
is
you
know
there
there's
this
thing
that
we
have
in
the
ITF
since
a
decade
or
so
you
know
proving
pretty
useful.
F
So
then,
of
course,
there
are
a
lot
of
things
in
DNS,
primarily
that
DNS
is
the
inherited
or
sometimes
created
by
itself,
like
you
know,
underscore
UDP
TCP,
so
we
don't
want
to
do
the
crud,
so
I
didn't
try
to
do
just
encapsulation
of
existing.
You
know
DNS
message
formats
into
grasp,
but
try
to
basically
map
it
in
the
most
efficient
way,
so
that
in
a
grass
solution
alone
we
have
as
little
unnecessary
overhead
as
possible.
F
So
what
do
we
do
and
I
just
wanted
to
quickly
give
some
very
high-level
overview,
so
there
is
more
detail,
obviously
in
the
draft.
The
draft,
of
course,
is
by
far
not
complete
it's
a
zero
zero
right.
So,
first
of
all,
we
want
to
be
able
to
simply
reuse
and
grasp
service
names
from
that
have
been
assigned
by
6335.
F
We
want
to
have
the
same
ability
for
service
criteria.
Priority
weight
service
instance.
Names
is
an
interesting
thing.
The
service
instance
names
in
my
interpretation,
please
correct
me
if
that's
wrong
is
primarily
for
manual
browsing
so
that
a
human
can
make
nice
decisions.
Otherwise,
you
start
rather
in
automatic
selection,
rely
on
the
key
value
pairs,
also
to
compare
parameters
of
service
to
select
the
best
one
and
a.
C
Couple
of
quick
comments:
first
I,
want
to
say
very
clearly
that
I
agree
with
the
first
point
you
made
and
I'm
saying
that.
Well,
first,
point
verbally
not
on
the
slide.
There
is
absolutely
no
reason
to
be
encapsulating
the
DNS
packet
format
and
I'm
coming
up
to
the
microphone
to
say
this,
because
this
is
a
common
misunderstanding.
To
my
mind,
the
key
concepts-
and
maybe
we
chose
a
bad
name,
picking
a
good
name
for
something
is
always
very
important
than
maybe
we
didn't
in
this
case.
C
The
most
important
concepts
in
DNS
service
discovery
are
the
three
basic
operations
you
offer
a
service
on
the
network.
You
discover
a
list
of
available
services
of
the
type
that
meets
your
needs
and
then,
when
you've
picked
one
or
more
to
use,
you
may
need
additional
information
to
attach
actually
at
establish
a
connection
to
that
service.
C
A
TCP
connection
of
ice-cream,
a
message,
but
so
the
three
off
the
three
operations
are
offer
discover
and
use,
and
the
current
implementations
of
that
encode,
those
semantics
in
DNS
records
and
DNS
queries
or
multicast
DNS,
but
there
is
in
no
way
that
we
are
wedded
to
that.
Particular
packet
format
I
think
we
would
support
the
concepts
as
being
the
useful
concepts,
but
how
you
encode,
those
absolutely
should
be
done
appropriately
for
the
link
layer
of
the
environment.
You
have
so
hundred
percent
agreements
on
that
point.
Yet.
C
F
You
very
much
I
mean
that
was
kind
of
the
intention.
There
I
think
it
becomes
more
interesting
when
I'm
starting
to
kind
of
declare
certain
things
for
the
use
cases
within
grasp
enema
to
be
potential
crud
that
you
know
I'm
not
sure
how
I
want
them
at
all.
Right
now,
I've
defined
a
couple
of
things
as
optional,
and
so
basically
that
would
be
great
work
to
come
to
conclusions
on
right.
So,
for
example,
the
service
instance
names
right.
F
So
it's
a
great
thing
if
I'm
in
front
of
a
web
GUI
and
can
select
as
a
human,
if
I
have
a
bunch
of
automated
ASAS
that
are
trying
to
select
the
service
instance
I
think
I'd
rather
have
a
more
explicit
algorithm.
That
goes
to
key
value
pairs
and
compares
parameters,
and
there
is
some
know-
and
you
know-
privatization
scheme
right.
So
that
would
be
an
example,
which
is
why,
for
here
now,
the
service
instance
names
are
actually
optional.
C
So
on
that
subject,
I
think
I
heartily
agree
with
you.
I
think
having
service
instance
names
as
a
way
of
differentiating
things
on
the
network
should
not
be
optional,
because
you
need
a
way
to
identify
the
things
that
you're
talking
about.
When
you
want
to
make
a
connection
to
something
you
have
to
say
what
it
is.
You
want
to
make
a
connection
to
so
so
having
some
identifier
that
I
think
is
optional.
C
But
if
you
put
your
mind
back
ten
years
so
when
most
inkjet
printers
connected
over
USB,
it
was
common
for
people
to
run
printer
sharing
on
their
desktop
iMac
and
in
fact
it's
still
there
in
system
preferences,
you
can
see
the
printer
sharing
checkbox,
but
if
you
leave
your
iMac
powered
on
24
hours
a
day
just
so
you
might
want
to
print
something,
then
that's
not
very
good
for
the
environment
or
electricity
bill.
So
what
will
actually
happen?
C
Is
your
iMac
will
go
to
sleep
but
still
be
available
on
the
network
so
that
when
you
pull
out
your
iPhone
and
you
print
the
boarding
pass,
the
thing
wakes
up
print?
The
document
goes
back
to
sleep
again
and
it
does
that
by
transferring
its
service
state
to
a
proxy
on
the
network
that
can
answer
on
its
behalf
and
it
does
and
like
many
protocols
as
a
recursive
self
dependency.
Here.
If
you
want
to
find
something
on
the
network,
we
have
a
search
discovery
protocol
and
it
uses
multicast
DNS.
C
If
you
look
in
system
preference,
if
you
look
in
system
information,
you
will
see
it
lists
the
top
three
sleep
rocks
as
it's
found
on
the
network.
Anything
that's
powered
on
all
the
time.
Your
home
access
point,
an
Apple
TV,
takes
three
watts
and
is
typically
not
a
mobile
device.
So
out
of
all
the
possible
proxies
on
the
network,
it
picks
its
first
three
choices
and
shows
those,
and
you
can
see
the
metrics
it's
used
and.
F
And
it
also
just
another
point
that
that
comes
to
mind
Ellison,
who
is
this
is
basically
the
the
the
question
about.
When
do
you
need
locators
versus
identifiers
for
instances
right
and
so
right
now,
I
think
I
came,
for
example,
from
all
the
protocols
where
the
locators
are
sufficient
to
distinguish
identities
right.
C
C
F
C
F
And
then
the
last
one,
of
course,
the
host
name
right,
just
I,
think
I'm
not
quite
sure
it
is
it
kind
of
being
an
outcome
of
DNS.
The
way
it
works
right
that
you
are
kind
of
not
directly
getting
over
to
the
a
records
but
first
to
the
host
name
record
and
then
da
records
right,
so
that
India
kind
of
in
grass
we
don't
even
have
host
names
normally
right.
So
that's
something
that
would
also
be
I.
C
B
C
B
F
In
in
our
case,
you
know,
if
we
figure
out
that
we
want
to
have
that
indirection
I
mean
what
we
have
as
locators.
Right
now
cannot
only
cover
addresses,
but
it
could
also
cover
host
names
right,
so
I
just
haven't
found
a
good
enema
scope
example
use
case
of
that,
but
once
I
have
one
I
would
kind
of
introduce
that
option
in
the
machine
to
machine
use.
C
Some
gobbledygook
gooood
type
identifier,
like
my
the
new
garden
irrigation
controller
I,
got
the
host
name.
Ian,
has
his
android
and
then
the
12
hexadecimal
characters
of
this
MAC
address
our
normal
human
user.
Never
even
sees
that
they
just
on
their
on
their
app.
They
just
tap
it
and
it
opens,
and
the
home
is
so
that
that
is
an
approach
can't
take
as
they
put
in
eventually
a
W
place
over
there.
Yeah.
F
But
I
mean
given
how
we
haven't
really
explored
the
whole
space,
but
are
always
scared
of
these.
You
know
yesterday
type
1
devices,
you
know
less
kilobytes
right
and
so
one
of
the
ideas
was
of
course,
also
to
keep
decoding
and
encoding
of
the
informations
contact
as
we
can
and
eliminate
all
the
stuff
we
don't
need.
So
this
is
basically,
if
you
haven't
seen
CD
DL
the
C
for
presentation
thing
that
basically
how
it's
specified
and
I
just
summarized
a
little
bit.
So
basically
we
have
a
naming
scheme,
objective
names.
F
B
F
Some
things
I'm
hopeful
name.
If
you
want
to
do
that
and
then
the
service
element,
all
the
data
is
basically
in
in
this
structure.
So
I
know
if
you
want
an
extension
message
type
now
you
gave
me
some
other
name.
So
I
came
up
with
describe
describe
request,
enumerate
a
numerate
request.
It
was
a
little
bit
written
from
your
RFC,
but
I
think
we're
just
using
somewhat
different
words
for
what
you
would
like
to
see
as
the
expected
API
name.
F
So
it
would
be
great
to
talk
about
service
name
service
instance
name
domain
kind
of
now,
with
the
way
grasp
is
mostly
empty
because
it's
mostly
like
top
local,
only
that
it's
the
global
network
of
50
thousand
routers,
so
kind
of
global.
If
you
like,
but
really
not
very
structured
priority,
wait
Katy
tears.
The
range
is
a
thing
so
because
in
brass
were
kind
of
doing
flooding
hop-by-hop
with
time
to
live,
decrement
ation,
we
can
know
the
distance
in
the
service
of
a
service
instance.
F
So
one
would
be
the
default
like
where
the
announcement
is
in
the
a
NIAC
key
or
other
VRS
in
the
network
infrastructure,
and
then
you
know
I'm
not
going
into
exactly
how
we're
mapping
these
for
service
types
onto
the
different
grasp
message:
types
that
we
have
the
flood
of
an
announcement,
the
flood
of
a
request,
the
unicast
responses,
or
so
that's
in
the
draft
there's
also
from
Monday
in
the
slide
in
the
enema
working
group.
More
detail
on
that.
F
So
what's
the
target
system
overall,
that
I'm
imagining
right
so
overall
kind
of
for
these
specifications
of
anything
we're
doing
an
enema
in
the
future,
simpler,
more
consistent
specification
of
a
and
IACP
service
and
up
one
line
right.
That
says,
you
know,
the
the
service
documented
here
is
the
following
name
in
the
ini
registry.
Right
parameters
are
according
to
dns,
SD
done
right,
DNS
SD
graph
right
because,
as
you
saw,
we
have
some
additional
parameters.
F
Common
service
name
announced
discover
API
and
SDKs,
which
might
be
a
superset
so
that
you
know,
depending
on
context,
it
would
automatically
use
DNS
SD
unicast
mdns
of
wrath'.
That
would,
for
example,
be
great
for
the
brewski
stuff,
where
we
actually
want
to
specifically
also
highlight
how
to
do
non
a
and
I
solutions
for
actual
mdns
would
be
use,
or
you
know
an
SSD
will
have
to
check.
F
We
haven't
invested
that
much
time
there
gateway
functions
and
the
knock
router
right,
so
I
mean
avahi
and
others
are
easily
able
to
quickly
put
all
your,
not
equipment
in
a
state
that
it
announces
itself
by
M
DNS
and
then
the
router
does
the
gateway
between
em
DNS
and
grasp.
That's
also
what
you
know
the
Cisco
product
does.
Only
that
it
does.
You
know
multi-hop
p.m.
DNS
in
the
network
and
that
kind
of
didn't
really
work.
So
I'm
very
happy
that
you
know
we
came
with
grasp
and
the
flooding
mechanism.
F
We
have
to
a
better
solution
there.
So
what
is
outside
the
enema
scope?
And
that's
now
where
the
discussion
with
Terry
was
very
useful,
so
one
set
of
limitation-
and
the
current
definition
I
think
makes
a
lot
of
sense
is
really
scoping
ourselves
to
the
enemy
use
case.
In
terms
of
everything
we
need
for
operational
things
because
Europe,
you
can
always
bring
up
thousands
of
more
things
that
are
great,
but
that
would
apply
to
you
know:
user
services
use
cases,
and
so
then
the
question
is:
how
do
we
capture
that?
F
And
that's
certainly
something
we
wouldn't
want
to
do
it
with
you
know
a
draft
in
animal
I'd
be
very
happy.
If
somebody
wants
to
pick
this
up
and
say
hey
this
type
of
you
know,
flooding
grass
might
be
useful
to
also
you
know
as
an
alternative
in
some
scenarios,
for
let's
say
the
hybrid
proxy
thing
right
so
in
comparison,
the
hybrid
proxy
is
better.
If
you
have
a
sparse
receiver
population,
because
you
don't
need
to
blood
everywhere,
but
the
flooding
of
course
is
a
very
efficient
scheme.
C
Thanks
for
coming
and
doing
this
presentation,
and
thanks
David
for
thinking
of
setting
this
up
because
I
was
not
aware
of
the
details
of
this
work,
I'm
very
happy
that
you
decided
to
adopt
the
same
service
namespace
run
by
Ayane,
because,
if
nothing
else
that
that
provides
a
consistent
way
of
naming
services,
regardless
of
what
the
bits
on
the
wire
or
over-the-air
look
like
the
concepts
are
compatible
and
that's
really
important.
So
thank
you
for
doing
that.
Instead
of
inventing
yet
another
service
namespace
exactly
and
by
the
way
I
mean
so.
F
D
D
A
Our
lat
next
and
last
topic
for
today
is
going
to
be
on
DNS
as
the
privacy
we
had
documents
adopted
by
the
working
group
on
this
topic
and
Stewart
now
has
a
new
documents,
but
looking
less
into
the
proposed
solution
and
more
into
the
requirements.
So
this
is
meant
to
be
a
very
interactive
conversation
on
what
we're
trying
to
accomplish
as
a
working
group
in
the
domain
of
DNS
SD
privacy
rights
to
it.
Thank.
C
You
David,
so
we
have
some
drafts
by
christian,
we
tamar
and
daniel
kaiser,
neither
whom
are
able
to
be
here
physically
for
this
meeting
and
they
cover
some
interesting
areas.
Earlier
when
I
was
speaking
about,
the
last
call
results
on
the
discovery
hybrid.
I
had
a
couple
of
asterisks
saying
there
are
questions
about
a
privacy
and
information
leakage,
and
it's
a
sign
that
I
think
there's
a
lot
more
awareness
of
that
right
now,
10-15
years
ago
you
go
back
to
apple
talk
in
1987.
C
C
These
are
all
the
people
I
have
in
my
contacts
list
and
when
you're
trying
to
initiate
a
file
transfer,
we
don't
be
broadcasting.
This
is
my
identity.
Does
anybody
out
there
have
me
in
the
contact
list,
because
that
way,
your
you
could,
if
you
gave
your
name
your
email
address,
your
phone
number
you'll
be
broadcasting
that
to
any
eavesdroppers
around
untrusting,
the
ones
that
aren't
supposed
to
receive
it
to
throw
it
away.
C
We
could
do
a
hash
of
your
email
address
and
a
one
way
hash
would
make
it
seemingly
harder
to
reverse-engineer
what
the
email
address
is.
But
if
the
email
addresses
are
something
at
iCloud
com,
it's
pretty
easy
to
do
a
dictionary
attack
against
common
names
and
figure
out
the
match.
So
even
a
hash
reveals
your
email
address.
The
other
issue
with
the
hash
is
that
it
doesn't
change,
even
if
it's
not
reversible.
If
it's
the
same
every
day,
you've
now
created
a
tracking
identifier.
C
We
may
not
need
to
know
who
you
are,
but
we
may
know
that
you
come
into
this
particular
cafe
for
a
cup
of
coffee
every
morning.
Things
like
this.
We
didn't
care
about
ten
years
ago,
but
we
definitely
do
now
so
airdrop
does
some
in
that
area.
It's
probably
not
perfect,
but
it's
certainly
one
of
the
goals
they
had
in
mind
in
the
design.
Same
thing
goes
for
the
home
kit,
home
automation,
accessories.
C
When
my
phone
is
looking
for
my
accessories,
it
can
control.
It
has
got
to
transmit
some
kind
of
query,
then
in
effect,
says
I'm
looking
for
Stewart's
home
accessories,
I'm
looking
for
the
thermostat
and
the
door
lock,
but
it
has
to
do
that
in
a
way
that,
when
I'm
here
in
Singapore,
my
phone
is
not
broadcasting.
My
name
and
my
address
in
my
account
details.
So
again
we
need
a
selective
service
discovery
that
does
not
leak.
C
Private
information,
Google
has
their
nest,
product
line
with
the
thermostats
and
the
smoke
detectors
and
the
cameras
and
the
whole
works
with
nest
partnership.
They
have
similar
concerns.
They
don't
want
devices
broadcasting
your
identity,
the
ZigBee
community
that
traditionally
has
done
home
automation
for
the
last
decade
or
more,
using
their
proprietary
protocols
over
the
802
11
802
dot,
15.4
radios.
They
are
now
moving
to
running
over
IP,
using
the
thread
mesh
network
pioneered
by
Google
and
others.
They
have
similar
privacy
concerns.
C
There
are
other
projects
I'm
aware
of
that's
confidential
and
there's
another
project
that
I'd
actually
forgotten
about
from
five
years
ago,
and
the
only
thing
that
reminded
me
about
it
is
I
got
one
of
those
little
brass
patent,
plaques
in
the
mail
at
my
office,
saying:
congratulations,
you
have
a
patent
and
I
went
wait
really.
I
I
totally
forgot
that
I'd
helped
that
team
with
that
and
they'd
added
my
name
on
the
pattern.
C
So
that
reminded
me
of
that
long-dead
project
and
I've
ample
legal
to
make
that
IPR
disclosure
may
or
may
not
be
relevant
to
this
work,
but
we
should
disclose
it
so
that
other
people
can
make
that
determination-
and
these
are
just
the
ones
I
know
about-
there's-
probably
many
more
so
I
realized
for
us
to
really
evaluate
all
these
different
things
that
are
going
on
and
figure
out.
If
any
of
them
have
in
fact
overlooked
something
important.
It
would
be
good
to
take
a
step
back
from
any
specific
solution
and
figure
out.
C
What
are
the
things
that
we
are
concerned
about
here
and
debate?
Are
they
important?
Are
they
not
important?
So
to
that
end,
I
wrote
a
quick
document
outlining
at
least
the
starting
point
of
the
things
so
things
to
consider,
and
the
purpose
of
this
discussion
is
to
talk
about
which
of
those
are
right,
which
are
wrong,
which
additional
things
who
maybe
should
add.
C
C
The
three
basic
primitives
to
my
mind,
are
you
have
seen
offering
a
service
on
the
network.
In
today's
terminology,
that
means
it
has
a
listening
socket.
It's
accepting
incoming
TCP
connections
or
income
UDP
packets
and
it's
running
some
kind
of
application
protocol
and
to
communicate
with
it.
You
have
to
know
the
application
protocol
to
send
it
meaningful
messages
that
it
will
understand
for
a
web
server
that
you
might
send
HTTP
GET
for
a
mail
server.
If
you
send
it
an
HTTP
GET,
it's
not
going
to
do
anything
useful
so
that
whole.
H
C
Of
what
do
I
offer?
What's
my
address,
what
name
or
other
distinguishing
information
describes
this?
All
of
that
is
what
I'm
calling
offering
the
service
you
may
have
something
like
the
turbo
room
printer
here,
which
is
offering
the
public
service.
It
is
there
so
that
we
can
print
documents
that
we
need
to
print,
so
it
does
make
sense
for
that
to
be
secret.
There
are
other
things
that
may
be
secret.
C
If
I
have
an
implanted
blood
sugar
monitor
or
an
insulin
pump,
then
it
is
offering
a
service
that
my
iPhone
health
app
can
communicate
with
to
check
my
blood
sugar
level,
but
it
doesn't
mean
I
want
to
be
walking
around
broadcasting
the
fact
that
I
haven't
embedded
blood
sugar
monitor
to
everybody
within
range.
So
that's
an
example
of
a
service
that
you
want
to
offer,
but
only
offer
to
authorized
receivers.
C
Discovering
is
the
client-side
operation,
which
is
here
at
the
ITF.
You
tap
the
Efrain
button
on
your
iPhone.
It
will
show
you
the
terminal
room.
Printer
is
available
right
now
we
are
only
have
one,
but
if
there
were
two
or
five
or
10,
you
would
see
the
list
to
choose
from.
So
that
is
the
step
of
discovering
services
and
again
the
entity
doing
the
discovering
might
want
to
keep
that
confidential.
C
If
my
iPhone
is
looking
for
blood
sugar
monitors,
then
whether
or
not
I
have
one
or
whether
I
have
it
with
me,
I
may
not
want
the
iPhone
broadcasting
to
everybody
within
range:
hey,
I'm,
looking
for
blood
sugar
monitors
because
I
have
a
diabetes
app
on
this
phone
and
then
the
final
step
is
having
discovered
a
list
of
candidate
services.
In
many
cases,
you're
going
to
pick
one
to
use
it
and
that
use
operation
might
also
want
to
be
protected
and
confidential
many
times.
C
I
may
skip
the
discover
step
so
to
use
the
example
at
the
home
care
accessories.
When
I'm
setting
up
a
new
accessory
I
may
want
to
do
a
discovery
for
all
home
automation,
accessories,
I
can
communicate
with
once
I've
had
appropriate,
aesthetic
accessories
with
my
phone.
My
phone
may
be
just
looking
for
the
door
lock
and
it
is
saying
when
I
come
within
range
of
the
door,
lock
unlock
it.
So
now
it's
not
browsing
for
all
door
locks.
It's
looking
specifically
for
my
door
lock,
because
that's
the
one
it
has
the
credentials
to
open.
C
So
again
we
don't
take
constantly
broadcasting
I'm.
Looking
for
Stuart's
door
locks,
its
door
locks
door
locks.
We
want
a
way
that
it
can
indicate
what
it's
looking
for
in
a
way
that
the
door
lock
itself
will
recognize,
but
that
everybody
else
is
undecipherable
encrypted
nonsense
and
nonsense.
The
changes,
because
it's
not
it
can't
be
a
constant
ID
that
becomes
a
tracking
identifier.
So
those
are
the
three
primitive
operations
offer
discover
and
use
when
we're
talking
about
who
we
trust
and
whose
trusted
and
whose
untrusted
there
is
a
question
of
granularity.
C
Are
we
talking
about
doing
this
on
a
per
device
level
like
once
I
authorized?
My
iphone
all
apps
on
the
iPhone
are
equally
trusted
on
a
multi-user
device
like
a
laptop
that
might
have
multiple
user
accounts?
Are
we
doing
this
trust
at
a
per
device
level
or
a
per
cuman
user
level
I'm
not
taking
any
strong
position
on
which
of
those
is
right
or
wrong?
C
So
once
we've
talked
about
the
operations
and
the
granularity,
the
question
is
one
other
threats
that
we're
worried
about
what
what
properties
do
we
want
and
here's
a
list
of
seven
that
I
thought
of,
and
the
point
of
this
is
to
solicit
other
thoughts
on
this.
We
start
with
the
obvious
ones.
We
want
to
know
that
the
data
is
real
and
hasn't
been
modified.
C
C
We
shouldn't
forget:
one
is
things
like
the
sleep
proxy
stuff.
I
was
talking
about
earlier,
where,
when
your
device
goes
to
sleep,
it
hands
its
state
to
some
other
device
on
the
network
that
can
answer
on
its
behalf,
while
it's
asleep,
if
we
require
crypto
operations
done
for
every
operation
requiring
secret
key
material,
we
may
not
want
to
hand
our
secret
key
material
to
an
untrusted
proxy
on
the
network,
so
figuring
out
how
the
privacy
and
the
power
management's
fit
together
is
a
challenge.
C
C
With
things
like
the
Mirai
botnet
attack,
we
have
to
assume
that
we
may
be
surrounded
by
malicious
attackers
at
all
times
and
even
a
30-second
vulnerability,
probably
not
acceptable
if
you
get
a
brand-new
printer
out
of
the
box
and
set
it
up
and
put
it
onto
your
network.
The
moment
you
press
that
learn
button.
Some
man-in-the-middle
running
on
some
compromised
bit
of
equipment
could
intercept
that.
So
we
want
ways
of
establishing
that
trust
relationship
that
don't
have
a
leap
of
faith.
Trust
on
first
use
has
worked
very
well
famously
SSH.
C
Does
that
the
first
time
you
SSH
to
a
host?
It
will
tell
you
don't
know
who
this
is.
You
want
me
to
store
the
public
key,
and
you
say:
yes,
you
cross
your
fingers
that
that's
the
right
host
and
if
it
was,
it
protects
all
future
accesses.
But
if
your
intercepted,
the
first
time
you
may
have
just
got
a
man-in-the-middle
public
key
stored
in
your
SSH
known
hosts,
so
the
way
of
doing
that
setup
that
is
not
vulnerable
will
also
be
desirable.
The
good
news
is,
we
now
know
how
to
do
this.
C
C
There
is
recently
an
RFC
but
jpeg
pages,
PA,
ke,
password,
authentication,
key
exchange,
and
I'm
I'm
very
happy
that
these
things
are
now
well
understood,
because
we
should
be
using
those
for
all
future
pairing
protocols
and
device
for
provisioning
protocols.
We
should
be
using
these
secure
key
exchange
mechanisms,
so
that
is
the
overview
of
what
I've
been
thinking
about
with
privacy.
I
want
to
thank
Christian
and
Daniel
for
their
work
over
the
last
year
or
two
on
writing
the
drafts
on
that.
B
C
Yes,
thanks
for
that
suggestion,
I
didn't
have
something
to
make
note
tick.
So
can
we
just
make
sure
that's
recorded
in
the
notes,
I'm
certain
not
saying
that
in
all
cases
padding
and
jitter
and
randomness
and
dummy
traffic
and
necessary,
but
we
should
definitely
include
that
in
our
toolkit,
but
the
things
that
are
especially
sensitive.
We
should
be
thinking
about
that
worry
right.
Yes,.
G
Michael
Abramson,
so
did
you
mentioned
a
lot
of
examples
of
things
already
in
this
area?
I
just
really
quick
through
these
through
the
draft
I
didn't
see
like
a
list
of
examples,
and
so
on
that
you
just
gave
it
is
it
in
there
and
already,
or
could
you
post
that
to
the
list
or
something
because
you
have
a
lot
of
your
brain
I'm
sure
that
when
it
comes
to
example,
so
that
that.
A
C
C
To
clarify
that
there's
kind
of
two
questions
that
you're
asking
there
one
is
the
draft
I
just
submitted,
which
is
a
framework
for
thinking
about
things.
It
doesn't
propose
any
solution
and
then
the
second
question
is
whether
we
should
continue
with
things
like
Christians
work
about
actually
trying
to
solve
these
problems.
So
maybe
we
should
ask
you
separately,
yeah.
E
B
A
Apologies
so
going
back
then
to
Stuart's
document
which
discusses
the
use
cases
and
what
we
that
I'm
going
to
ask
for
a
hunk
that
we
should
be
working
on
this.
We
should
adopt
this
as
a
workable
document,
of
course,
we'll
take
that
to
the
list
so
last,
first,
for
if
we,
if
you
think
we
should
adopt
this
and
for
how
much
you
think
we
should
yet.
A
C
And
just
to
give
a
bit
more
background,
Kristen
and
Daniel
have
been
working
diligently
on
their
privacy
and
pairing
documents
without,
to
be
honest,
a
lot
of
other
input
from
one
group,
members
and
I'm,
partly
that
my
fault,
because
I
was
busy
with
some
of
the
other
areas
that
we're
working
on
when
I
had
time
to
focus
on
this
and
realize
there
was
a
bunch
of
interesting
important
stuff.
There.
C
Daniel
and
Christian
have
an
implementation,
but
nobody
else
does,
and
neither
of
them
want
to
push
through
an
RFC
for
the
sake
of
having
an
RFC
if
it's
actually
not
going
to
be
used,
so
both
of
them
would
be
happy
with
kind
of
putting
their
documents
on
hold.
While
we
get
more
more
scrutiny
in
more
discussion,
so
this
is
not
something
to
wear
springing
on
them.
E
Lemon
I
thought:
actually
we
did
give
it
a
fair
amount
of
review.
That's
like
I,
say,
they're
doing
a
little
bit
more
work
on
the
motivating
use
case.
It's
a
bad
idea,
but
we
did
do
a
fair
amount
of
work
on
looking
at
the
document
and
talking
about
some
of
the
issues
that
you've
raised
in
this
slide
deck
already
so
again,
not
to
say
that
we
shouldn't
do
this,
but
I
actually
am
pretty
enthusiastic
about
the
work
that
they've
done
so.
C
Current
drafts
from
Daniel
and
Cristian,
in
my
opinion,
do
not
meet
the
goals
if,
if
I'd
read
them
and
thought
yes,
this
does
everything
we
need.
Then
we
probably
wouldn't
be
having
this
discussion
and
I
wouldn't
have
taken
the
time
to
write
that
requirements
draft
it's
because
I
think
there
are
gaps
in
those
documents.
But
what
I
wasn't
clear
about
was
whether
those
gaps
are
errors?
C
Yes,
we've
that's
what
we
meant,
and
that
was
that
was
when
I
started
to
realize
that
we
actually
didn't
have
a
clear
understanding
of
what
we
thought
was
important
and
what
wasn't,
at
least
in
my
mind,
that's
what
I
thought
and
that's
what
we're
here
to
discuss
it.
Everybody
else
is
clear
on
it,
then
maybe
just
mean
you
complete
the.
B
B
Section
two
of
the
DNS
SD
privacy
document
actually
cover
a
sort
of
specifically
privacy
issues
in
the
DNS
SD
protocol,
as
exist
as
it
exists
or
is
deployed
right
now,
and
so
the
question
that
you
were
starting
to
ask
was:
does
the
working
group
think
that
this
is
interesting?
Well,
if
they
didn't
think
it
was
interesting,
they
probably
should
be
arguing
that
section
two
should
be
removed
from
that
document.
I
think
because
it
actually
is
a
working
group
item
right
now.
B
I
think
the
question
is
really
should
the
privacy
considerations
or
requirements
or
orbit
around
a
phrase
that
be
split
into
its
own
document,
which
is
actually
what
I
believe
the
approach
that
Stuart
is
taking
is
actually
more
better
phrased.
That
way,
and
whether
section
two
is
then,
if
the
answer
was
yes,
then
what
our
section
two
is
moved
into
that
document
or
kept
in
here
and
normatively
referenced.
B
B
So
I
think
they
are
somewhat
complementary,
but
I'm
just
saying
that,
because
there's
already
a
working
group
item
that
does
touch
on
these
here,
I'm
coming
in
how
you
might
phrase
the
question,
people
think
that
this
is
interesting.
You
I'd
have
to
say
what
this
is.
Should
a
more
generic
exposition
on
the
security
principles
and
the
privacy
principles
and
considerations
we
put
into
its
own
document
would
be
a
good
way
to
phrase
the
question
my
opinion
and
Stuart's
document
a
good
starting
point
for
such
as
the
doctor.
It's.
M
Tok
Tok
yeah,
so
this
this
kind
of
work
is
very
important.
We've
been
looking
at
some
of
these
leaks,
pipe
information.
It's
one
of
the
human
rights
considerations
in
terms
of
birth
surveillance,
so
I
think
it's
very
commendable
to
keep
pushing
forward
with
this,
and
if
there
are
some
areas
of
reuse
that
you
need
to
go
and
also
cover
with
the
HR
PC
group
to
support
that.
C
Yes,
thanks
for
bringing
up
that
angle
to
it,
I
was
talking
about
medical
information
and
privacy,
which,
which
may
be
important
in
in
various
employment
context.
I
think
your
your
human
rights
issues
are
maybe
a
a
much
more
extreme
example
of
that,
where,
in
some
cases,
people's
lives
are
in
danger
if
they
reveal
information
that
they
shouldn't.
L
A
So
thanks
to
everyone
for
the
input
and
where
we
want
to
ask
the
question
of
whether
the
what
was
in
section
2
reviews
Jeff,
so
the
requirements
should
be
expanded
on
so
it
could
be
in
towards
document
or
it
could
be
something
else.
But
the
main
question
is:
do
we
think
it's
available
for
the
working
group
to
be
spending
more
time
on
expanding
the
requirements,
so
I'm
gonna
have
or
a
hum
for
working
on
these
requirements
and
I
haven't
guessed?
If
you
think
we
should
be
spending
time
on
this,
please
hum
now.
L
H
Under
Sullivan,
so
I
I,
don't
like
to
chair
from
the
floor,
but
I
noticed
that
the
people
who
should,
though
we
should
work
on
this,
didn't
seem
to
be
very
loud
and
so
I
guess.
The
other
question
is
how
many
people,
who
think
we
should
work
on
this,
are
actually
going
to
work
on
it,
because
that's
the
other
question.
L
Yeah,
I
think
that
I
think
the
question
I
was
gonna.
Ask
after
this
was:
can
we
get
any
tion
in
show
of
hands
to
see
people
are
willing
to
review
this
or
sort
of
work
on
the
draft
in
this
room?
Please
raise
your
hand,
see
Ted
I
see
Andrew
took
okay,
so
this
is
Barbara.
If
you
can
write
those
name
down,
so
we
can
hold
them
accountable.
That
would
be
great.
L
L
L
L
So
house
I'll
speak
up
here
about
the
session
signalling
draft,
as
you
know,
stop
co-chair
I'd
say
about
half
the
room
attending
this
up
and
the
other
half
doesn't
get
their
hands
dirty,
so
those
folks.
Actually
it
would
be
useful
from
that
point.
If
you
like,
throw
this
and
Brian
and
stuff,
you
can
sort
of
read
the
session.
Signaling
drop
as
we're
gonna,
get
ready
for
working
group
last
call
and
sort
of
take
feedback
on
that,
so
yeah
I
think
on
our
side.
We
would
appreciate
that
thanks
so.