►
From YouTube: IETF96-DNSSD-20160720-1400
Description
DNSSD meeting session at IETF96
2016/07/20 1400
A
B
C
A
A
A
D
A
A
D
I
D
D
Dns
aesthete
hybrid,
is
let's
say:
I
went
through
this
I.
My
notes,
we're
going
to
mention
DNS
SD
hybrid
in
a
later
slide.
Mdns
DNS
interrupt
is
waiting
for
a
shepherd's
cover
sheet
and
then
it
will
go
to
the
iesg
DNS.
Sd.
Push
will
talk
about
during
today's
session.
I
think
that's
it.
Oh
yeah
we'll
also
be
talking
about
the
privacy
document
as
well.
D
So
we
have
a
couple
of
major
topics
to
talk
about
today.
At
the
last
meeting
that
was
last
meeting,
we
talked
about
splitting
them
right
yeah.
At
the
last
meeting
we
came
to
the
conclusion
that
the
DNS,
the
DNS
push
document
really
needed
to
be
split
into
two
parts,
one
of
which
is
a
more
general
session
maintenance
document
to
go
through
dns
up
and
one
is
a
specifics
for
managing
dns
SD
push
which
will
go
through
this
working
group.
So
we
want
to
make
sure
that
we've
got.
D
D
Tom
and
I
are
going
to
talk
briefly
about
hybrid
proxy
deployment
and
configuration
you
know
in
a
larger
scale,
network
context.
This
is
something
we've
also
talked
about
with
Stuart.
The
idea
is
that
there
are
a
number
of
components
that
all
go
together
into
a
into
a
unicast
DSS
the
deployment,
and
we
think
that
there's
room
for
a
bcp
document
that
explains
all
of
those
pieces
in
detail.
A
D
C
A
A
At
the
point
where
the
hybrid
proxy
is
a
going
to
go
through
in
the
next
month
or
two,
the
DNS
bush
is
now
making
it
a
way
forward.
So
we've
got
some
time
at
the
end
just
to
discuss
next
steps
and
that
can
include
what
we
might
do
to
recharter
I
think
Terry
Terry's
in
the
room,
whether
he
left
he
was
as
hiding
here
behind
somebody
yeah.
J
A
A
K
A
H
J
A
E
Okay,
so
I'm
at
the
last
ITF
ray
and
Sarah
and
Alison
and
John
kind
of
approach,
Stuart
and
I
about
some
of
the
work,
we're
doing
with
put
looked
a
lot
like
what
they
needed
for
other
things,
and
so
they
asked
if
we
wanted
to
kind
of
get
together
and
see
if
we
could
come
out
something
that
would
work
for
both
of
us.
There's
an
initial
draft,
it's
out
there
and
we've
had
a
good
design
meeting
this
time.
We
kind
of
defined
that
or
you
know
what
a
session
is.
E
We
consider
to
be
a
long-lived
series
of
DNS
queries.
Either
side
can
initiate,
it
doesn't
and
get
a
response,
and
the
messages
are
should
be
arriving
in
the
same
order
they
were
sent.
So
if
you
can,
if
that
seems
to
apply
in
our
case,
we're
using
TCP
over
TLS-
and
there
may
be
other
transports
that
apply
that
as
well,
but
we're
not
going
to
dictate
what
transports
you
use.
It's
just
that
those
are
properties
are
well.
You
know
kind
of
match
our
use
case.
If.
E
This
allows
us,
instead
of
having
per
packet
signaling
messages
like
the
EDS
0
keep-alive
options.
We
can
do
it
for
the
whole
session
set
it
up,
and
then
we
don't
have
to
do
the
extra
options
in
every
packet,
so
that
work
is
progressing
and
we
should
have
a
new
new
draft
out
soon.
Based
on
the
discussions
that
we
had.
E
We
may
end
up
with
our
own
keep
our
own
formats
for
subscribe,
unsubscribe,
where
we
confirm,
or
we
may
be
able
to
incorporate
those
into
the
session
signaling
as
well.
That's
something
Stewart
and
I
are
gonna.
Look
at
sea.
One
advantage
is
that
session
signaling
is
going
to
have
its
own
opcode
and
can
define
its
own
packet
types,
and
if
we
bring
you
back
on
that
and
that
reduces
the
number
of
op
codes
that
we
use.
E
That's
something
that
the
session
singling
group
is
we're,
trying
to
figure
out
what
the
optimal
case
there
isn't.
The
next
draft
will
have
that
work
out,
so
we
hope
to
have
a
new
draft
out
soon
of
the
session
signaling.
Then
we'll
update
the
push
draft
to
reflect
all
those
changes
that
the
general
architecture
push
isn't
changing.
This
is
just
a
new
way
to
encode
the
messages
and
so
I'm.
E
J
A
L
L
The
question
was:
when
will
the
new
draft
come
out?
Are
we
we
had
a
long
meeting
discussed,
discuss
session
signaling
here
at
the
ITF?
My
plan
is
to
update
that
documents
on
my
flight
back
on
Saturday
and
then,
if
my
co-authors
approve
it
will
have
the
session
signaling
draft
done
and
give
that
a
couple
of
weeks
for
people
to
look
at
it,
and
if
people
are
comfortable,
that
direction
will
then
update
the
push
draft
to
adopt
the
new
syntax
of
the
session
signaling
mechanism.
L
M
O
A
D
D
A
I
K
F
B
K
So
in
order
to
make
that
work,
we,
the
I
shouldn't,
say
we
essentially
I've,
been
doing
all
of
this
work
and
then
I
encourage
people
to
participate
and
throw
tomatoes
and
so
forth.
But
anyway,
I
have
been
come
other.
The
solution
that
I
that
I
thought
made
the
most
sense
was
to
was
to
have
the
the
home
net,
essentially
have
a
local
DNS
zone
that
has
all
of
the
names
in
it.
At
least
that's
what
it
should
look
like
to
the
end
user.
That's
a
little
bit
different
than
the
DNS
SD
hybrid
model.
K
The
DNS
SD
hybrid
model
has
what
looks
like
a
zone
for
every
link.
Actually
three
zones,
for
we
need
to
talk
about
that
and
it's
a
really
neat
solution.
It
basically
works
by
triggering,
if
you
do
a
DNS
query,
that
triggers
n
DNS
queries,
which
answer
the
questions
and
if
you're
using
DNS
push
than
you
get
better
results
very
nice
system
which,
for
the
most
part,
I
think
we
should
also
use
on
home
nets
and
but-
and
it
also
does
support
I-
think
caching
that
doesn't
require
it.
K
So
the
ID
on
home,
that's
is,
is
that
I
think
I
got
a
home
that,
in
order
to
make
the
network
make
sense,
we
actually
need
to
build
a
cache
that
has
the
information
we've
learned
from
the
network.
We
need
to
be
a
little
bit
more
proactive
in
learning
information
about
the
network,
which
means
that
we'll
probably
sit
there
and
listen
for
you
know
when
an
mdns
device
is
powered
on
it
announces
that
it
exists.
K
That's
the
last
time
you
hear
about
it
unless
you
wish
you
a
query,
so
we
want
to
track
that
we
want
to
track
what
happens
when
people
make
queries
and
so
forth.
We
don't
want
to
reveal
a
topology
in
order
to
not
reveal
the
topology.
The
reason
why
wydn
SSD
hybrid
reveals
the
topology
is
because
it
eliminates
the
the
conflict
problem,
the
naming
conflict
problem.
K
If
you
have
two
devices
on
two
different
links
with
the
same
name,
they
don't
have
the
same
name
because
there's
a
there's,
an
additional
name
interpose
that
that
identifies
the
link,
and
so
you
just
have
printer
a
on
link.
A
and
printer
a
on
link
be
and
there's
no
naming
conflict,
it's
a
little
confusing,
maybe
but
there's
our
naming
conflicts.
So
that's
that's
a
good
thing,
but
link
a
and
Link
be
aren't
going
to
make
any
sense
to
an
end
use
if
they
don't
know
what
those
links
are
in
a
home
net.
K
In
a
like
at
a
college.
You
know
the
link
link,
a
might
be,
might
have
a
name
that
the
administrator
put
in
it.
That
actually
makes
real
sense.
That's
not
going
to
be
the
case
here
so
to
handle
the
duplicate
problem.
I've
thought
about
this
a
lot,
and
this
is
very
much
a
work
in
progress
and
I'm
open
to
alternative
suggestions.
The
various
things
that
I've
considered
have
been
just
essentially
taking
the
duplicates
from
the
mtns
database
or
from
the
M
DNS
queries
and
adding
a
little
identifier.
K
The
that's
like
a
number
that
represents
the
link.
My
current
feeling
about
this
is
that
the
best
thing
to
do
is
actually
cross
defend
once
so
that
so
suppose,
some
some
device
comes
up
on
link
a
and
says
hi
I'm,
printer
one,
and
then
some
device
comes
up
on
like
B
and
says
hi
I'm
crater,
one
on
the
home.
That
will
defend
that
name
against
the
second
printer,
and
one
of
two
things
will
happen:
either.
Assuming
no
attackers
which
it's
a
home
net
I
mean
whatever
so
either.
K
Both
printers
will
change
their
name
or
only
one
will
and
the
case
where
only
one
does.
It
was
actually
two
different
devices
in
the
case
where
they
both
do
it's
the
same
device.
This
is
my
theory,
so
so
that's
the
nice
thing
about
this
as
compared
to
adding
on
some
names
in
the
in
the
in
the
DNS
view
of
vm,
dns
name
space
is
that
now
the
names
are
consistent
when
you
see
them
in
the
user
interface.
K
K
So
anyway,
I
just
thought
of
a
problem
with
that
yeah,
which
is
the
dot
local
and
home
that
are
not
the
same
string.
But
you
know
life
is
full
of
tragedies
so
anyway,
as
you
can
see,
this
is
this
is
very
much
a
work
in
progress
that
needs
work.
But
the
idea
is
that
we
keep
a
real
DNS
zone
with
forward
reverse
lookup
information
and
that
can
be
securely
updated,
using
DNS
updates
or
if
there's,
if
the.
K
If
the
service
doesn't
support,
doing
secure,
updates
or
just
have
to
be
signed
with
60,
then
it
can
just
do
the
update
on
the
local
wire
and
we
basically
treat
it
as
just
as
trustworthy
as
an
mdns
advertisement,
which
is
to
say
no.
What
are
you
gonna
do
so
and
then,
but
we
give
priority
to
names
in
the
DNS
zone.
K
So
if
some,
if
we
have
a
device,
that's
publishing
its
name
in
the
DNS
and
then
some
other
device
comes
along
and
publishes
a
name
using
mdns,
then
the
home
that
will
defend
the
name
so
that
the
second
device
that
came
along,
because
in
this
case
we
know
they're
different
devices,
because
one
of
them
supports
DNS
updates
and
one
of
them
does
it.
So
so,
in
that
case,
the
the
home
that
will
defend
that
name
using
mdns
and
presumably
the
second
device
will
get
a
different
name
and
everything
look
good.
K
K
Just
that
question
occurred
to
me
kind
of
out
of
order.
I
need
these
slides
up
about
two
minutes
ago.
So
a
couple
open
questions.
You
know
how
they're
they're
open
issues
with
the
name
name
claiming
stuff
and
actually
a
I'm,
no
longer
convinced
that
it
works.
But
but
that's
one
question
to
answer.
Another
question
is:
do
we
maintain
a
DNS
zone
that
has
everything
in
it?
It
has
serial
number.
K
My
original
when
I
originally
thought
this
through
the
design,
was
that
it
would
in
fact
have
a
serial
number
and
would
contain
all
the
mtns
data
I
think
that
works
best,
but
it's
a
little
harder
to
implement.
So
there's
a
trade-off
to
be
made
there.
The
reason
that
the
reason
why
works
best
is
because
now,
if
you
do
a
DNS
update
the
data
from
mdns,
is
there
and
can
be?
K
Can
be
seen
by
the
update
query,
so
updates
have
predicates
sand
and
if
you,
if
you
put
in
a
predicate
you'd
like
it,
if,
if
so,
if
a
host
tries
to
create
something,
but
only
if
something
else
is
true-
we'd
like
that
predicate
actually
work.
So
that's
kind
of
the
motivation
for
that
bullet
item.
I,
don't
know
how
important
that
is.
K
K
E
E
K
And
the
reason
I'm
objecting
to
that
is
not
because
it's
inherently
bad,
it's
not.
It
actually
makes
sense
if
you
have
a
managed
network,
but
I,
don't
think
it
makes
sense.
If
you
have
a
home
that,
because
the
home
Nets
topology
is
essentially
random
and
the
end
user
going
to
have
no
idea
which
link
is
linked,
one
they're,
not
even
necessarily
to
know
what
a
link
is
and
so.
E
K
Entirely
how
DNS
SD
works?
That's
certainly
one
model
for
how
DNS
SD
works,
but
that's
not
the
whole
picture
like
if
you're
using
you,
no
I,
see
many
apple
logos
here,
any
one
of
those
laptops
if
it's
doing
AFP
all
right,
Apple
file
sharing
it
in
the
user
interface.
When
you
enable
file
sharing.
It
says
this
laptop
can
be
reached
on
this
address
and
that's
true
for
ssh
and
all
those
things
that
address
has
to
make
sense.
It's
not
good
enough
to
say
some
addresses
make
sense,
but
other
addresses
will
be
gibberish.
K
They
all
have
to
make
sense
and
people
are
used
to
domain
names.
They
know
what
they
look
like.
They
they
kind
of
have
they
don't
necessarily
understand
the
structure
of
domain
names,
but
but
they've
seen
enough
of
them
that
they
that,
if
you,
if
you
present
them
something
weird
they're
gonna,
it's
gonna,
it's
going
to
be
a
problem.
I
think
it's
its
usability
issue.
So
I
don't
know
I
it's.
This
is
definitely
a
matter
of
taste.
K
D
D
What
the
word
reveals
means
to
you
may
not
mean
the
same
as
what
reveals
means
to
to
a
casual
user,
that
is
to
say
a
lot
of
the
existing
Apple
interface
anyway
hides
the
entire
DNS
structure.
So
if
there
is,
if
so,
you
know
what
I'm
talking
about,
and
so
all
you
see
is
the
host
name.
You
don't
see
all
of
the
other
stuff
right
for
those
examples.
K
What's
the
answer
one
answer
to
this
is:
is
a
let's
do,
plan
a
which
is
reveal
the
topology,
and
then
you
know
we
can.
We
can
add
later
a
way
of
unrevealing
the
topology,
my
only
and
and
I
don't
see
any
particular
downside
to
that,
and
maybe
it's
not
worth
so
there's
someone
behind
you
who
just
just
went
like
this
when
I
said
that
so
maybe
he
has
a
strong.
K
K
But
they
have
a
different
idea
of
what
they're
looking
for
everywhere.
Every
user
has
a
different
idea
of
what
they're
looking
for,
and
what
I
want
to
do
is
is
make
it
be
the
case
that
what
we
present
is
is
understandable
and
as
simple
as
possible,
without
being
so
simple
that
it
actually
becomes
more
complex,
which
is
all
kind
of
problem
it
actually
might
might
be
worthwhile
to.
D
Run
some
experiments
yeah.
You
know
to
actually
do
some
demos
to
see
here's,
here's,
a
here's,
a
hybrid
proxy
deployment
and
and
here's
what
happens
when
I
connect
my
iOS
device
onto
the
first
SSID
on
this
little,
this
little
home
network
deployment
with
these
ugly
names
and
see
where
I
just
get
the
host
names
and
I
mean
I'm.
Sorry,
the
servants
in
service
instance
names
and
where
I
get
actually
the
the
full
ugly
names
and
and
see
what's
tolerable
and
what's
not
yeah.
K
D
Spent
a
little
time
reading
the
HNC
p
document
recently,
some
of
you
may
be
aware
of
that.
Not
that
we're
bitter
yeah
I'm,
not
bitter
on
the
bitter
but
I-
have
been
spending
a
lot
of
time,
trying
to
read
it
yeah,
and
there
is
something
in
there
about
having
that
h.
Ncp
routers
are
required
to
assign
a
name
of
some
sort
to
every
link.
Yes,
so
if
that's
already
happening,
then
that's
yes,
but
what
does
that
name?
Look
like
I
and
we're
coming
full
circle,
because
I
claim
I,
don't
care
even
I.
Don't
care
well.
K
D
N
K
K
I
mean
forgive
me,
but
but
what
you
just
said
slightly
trivializes
the
conversation,
though,
because
it's
pretty
clear
that
the
names
will
show
up,
because,
if
you've
got
a
printer
on
on
on
link
a
and
the
st.
and
a
printer
with
the
same
name
on
unlink,
be
right,
you're
gonna
see
the
name.
There's
no
way
to
avoid
that.
That's
that's
part
of
the
design
that
that's
okay.
Now
it
may
be
that
that
never
happens,
in
which
case
we're
fine,
okay,.
M
Happened
to
a
sense
of
subject,
an
email
on
this
precise
subjects,
the
open
a
list
within
the
last
hour
without
much
chair
hassle.
These
said
these
names
do
appear.
Not
every
device
accessed
via
Bonjour
with
local
is
accessed
via
a
device
class
specific
control
panel,
which
hides
that
dot.
Local
name
from
you,
yeah
I
have
two
devices
on
my
home.
You
know
one
of
theirs
and
ours,
which
is
primarily
accessed
as
yet
nazdar
local
and
the
management
is
that
is
done
via
a
web.
M
Browser
I
ought
to
be
able
to
bookmark
that
I
don't
want
that
bookmark
to
changed
in
or
which
particular
segment
of
my
network
that
NASA's
currently
plugged
it
into
so
I'm,
so
I
think
not
an
issue
which
will
be
not
get
hung
up
on
just
the
human
readability
aspect
of
this,
but
has
also
views
the
subsequent
usability
of
these
names.
As.
A
J
A
L
L
M
J
L
L
L
Ralph
has
already
suggested
that
we
need
some
kind
of
bcp
or
deployment
advice
or
some
kind
of
guidance
for
how
you
build
a
system
using
these
building
blocks,
and
that's
that's
a
gap
that
we
have
right
now.
Yeah
I
actually
agree
with
you
that
the
final
solution
that
we
put
together
should
hide
these
link
names.
L
Part
of
that
is
a
question
of
you,
I
that
we
don't
design
in
the
IETF.
I
agree
with
what
ralph
said
that
part
of
this
process
is.
We
should
take
a
look
at
the
current
you
I
that
exists
in
various
bits,
software
and
see
how
it
handles
this
and
displays
it,
because
the
display
is
not
uniform
and
consistent.
L
For
instance,
Safari
will
just
display
the
instance
name
as
long
as
it's
unique,
but
if
it
finds
a
NAS
device
on
two
different
subnets,
then
or
two
different
subdomains,
it
will
put
the
subdomain
name
in
parenthesis
after
the
device.
So
you'll
have
mass
device
or
you'll
have
nasty
fights
brackets
Ethernet
NAS
device
brackets
Wi-Fi
I'm
not
advocating
that
because
that's
full
of
problems,
because
if
you
call
your
device
nas
device
brackets
Wi-Fi,
then.
L
But
the
point
is
that
is
something
the
Safari
engineers
came
up
with
and
other
tools
that
the
UI
is
not
consistent
and
to
make
things
even
worse.
Once
we
roll
out
this
hybrid
proxy
stuff
and
it
becomes
widespread,
those
application
developers
may
well
go
and
update
their
you
ice
in
response
to
that.
L
K
So
let
me
just
say
that,
having
listened
to
you
say
that
I
realized
that
I
actually
made
the
complete
wrong
slide
deck,
because
the
sales
pitch
that
I
really
want
to
give
here
is
the
sales
pitch
for
we
need
to
replace
mdns
with
something
that
works
on
larger
networks
and
which
I,
don't
think,
is
controversial,
maybe
I'm
wrong.
The
reason
being
mdns
works
really
well
on
a
single
wire
I
mean
it's
great.
K
So
so
the
whole
point
of
this
is
to
create
a
context
in
which
there
is
an
incentive
for
printer
manufacturers
to
do
something
other
and
and
for
everything
that
now,
as
manufacturers,
whatever
to
do
something
other
than
mdns,
because
you
know
you
have
dns
update
in
RFC,
67-63
I
foresee
several
biz
in
a
future
Ted.
What's.
L
K
L
Thanks
I'll
make
one
quick
final
comment
to
raise
points.
I
completely
agree
with
what
you're
asking
for
I
just
don't
know
how
we
do
it
in
the
general
case
and
what
a
what
I'm
talking.
That
is,
if
my
NASA's
on
Wi-Fi
and
I
decide
to
run
a
gigabit
ethernet
cable
to
it,
because
it's
that,
because
it's
faster
I,
completely
agree
with
you
I
would
like
the
name
to
not
change
out
like
the
bookmarks
to
not
change.
But
how
far
do
we
take
that?
L
C
C
J
K
So,
in
order
for
that
to
so
there's
two
ways
that
that
can
work,
one
is
that
the
name
is
a
dependable,
that
is
to
say
it's
not
going
to
change
over
again,
assuming
you
know
that
you
don't
get
rid
of
that
printer
or
whatever,
but
but
as
long
as
that
printer
still
lives
on
your
network,
it's
always
going
to
have
the
same
name.
If
you
can
make
that
assumption,
then
the
UI
can
just
put
a
different
name
on
the
printer.
There
are
a
couple
issues
with
that.
K
K
So
when
you,
when
you,
when
you
go
to
your
UI
in
chrome,
you
can
you
can
click
on
the
thing
or
in
in
Safari
or
whatever
you
can,
click
on
the
object
and
you
get
a
little
cursor
in
it
in
a
text
field
and
you
can
edit
the
text
field
and
then,
when
you're
done
editing
the
text
field.
Some
message
goes
out
on
the
wire
and
as
a
result
of
that,
the
name
of
that
object
is
permanently
changed.
And
ideally
you
want
that
change
request
to
go
all
the
way
to
the
object
right
so
well.
C
K
K
L
Right
I'll
try
to
make
this
quick.
It
sounds
to
what
you're
proposing
Ted
is
something
like
an
SNMP
set
operation
for
some
standardized
mechanism
for
set
the
name
of
a
device,
and
I'm
actually
not
saying
that
advocated.
I'm
saying
that
to
kind
of
point
out
that
you
know,
maybe
it's
never
going
it's
a
hard
problem
that
I
would
love
to
see.
Some
standardized
network
protocol
for
set
name
of
device,
I
just
don't
know
how
we'd
get
anybody
to
adopt
it.
Yeah.
J
L
L
I
recently
bought
a
new
house
and
I've
been
buying
amplifiers
for
the
stuff,
and
it's
actually
been
really
gratifying
to
me
that
almost
every
device
I
bought
has
a
bonjour
advertised
web
UI
on
it.
In
fact,
really
surprising.
I
wasn't
searching
for
that.
That
wasn't
my
litmus
test,
whether
I
buy
a
product.
L
L
K
O
J
O
K
L
L
A
A
We're
hearing
is
thanks
for
doing
the
work
Ted
as
much
appreciated.
Clearly,
Ted
needs
help,
there's
a
suggestion
of
having
a
design
team,
whether
formal
or
informal
I
think
that
would
be
a
good
thing
to
do
with
people
like
touch
to
it
ray
if
they're
willing
to
do
that,
and
any
other
volunteers
want
to
come
forward.
There
is
does
seem
to
be
the
kind
of
flat
homenet
problem
that
we're
trying
to
solve
here,
but
there's
also
the
interweaving
of
DNS
update
and
hybrid
proxy
and
a
campus
type
environment
as
well.
A
There's
two
threads,
their
final
question,
not,
and
if
it's
for
sure
or
who
it's
for,
but
is
Marcus
stenberg
in
the
room,
no
well
he's
got
a
working.
Maybe
you
can
answer
this
way.
There
is
a
draft
Marcus
wrote
about
hybrid
proxy
in
home
net,
or
were
you
suggesting
that's
no
longer
the
way
or
okay,
all
right,
we'll
take
that
offline,
never
mind?
A
D
You
have
some
slides
or
anything
ready
to.
You
were
you're,
going
to
talk
about
your
implemented.
Oh
okay,
okay,
I
did
you
outside
I?
Have
slides
I'll
walk
through
what
I
have
to
say
what
we?
What
we
had?
What
we
were
interested
in
is
your
work
on
Hydra
proxy
implementation,
but
so
let
me
walk
through
my
slides
and
then
chimed
in
so
I'll.
Take
this
back.
A
D
So
I
have
nothing
like
a
bcp
document.
Nothing
like
laying
out
all
the
possibilities.
All
I
want
to
do
today
is
run
through
some
of
the
components
that
make
up
the
building
blocks
of
unicast
DNS
SD
as
Stuart
was
alluding
to
and
give
one
small
example
of
how
those
can
be
put
together
in
a
in
a
particularly
in
a
particular
way
for
stitching
the
various
zones
together
to
accomplish
particular
requirement.
D
The
idea
here
is,
as
Stuart
was
saying,
to
get
to
a
unicast
DNS
SD
deployment,
while
still
accommodating
multicast
DNS
devices
and
start
broadening
the
way
we
think
about
these
pieces
as
as
as
building
blocks
and
being
able
to
be
put
together
in
in
lots
of
clever
ways.
As
always,
since
this
is
a
naming
problem,
there
are
lots
of
opportunities
for
doing
clever
things
with
names
and
levels
of
indirection
inside
the
various
components
that
we
haven't
really
even
started
to
begin
exploring.
Yet
ok,
so
we
all
know
this
stuff.
D
I
just
want
to
make
sure
everybody's.
On
the
same
page,
dn
SSD
is
independent
of
the
DNS
transport
right.
You
send
the
same
queries
over
multicast
DNS
as
you
do
over
unicast
DNS.
Let
me
get
evaluated
the
same
way.
You
get
the
same
responses
back.
It's
just
a
question
of
the
transport,
whether
it's
multicast,
DNS
or
unicast,
DNS
unicast,
DNS
SSD,
is
a
good
thing.
It
avoids
the
overhead
of
multicast.
Dns
I
may
have
relayed
this
antidote
before
a
friend
of
mine
captured
a
packet
trace
of
traffic.
D
A
Cisco
live
where
the
deployment
tends
to
be
a
very
large
bridge,
single
link
in,
in
which
there
may
be
as
many
as
10
or
20,000
people,
and
you
know
how
we
are.
We
probably
have
three
or
four
of
these
things
that
we're
all
carrying
around
at
communicating
over
over
mdns
the
traffic.
The
multicast
DNS
traffic
on
that
packet
capture
was
something
like
forty
percent
of
the
packets
over
the
period
of
time
that
I
looked
at
it.
D
So
it's
so
DNS
SD
avoids
all
that
overhead
and
DNS
SD
can
avoid
the
overhead,
even
if
you're,
some
of
the
overhead,
even
if
you're
using
multicast
DNS
for
legacy
devices,
because
you
don't
have
to
to
forward
the
multicast
DNS
traffic
from
the
legacy
devices
across
the
entire
multi-link
network.
You
can
you
can
isolate
it
to
a
single
link
and
then
use
unicast
DNS
in
clever
ways
to
communicate
across
to
do
dns
service
discovery
across
remote
links.
So
some
considerations-
this
is
consideration
at
scaling
responses
to
service
discovery.
D
It's
great.
If
we
can,
we
can
have
a
way
of
merging
together,
multicast
dns
eunuch
SDNS
SD
into
a
single
sort
of
search
domain.
But
if
I
pull
down
the
menu
and
ask
for
all
the
printer
services
at
cisco,
I'm
going
to
get
a
list
that's
way
too
long
and
not
very
relevant
to
what
I
want
to
do.
So
I
want
to
be
able
to
to
to
filter
that
to
get
just
the
just.
D
The
printers
that
I
might
be
interested
in
one
way
to
do
that
filtering
is
to
modify
the
responses
that
come
back
from
from
dns
SD
service
queries
based
on
location.
So
is
there
a
clever
way?
I
can
take
the
DNS
SD
infrastructure
and
structure
it
in
such
a
way
that
I
get
back
just
the
the
responses
from
devices
that
are
physically
in
my
vicinity
and,
as
I
said,
we've
got
to
accommodate
legacy
devices.
This
is
the
conversation
we
had
at
the
end
of
the
previous
presentation.
D
D
Excuse
me,
so
what?
What
are
the
tools
involved
here?
What
are
the
building
blocks
that
we
can
put
together
in
a
tip
to
get
a
emerged?
Unicast,
DNS,
SD,
multicast,
DNS,
DNS,
SD?
Well,
first
of
all,
their
duties,
DNS
SD
client
configuration
resource
records.
There
are
actually
several
of
the
magis,
but
one
example
up
here
as
an
example
so,
and
these
these
configuration
ours
come
from
a
couple
of
different
places.
So
the
idea
here
is
the
client
device
gets
its
domain
name
from
dhcp.
D
So,
for
example,
example.com
it
pre
pens,
lb,
underscore
dns
SD
w
square
UDP
sends
that
out
as
a
unicast,
a
unicast
dns
query,
there's
a
second
kind
of
query:
that's
made
by
taking
the
subnet
that
the
device
is
attached
to
so
the
device
takes
its
address.
Ip
address
applies,
the
subnet
mask
and
gets
a
gets.
A
subject
number
puts
it
into
IM,
a
darpa
format
and
issues
that
request
and
then
finally
it'll
issue
an
lb
request
on
that
local
/
mdns.
D
Now
I
do
have
a
pointer.
The
hybrid
proxy
servers
themselves
and
then
there's
the
organization
DNS
SD,
server
or
DNS
server,
which
we're
going
to
use
to
stitch
all
this
stuff
together.
So
the
organization
dns
dns
server
has
the
unique
sdn,
SSD
client
configuration
or
ours
these
things.
It
has
the
delegations
from
the
central
zone
for
the
organization
to
the
hybrid
proxy
servers,
and
it's
got
these
these
these
funny
subnet
entries,
ok,.
D
So
how
do
we
stitch
all
these
things
together
in
this
particular
example?
In
this
particular
example,
what
I
want
to
do
is
show
how
we
can
do
use
hybrid
proxy
servers
to
generate
location,
dependent
search
lists,
so
that
device
will
only
get
services
that
are
of
interest
based
on
its
location.
In
a
building
we
got
a
building
with
three
floors
floor,
1,
2,
&
3.
The
device
is
going
to
be
on
one
of
those
floors
and
it's
going
to
get
a
DNS
SD
unicast
search
list.
D
That
depends
on
which
floor
it's
on
and
therefore
it
will
only
search
part
of
all
of
the
available
services
and
just
look
at
the
adjacent
floors.
So
it's
on
floor
one.
It's
going
to
look
at
floor
one
in
floor
too,
so
we
deploy
hybrid
proxies
on
all
three
floors.
We
put
the
delegations
of
the
organization
servers
and
we
add
these
entries
for
each
link.
Okay,
so
we've
got
the
the
browsing
domain
link
for
subnet,
one
which
I'm
assuming
is
on
floor
one
and
it
gives
back
to
PTR
records
floor
one
in
floor
too.
D
L
No,
you
got
that
perfectly
right.
I
I
wanted
to
add
a
comment:
okay,
because
this
is
something
that
comes
up
repeatedly.
I
want
to
make
sure
everybody
realizes
that
what
Ralph
is
describing
here
is
not
a
proposal
for
what
we
might
do
in
the
future.
This
is
the
software
that
you
all
have
on
your
macs
and
iphones
today
and
if
you
hit
command
p
and
the
terminal
room
printer
shows
up,
will
you
press
the
air
print
button
on
your
phone?
This
is
what
it's
doing.
D
D
D
Gets
all
three
search
domains
and
then
the
device
on
the
third
floor
just
gets
42
and
43
okay.
So
when
one
of
these
devices
now
does
a
you
know,
does
it
pull
down
to
do
service
discovery?
It
will
either
look
at
the
services
on
the
hybrid
proxies
in
floor
one
in
floor
two.
If
it's
on
floor,
two
it'll
look
at
the
hybrid
proxies
on
floor,
one
two
and
three
and
get
all
other
resources
back.
That's
on
for
three
it'll,
just
look
at
two
and
three,
so
the
unicast
DNS
SD
client
on
floor.
D
One
resolves
its
browser
RR.
It
sends
out
these
queries.
The
results
are
merged.
In
the
leftmost
naval
labels,
the
instance
names
are
displayed
and
so
you'll
actually
get
a
little
pulldown
menu.
That
has
just
the
printers
on
the
local
link
on
the
dot
local
link
and
on
floor
one,
and
for
two
that's
pretty
much
it.
D
That's
the
that's
trying
to
kick
off
the
discussion,
trying
to
give
you
an
idea
of
where
Stuart
and
perhaps
tom
and
I
are
going
to
start
and
writing
a
PCP
document
that
lays
this
out
in
more
detail
that
that
gives
some
gives
more
examples
about
how
you
can
stitch
these
things
together
in
in
more
clever
ways.
Yeah.
A
D
So
that's
an
excellent
question
about
what
tools
the
administrator
has
to
put
these
things
in
place.
Now,
let
me
try
two
different
scenarios.
The
first
scenario
is,
if
you're,
considering
a
an
enterprise
scale
deployment
where
you
actually
have
a
real
straighter,
there's
still
a
lot
of
opportunity
for
support
tools
here.
So
if
you
were
to
buy
all
of
your
gear
from
some
major
router
vendor,
they
might
give
you
some
support
software.
That
goes
along
with
this.
D
These
crazy
are
ours
out
and
push
out
all
of
the
the
configuration
pieces.
Now,
if
you're
in
the
home
network,
you
wouldn't
probably
use
this
strategy
for
trying
to
try
to
restrict
the
search
areas,
because
you
don't
have
an
administrator
and
you
don't
know
that
the
first
router
is
the
one
that's
downstairs
in
the
basement.
Next
to
the
next
to
the
DMark,
where
your
your
internet
comes
in
on
some
major
ISP
and
the
other
router
you
have
is
up
in
the
Far
bedroom
corner.
D
On
the
second
floor,
because
the
Wi-Fi
from
the
first
one
doesn't
quite
get
around
the
corner
of
the
wall
in
the
basement,
you
needed
a
second
one
upstairs.
So
in
that
case,
instead
of
individual
browsing
lists
for
each
individual
subnet,
you
just
use
of
a
system-wide
browse
list
for
all
of
the
all
the
devices
in
your
network.
D
A
A
Of
time
for
about
five
minutes
of
comments
before
we
take
this
to
the
list,
hopefully
this
has
given
the
room,
the
sort
of
feel
for
the
type
of
things
we're
trying
to
do
here,
as
I
think
Stuart
mentioned
earlier.
There
are
other
issues
like
what
the
UI
looks
like
and
Ted
hinted
to
that
with
what
he'd
like
to
do
with
being
able
to
name
devices.
So
there
are
many
pieces
to
this,
many
of
which
aren't
within
our
remit
to
actually
deal
with.
A
D
P
D
So
I'm
I'm
I'm
not
going
to
answer
that
right
now,
because
AI
don't
know
how
to
and
be.
I
think
this
is
exactly
the
kind
of
consideration
we
want
to
put
into
the
document
in
the
long
run,
rather
than
trying
to
worry
about
the
specific
solutions
here.
But
but
that's
exactly
the
kind
of
thing
I
need
to
walk
through
so.
A
E
E
You
can
configure
it
at
the
delegating
server
to
to
get
in
the
hybrid
proxy
can
figure
out
what
it
needs
to
know
from
the
delegating
server
or
you
can
have
the
delegating
serve
or
even
have
the
hybrid
proxy
update
the
delegating
server
and
so
they're
kind
of
an
auto
configuration
mode
and
so
I
think
we
wanted
to
make
the
distinction
between
the
two
ways
you
can
do
it
as
far
as
the
previous
question
about.
Why
are
you
talking
about
delegation
server
as
well?
E
Q
The
magical
red
button
hi
very
briefly.
First
of
all,
there
are
a
couple
inserted
a
couple
of
snarky
comments
in
the
jabber
log
that
I
want
to
take
a
look
at
it
some
stage,
but
are
not
worth
spending
time
on
today,
more
important,
just
as
an
observation
about
how
complicated
the
world
gets.
I've
been
working
with
some
architects
of
the
traditional
building
variety.
On
on
what
turns
out
to
be
an
aspect
of
some
of
the
problem.
Q
You
we've
been
talking
about
Ralph
and
just
want
to
mention
that
some
of
the
assumptions
you've
made
in
your
presentation
assume
either
that
everything
is
wired
or
that
when
we
design
buildings
and
their
interiors
are,
we
are
going
to
insist
upon
new
kinds
of
carpeting
consisting
of
a
wire
mesh
which
runs
edge
to
edge
to
edge
cross
room
scanties,
thoroughly,
grounded
sufficiently
to
prevent
radio
waves
from
from
moving
between
floors
and
and
I.
Can't
tell
you
that's
going
to
happen.
Q
A
I
just
thought
it
was
were
nothing:
oh,
don't
go
yeah
and
I.
Think
from
my
experience
of
managing
the
campus
environment,
you
and
when
you
do
a
campus-wide
the
point
of
wireless,
for
example,
you
have
a
number
of
controllers
and
the
access
points
they
control
can
be
anywhere
and
you
have
things
like
VLAN
pooling.
That
means
you
can
have
two
devices.
In
the
same
that
it's
a
we
need
to
think
about
all
these
things.
I
think
it's
a
very
good
point
and
please
do
take
that
forward
on
the
list.
Yeah.
D
L
Agreed
the
similarities
and
I
think
likewise,
we
don't
currently
have
any
solutions
because
I
I
I'm
not
aware
of
any
technology
in
my
phone.
That
knows
what
floor
of
the
building
I'm
on
right.
Now,
gps
only
works
at
all
outdoors
and
even
then
not
to
a
sufficient
accuracy
to
tell
you
within
a
meter
where
you
are
reliably
so
yeah.
It's
it's
it's
a
it's
an
open
problem.
J
My
name
is
danica
I'm,
a
PhD
student
at
the
University
of
concert
and
I
want
to
present
our
draft
DNS
st
privacy
extensions.
So
the
draft
is
about
the
privacy
problems
arising
and
using
dns
st,
and
it
also
gives
a
first
solution,
which
we
call
a
two-stage
solution,
that
it
was
added
in
the
second
version
of
the
job.
J
J
I
feel
so,
let's
assume
Alice
wants
to
offer
present
service,
which
is,
for
instance,
used
by
ichat
or
pigeon,
and
during
service
browsing.
Her
device
will
offer
a
point
resource
record
which
looks
like
this,
and
this
tells
other
devices
that
there
is
a
new
service
of
the
try
presents.
But
this
brings
the
privacy
problem
of
giving
a
list
of
service
instances
that
is
offered
by
a
device,
then
for
service
browsing
her
device
will
offer
the
corresponding
text
and
service
resource
records.
The
service
record
might
look
like
this.
J
It
contains
the
part
of
which
the
application
is
listening
and
the
host
name.
The
host
name
is
a
privacy
problem,
especially
if
it
contains
two
users
name
which
is
often
on
the
default
behavior
and
the
part
often
identify
the
service
type.
Then
the
text
to
source
record
contains
further
information
about
the
service
and
my
content.
Private
information
like
here
on
the
full
name
or
a
chat
status,
and
then
for
host
name
resolution.
We
use
the
typical
I'm
a
resource
record
which
again
discloses
the
hostname.
J
So
on
as
a
mitigation
technique,
we
propose
the
two-state
solution
which
divides
the
service
discovery
process.
In
two
stages,
the
first
one
is
directly
discovery
and
the
second
is
a
service
discovery.
The
motivation
for
dividing
this
is
that
we
want
to
offer
services
directly
to
on
piers
that
can
actually
use
the
service
so
meaning
that
in
the
first
stage,
peers
discovered,
select
peers
and
in
the
second
stage
they
directly
queries
them
for
for
service
information.
J
This.
This
could
also
be
used
for
other
arm
discovery
protocols
so
enduring
directory
discovery.
The
house
discover
a
special
service
that
is
offered
by
a
private
directory
and
we
call
the
service
dis
the
PhDs
service,
and
this
is
implemented
as
a
minimal
dns
server
running
on
on
the
host
and
when,
like
in
this
example,
Alice
Anderson
ever
she
will
first
look
for
these
pair
peers
or
for
the
select
peers
and
then,
in
the
second
stage,
cure
them
directly.
J
But
to
be
able
to
do
privacy-preserving
service
discovery,
the
devices
need
to
know
or
need
to
identify,
authorized
devices
that
are
allowed
to
get
the
service
information
and
to
establish
the
necessary
relationship.
We
prefer
the
device
pairing.
This
is
the
only
step
that
will
need
user
interaction,
so
it
has
to
be
as
convenient
as
possible.
We
propose
two
kinds
of
pairing:
the
first
one
is
an
intra
user
pairing
which
we
use
to
pair
device
of
the
same
user,
and
then
they
have
an
entry
user
pairing
which
we
use
to
parry
devices
of
friends.
J
So
for
the
intro
use
of
hearing
you
can
use
methods
that
require
a
little
to
none
user
interaction,
but
for
interview,
the
pairing,
many
different
means
we
were
on
discussing
both
push-button
methods
or
transmitting
a
secret
and
public
authentication
keys,
which
can
then
be
verified
using
QR
codes.
This
QR
codes
methods
are
already
like
used
for
instant
messaging
applications
like
like
pigeon,
but
we
still
don't
know
how
to
reduce
this
to
practice
and
also
one
discuss
Harry
so
for
secure
for
private
office
of
the
PSD
SS
instances.
J
We
need
obfuscate,
at
instance,
names
and
we
generate
them
by
using
a
secret
exchanged
during
pairing
and
hashing.
This
concatenated
with
a
seat,
and
this
seed
is
a
a
time
stamp
around
in
time
stamp.
That
allows
us
to
pre
calculate
these
values
and
we
use
pairwise
identifiable,
obvious
gated
names
and
packed
ten
of
those
after
ten
of
those
names
of
one
service
instance
name
to
make
it
more
efficient.
J
J
J
It
reduces
visual
collateral
because
all
these
PSD
s
instances
belong
to
a
dedicated
service
type
and
can
easily
be
hidden
in
a
user
interface,
and
it
offers
services
only
directly
to
parent
devices.
And
the
second
question
is:
should
we
work
on
pairing?
Pairing
is
essential
for
privacy,
preserving
service
discovery
and
other
applications
will
also
benefit
from
this.
So
thank
you
for
the
attention.
A
K
K
The
pairing
problem
is
actually
slightly
larger
than
you've
described,
because
you
the
way
that
users
discover
each
other
is
that
they
get
some
message
saying
that
they
get
some
indication-
the
user
interface
that
there's
someone
there
to
discover
without
that
mechanism.
They
may
not
even
be
aware
that
there
is
a
chat
thing
that
they
can
use
to
talk
to
each
other.
So
if
you
want
to
do
this,
I
think
that
you
need
to
be
able
to
say
something
like
somebody
new
showed
up
on
the
network,
you
might
want
to
look
into
that
somehow.
J
About
the
what
we
as
of
yet
thought
of
us,
that
that
like
when
trying
to
use
an
instant
messaging
applications,
users
have
let
day
they
know
each
other
beforehand,
and
then
they
will
meet
and
do
this
pairing
manually
and
then
they
can
engage
in
serious
discovery.
So
it's
like
out
of
the
protocol
right
at
the
moment.
The.
A
K
Something
to
be
present
requires
them
to
have
kind
of
a
mental
model
that
they
may
not
have
yeah
and
oftentimes.
What
happens?
One
of
the
reasons
why
these
why
these
services
are
so
cool
because
people
discover
them
spontaneously,
so
you
I
think
you
want
to
somehow
preserve
the
spontaneous
discovery
while
not
violating
people's
privacy.
Yes,
so
that's
what
I'm
getting
yeah.
N
Please
check
them
out,
go
go
eda.
The
idea
is
that
you
do
the
felling
once
and
yes,
there
is
a
question
of
what
tree
girls
belly
and
clearly
because
me,
okay,
I
know
that
I'm
talk
to
you
later,
I
know
you're
here
I
say
we
should
bury
okay.
Then,
once
you
have
paired
you
get
in
the
room
knock.
There
are
50
people
in
this
room,
but
only
five
of
them
are
pairing
with
you.
N
So
in
the
first
stage
you
will
discover
all
the
50
people,
but
you'll
do
a
triage
by
checking
the
value
of
you
since
names.
You
say,
oh
only
that
one
as
a
magic
token
that
I
understand
so
you
get
at
that
point.
You
get
the
address
of
the
PI
server,
your
five
friends
and
then
then
for
those
ones
you
do
not
contact
them
using,
say,
DNS
or
Tara's
can
ask
the
vicar
Oddie
necessities
question
to
find
out
the
IP
address
and
the
airport
number
of
the
chat
room
that
they
want.
You.
K
A
Yeah,
it's
good
to
hear
that
so
I
think
one
of
the
other
concerns
is
the
compatibility
with
everything
else
we're
doing
here.
It
sounds
like
it's
something
that
can
just
bolt
on
as
a
optional
extra.
If
you
choose
to
use
it,
which
is
a
good
thing,
but
we
need
to
be
clear
that
that's
the
case
that
the
device
that
uses
to
use
that
benefits
from
it
and
it
doesn't
lose
out
in
discovering
other
things
potentially
but
well
secure.
A
R
L
J
I
Think
they
were
on
the
two
questions.
I
think
the
my
personal
belief
is
the
answer
is
yes,
but
the
day,
but
the
definition
of
we
should
be
different.
In
the
top
case,
the
we
refers
to
DNS
SD
working
group,
and
my
belief
is
yes,
the
Dean
SSD
working
groups,
the
MSSD
privacy,
absolutely
and
I
think
the
stress
is
good
starting
point
on
the
bottom.
I
One
I
think
the
answer
is
yes
for
a
different
definition
of
we
I
think
the
notion
of
pairing
dns
st,
is
not
the
only
protocol
with
this
problem
that
could
benefit
from
pairing.
I
believe
that
the
bottom,
while
the
answer
should
be
yes,
but
not
within
the
scope
of
the
dns
st
working
I,
I
I'm
peering
back
in
an
80s,
have.
K
A
K
K
Of
people
who
are
interested
so
from
my
perspective
as
a
matter
of
expediency
and
avoiding
creating
larger
schedules
for
I
TFS
in
the
future,
I
think
it
might
make
sense
for
the
area
directors
involves
to
ask
themselves
the
question:
would
it
be
efficient
to
do
it
in
here,
because
I
think
there
is
a
community
of
interest
here?
Okay,.
A
So
first
question
is
who's.
Read
this
draft,
it's
a
small
number
of
hands,
so
it
can
be
a
small
vote
then,
but
from
what
you've
heard
I
mean
you
can
get
a
feel
for
what
its
are
trying
to
do
and
and
how
it
may
work.
Who
here
would
be
in
favor
of
the
working
group
adopting
this
draft
modulo
where
the
pairing
work
is
done
in
favor
against
so
I
said:
you're,
just
taking
your
glasses
off
there.
E
A
I
think
that's
an
interesting
point,
but
I
mean
this
draft
started
off,
stating
a
problem
and
it's
sort
of
in
version.
01
expression,
00
version,
01.
It's
started,
taking
the
steps
into
solution
space,
so
I
guess
there's
a
question
for
ID
there
as
to
whether
he
would
prefer
that
we
adopted
the
bit.
That
stated
the
problem
and
published
that
and
then
continue
the
work
towards
a
solution.
Many
comments
there
or
do
we
do
it
all
in
one
document,
I'm.
A
So
I
think
the
coming
there
is
then
to
make
sure
that
the
requirements
and
the
problem
are
stated
clearly
in
the
draft
as
well
as
I
think
they
are
already
okay,
ralphs
checking
for
blue
sheets
okay.
So
we
will
take
that
for
confirmation
to
the
list
as
to
what
people
want
to
do
with
adopting
the
draft.
Thank
you
very
much
again.
So
we've
got
about
five
minutes
left.
A
A
It's
came
up
before,
hopefully,
it'll
come
up
again.
There
we
go
so
there's
all
the
drafts
that
we've
covered.
There
are
these
three,
the
left
I
think
we've
heard
about
some
hybrid
proxy
zero
comp
from
Ray,
and
that
will
have
to
take
that
fire
rainn
disgusted
Marcus
about
where
we
stand
with
that.
We've
got
two
other
drafts.
The
general
DNS
SD
threats
documents
is
parked.
Is
we're
not
going
to
ask
adopting
it?
There
are
outstanding
questions
from
a
couple
of
people
against
that
draft
on
the
list
of
not
being
answered.
A
So
once
the
authors
answer
those
questions
satisfactorily,
we
may
be
able
to
progress
that
so
do
check
the
list
for
that
thread
and
comment
on
it.
If
you
can
and
then
the
last
one
which
I
kind
of
probably
fits
in
somewhat
with
what
we
were
discussing
about
how
you
use
things
in
practice,
maybe
five
meetings
ago
we
had
a
draft
presented
on
how
you
might
optimize
the
queries
and
where
it's
most
effective,
to
do
query
filtering
whether
it's
on
the
client,
the
server
or
the
responses
you
received
back
to
the
client.
A
So
it
might
be
worth
revisiting
that
so
I'll
contact
the
author,
see
if
he's
still
interested
or
he
or
she
I,
don't
remember
in
revisiting
that
I
think
it
might
be
worth
doing
that
at
the
next
ITF
meeting
and
that
just
then
leaves
us
with
the
final
steps
of
next
steps.
Is
there
any
work
here
that
people
think
we
should
be
doing
that
we're
not
any
other
brilliant
ideas
for
what
we
should
be
doing?
I.
Think
it's
great
in
the
last
couple
of
meetings,
you've
taken
the
privacy
aspect
on
board.
That's
really
good!
A
Okay,
that's
kind
of
encouraging
I
think
there
is
the
potential
to
look
at
reach
our
turing
as
we
discussed
at
the
start,
but
I
think
there
are
some
clear
actions
at
the
moment
on
the
hybrid
proxy
and
on
the
dns
pushed,
but
I
think
we
should
finish
those
little
pieces
first
before
we
consider
recharging.
So
a
recharging
discussion
might
happen
at
the
next
ITF
meeting.
I
would,
I
would
guess.
D
A
First
one
is
that
the
well
we'll
get
the
harpy
proxy
update
done,
we'll
get
the
DNS
push
and
signalling
updates
done,
so
the
signaling
work
or
be
done
first,
as
that's
going
to
happen
really
quickly.
Once
that's
sorted,
you
can
then
go
and
update
the
dns
push
document
stripping
out
the
bits
that
have
moved
to
the
signaling
document.
Stewart
said
semantically.
It's
the
same.
Recent
changes
in
the
syntax
third
thing,
which
be
the
design
team,
formal
informal
to
look
at
the
usual
disk,
all
flat
home
net
problem
for
the
time
being.
A
I
think
we
all
know
what
we
mean
related
to
that
is
also
dns
updates
and
hybrid
proxy
coexisting
in
an
enterprise
or
canvas
environment.
So
I
think
Ted
is
currently
has
taken
that
all
on
himself.
We
need
to
get
some
help.
Whether
people
like
range,
do
it
and
others
may
be
willing.
That
would
be
great,
so
I
think
if
Ted
can
kick
off
the
discussion
on
the
list
again
and
call
for
help.
That
would
be
very
welcome.
A
Next
thing
was
thick.
The
guidance
draft
I
think
we've
had
a
good
discussion
there
and
got
some
ideas
thanks
to
ralphs
presentation.
I
would
point
you
also
to
Tom
mentioned
it.
He's
got
some
configuration
examples
in
a
draft
that
you
could
post
there's
a
link
to
that
in
the
chairs
slide.
So
if
you
look
back
in
fact
here
we
go.
A
So
if
you
look
at
the
chairs
slides
as
a
link
there
to
the
github
repository,
where
he's
draft
currently
sits,
it's
just
not
published
yet
so
I
think
it
expired
say,
have
a
have
a
look
at
that
or
Tom
can
repost
it
somehow.
So
we
can
all
have
a
look.
So
that's
more
than
configuration
side
rather
than
the
high
level
how
you
stitch
things
together,
which
is
the
sort
of
thing
that
ralph
was
talking
about.
A
If
we
take
it
out
of
here,
we
may
not
have
any
critical
mass
so
keeping
it
here,
maybe
the
best
thing
but
we'll
see
okay,
so
I
think
that's
it
any
any
final
things
anyone
wants
to
say:
if
not
we're
going
to
release
you,
okay,
yep.
Thank
you
much
for
coming
make
sure
the
blue
sheets
come
back
on
and
that
you
sign
them.
Oh
yeah,
we've
got
them.
Okay,
if
you've
not
signed
them
last
chance.
Thank
you.