►
From YouTube: IETF97-DNSSD-20161117-0930
Description
DNSSD meeting session at IETF97
2016/11/17 0930
A
A
A
We
can
yes,
so
again
a
few
of
the
info
pages.
So
if
you
have
the
slide
deck
there,
you
can
follow
those
terms
of
where
we
are
with
the
various
documents
that
the
working
groups
working
on.
We
obviously
have
the
requirements
document
that
was
published
some
time
ago
now,
dns
SD,
hybrid,
stewardess,
conley
applied
the
updates,
plus
a
couple
of
extra
ones
that
were
done
yesterday.
A
Are
things
are
actually
now
on
05,
rather
than
0
for
Stuart's,
just
going
to
very
briefly
present
on
that,
we
think
it's
done,
modulo
a
couple
of
comments
and
possible
thought
about
what
we're
actually
calling
this
and
Stuart
will
talk
about
that
shortly.
Otherwise,
we
expect
is
push
that
upward
towards
publication.
A
It
does
have
dependencies,
though,
on
DNS
push,
and
that
in
turn
has
a
dependency
on
the
DNS
op
work
on
the
signaling
DNS
signaling,
so
everything
all
of
those
I
think
would
have
to
be
published
together,
but
that
shouldn't
stop
us
starting
the
process
of
putting
things
before
the
OSG.
The
mdns
dns
interop
is
done.
We're
just
waiting
on
a
shepherd
right
up
for
that
for
that
to
go
to
the
rsg
view
that
will
be
quite
soon
there
and
then
the
other
two
pieces
of
work
that
we
have
that
we
will
be
hearing
about
today.
A
Other
work
on
dns
SD
privacy.
So
that's
now
been
split
into
two
documents
both
being
conducted
in
this
working
group,
so
the
sort
of
high-level
privacy
document
and
then
the
specific
document
on
head
pairing
works
for
the
privacy
protocol,
so
we've
looking
at
both
of
those
today.
Unfortunately,
christian
is
somewhere
in
a
plane
right
now
and
daniel
it's
three
a.m.
in
the
morning,
so
neither
of
them
could
present
so
either
myself
or
we
might
have
Ralph
presenting
remotely
for
that
one
just
to
see
if
it
I'll
see.
Ralph
is
now
on
me,
TECA
yeah
good.
A
So
that's
where
we
are
with
everything
things
are
progressing.
What
we
want
to
try
to
achieve
today,
first,
is
just
to
round
off
anything
left
with
a
hybrid
proxy
before
we
push
that
one
up
figure
out
also
what's
left
to
be
done
with
dns
push
and
to
get
an
update
on
where
we
are
with
dns
signaling,
as
I
said,
that's
being
taken
to
the
DNS
op
group,
so
we
have
close
collaboration
going
on
for
that,
one
that
was
presented
on
Monday
or
Tuesday.
You
know
tuesday,
I'm
not.
A
In
short,
it
is
today
sorry,
so
that
that's
progressing
or
here
a
little
lamb
summary
of
that
from
stuart
today
and
we'll
also
discuss
that
the
privacy
work,
so
we've
got
some
slides
from
christian
and
daniel
and
we'll
just
run
through
those
quickly.
We
also
have
Ted
giving
a
short
talk
on
his
ideas
for
stateful
multi-link
extensions
as
well.
A
I.
Think
if
you
have
time
at
the
end,
you
might
want
to
have
it
just
a
quick
review
of
where
we
are
with
the
milestones,
which
is,
as
with
many
working
groups
a
little
bit
behind,
but
you
should
have
a
look
at
those
and
consider
where
we
might
want
to
go
after
we've
done
the
work
that
you've
got
before
us
now:
okay,
so
agenda
bashing!
This
is
the
plan
for
today
we've
got
90
minutes.
Hopefully
we
can
keep
that
to
schedule.
So
any
points
about
the
agendas
have
you
unhappy
with
that?
C
D
E
E
We
had
a
bunch
of
changes
during
last
call.
I
was
a
bit
slow
making.
Those
updates
apologies
for
that.
My
attention
got
drawn
off
finishing
the
push
notification
document,
which
then
got
split
up
into
two
documents
with
the
session
signaling,
but
I
finally
made
all
the
efforts
all
the
updates
I
think
all
the
edits
have
been
made
for
the
comments
that
were
received,
and
that
is
now
done
so
next,
one.
E
E
In
continuing
are
developing
this,
we
have
run
into
an
interesting
new
use
case
and
I
want
to
describe
that.
The
way
the
hybrid
proxy
works
right
now
is
it's
a
proxy
on
the
network.
That
does
queries
on
your
behalf
and
it's
analogous
to
me
picking
up
the
phone
and
calling
you
and
saying
I'm,
not
at
the
office
right
now.
Can
you
bring
up
the
printer
browser
and
tell
me
what
you
see
and
you're
doing
a
query
on
my
behalf.
E
The
use
case
here
is
things
like
6lowpan
mesh
networks,
where
multicast
is
not
supported
in
a
reasonable
way,
and
the
hybrid
proxy
has
currently
defines
let's
those
nodes
on
the
mesh
use.
Unicast
queries
to
discover
what
services
are
available
say
on
your
home
Wi-Fi
network,
but
if
one
of
those
know
wants
to
offer
a
service,
then
you'd
be
nice
if
it
could
cause
the
network
and
say
I'm,
not
part
of
the
multicast
cloud
here.
But
can
you
advertise
the
service
on
my
behalf?
This
is
my
IP
address.
E
I'm,
reachable
by
unicast
I
just
can't
participate
in
multicast
and
we
will
be
writing
a
draft
to
describe
that.
It's
a
similar
kind
of
mechanism,
you
make
a
connection.
You
send
requests
the
proxy
advertisers
on
your
behalf.
What
I
realized
is
that
we
may
be
running
into
a
confusing
terminology
thing.
So
what
I'm
suggesting
is
we
call
the
current
thing,
the
discovery
proxy
and
we
call
the
new
thing
that
advertising
proxy
and
then
nobody
will
get
confused
I'm
raising
it
here,
because
we've
been
calling
this
hybrid
proxy
for
a
long
time.
E
A
B
B
F
E
E
With
the
details
of
how
you
subscribe
for
change
notifications-
and
I
agreed
with
that
analysis,
it
does
delay
things
a
little
bit,
but
we
agreed
to
split
it
out
into
two
documents
which
we
did
and
the
new
push
message
that
the
new
session
signaling
draft
describes
a
new
message
format
and
the
push
draft
has
been
rewritten
to
use
that
new
mechanism.
A
lot
of
the
stuff
about
session
lifetime
and
session
termination
has
been
moved
into
the
session
signaling
draft,
which
is
where
it
belongs.
So
this
is
clean.
E
E
In
the
two
weeks
since
that
was
submitted,
we've
been
working
on
implementing
the
new
stuff
and
I
realized
we
have
an
oversight
minor
thing
which
I'll
fix.
The
reconfirm
message
gives
the
name,
type
and
domain
that
the
receiver
is
disputing
the
validity
of
we
need
to
add
the
our
data,
because
the
the
receiver
needs
to
say,
which
particular
record
is
disputing.
E
If,
if
a
multi-homed
host
has
three
IP
addresses
and
what
is
not
reachable,
it's
only
that
one.
That's
in
question:
it's
not
all
of
the
addresses,
so
minor
oversight.
I
will
fix
that,
hopefully,
in
the
next
few
days
and
that
will
be
submitted
and
then
that
document
should
be
done
just
pending.
The
final
discussion
on
the
session
signaling,
which
is
the
next
thing
for
us
to
talk
about.
E
E
E
The
the
main
motivation
here
is
managing
long
long,
live
connections,
Sarah
and
I
have
been
talking
this
week
and
realized
that
that,
when
people
talk
about
long
live
connections,
there
are
a
couple
of
different
scenarios
which
are
not
exactly
the
same.
One
is
a
dns
server
doing
traditional
one-shot
queries
and
it
was
to
keep
the
connection
open
just
for
efficiency.
It's
done
a
query.
There
might
be
another
one
coming
in
a
couple
seconds.
It
saves
tearing
down
the
connection
making
you
want,
especially
when
TLS
is
used.
It
saves
the
TLS
set
up.
E
The
other
use
case
is
for
push
notifications,
which
we
care
about
where
you
want
to
keep
the
connection
up,
because
you
have
a
long
day
of
operation
running
and
you're
expecting
to
get
notifications
of
interesting
events.
That
is
not
just
an
idle
connection
that
you're
keeping
around
for
convenience.
It's
an
active
connection
that
you're
expecting
to
get
messages
on.
You
want
the
NAP
mappings
to
stay
live
so
that
you
actually
get
those
push
notifications
when
they
come.
E
Another
potentially
controversial
issue
in
the
session
signaling
document
is
that
array
are
particularly
advocated
for
a
truncated
header.
We
don't
need
the
num
questions,
gnome
answers,
no
more
thorities
number
additionals
because
they
don't
apply.
Other
people
have
argued
that
they
should
all
be
there
with
value
0,
because
it
makes
pausing
with
TCP
dump
easier,
raise
raising
his
hand.
E
A
C
C
If
we
don't
have
anything
for
those
extra
four
bytes
I'd
fill
them
up
with
anyway,
but
you
aren't
required
to
keep
them
as
councils.
They
can
be
anything
if
you
if
it
really
depends
on
what
the
op
code
is
going
to
do,
and
what
extra
stuff
you're
going
to
have
shoved
in
there.
If
it's
got
it
has
got
stuff
in
there
dude
normal
use.
They
don't
have
to
be
the
countess
or
stuff
like
that.
C
E
Yes,
it
does
so
it
sounds
like
we
have
some
editing
on
the
document.
To
do.
I
did
the
last
round
of
editing
on
this
document
and
it
sounds
like
a
may
have
misunderstood
the
opinions
that
other
people
were
expressing.
So
if
we
want
to
go
back
to
the
standard,
12
bite
header
and
there's
no
objection
to
that,
I
think
that
will
make
a
bunch
people
happy
and
maybe
remove
some
of
the
controversy
yeah.
C
E
C
E
E
C
C
G
Right
here,
yeah,
that's
not
bike,
shed
on
the
specific
details.
Now
we've
got
some
ideas
on
this
one
and
whatever
happens,
why
shot
will
need
updating?
So
it's
fairly
moved
whether
it's
done
after
insisting
header
or
defining
the
current
bites.
What
marks
just
said
about
than
even
be
a
minimum
12
bytes
in
any
DNS
packets?
It
was
a
new
one
on
me,
so
that's
why
we
have
to
take
into
account
anyway
right.
G
E
Good,
the
next,
like
yes,
next
slide.
So
this
is
a
question.
If
we
add
the
full-length
fills
back
in
then
the
details
of
this
question
change.
But
the
question
is
still
there,
but
as
currently
written
with
no
additional
records
section,
there
is
no
way
to
add
a
tea
sig
or
an
eating
at
zero
to
a
session.
Signaling
message
a
session
signaling
connection
over
TCP
can
carry
multiple
DNS
messages
back
to
back
and
a
normal
query
over
that
connection
can
include
arati
Sakura
eating
at
0
as
usual,
but
the
session
signaling
control
messages
themselves.
E
If
they
don't
have
additional
records,
then
they
can't
have
these
things
and
that
I
offer
as
an
open
question
to
the
community.
This
is
a
DNS
off
work
group
document,
so
it's
being
discussed
there.
If
anybody
here
has
any
opinions
on
this,
then
please
weigh
in
on
the
list.
There
is
no
arguments
that
we
don't
need
t
sick.
Why
would
you
ever
need
to
sign
the
keeper
lifetime?
And
maybe
that's
a
valid
argument,
there's
an
argument
that
we
don't
need
any
eating
at
zero,
because
none
of
the
eating
is
zero.
E
Things
apply
to
this
like
eating.
A
zero
has
to
keep
alive
option,
but
the
session
signaling
keep
alive
value,
supersedes
that
so
you
shouldn't
use
the
edenists
or
a
keepalive
option.
Hopefully
ever
once
session
signal
becomes
established,
and
that
argument
makes
sense,
except
this,
a
new
zero,
which
is
the
padding
option
which
is
used
for
padding
messages
to
a
constant
length
for
security
reasons
to
avoid
traffic
analysis.
E
E
We
define
the
corresponding
session
signaling
tlv
with
similar
semantics,
or
we
define
a
generic
way
of
carrying
any
eating
a
zero
option
with
a
little
asterisk
that
many
of
them
don't
apply
and
in
particular
eating
a
zero
keeper
like
must
not
be
used
because
it
would
conflict
with
session
segment
keep
alive.
So
this
is
another
open
question
I'm,
not
presenting
any
answers
here.
I'm
letting
people
know
that
this
is
an
issue
that
needs
to
be
answered
before
session.
Signaling
can
progress,
which
means
push
is
waiting
for
it,
which
means
discovery.
Property
is
waiting
for
it.
A
F
More
sorrow,
Dickinson
and
yep
Farah
Dickinson
there
is
apparently
there
is
another
concrete
use
case
for
this,
which
is
the
stub
to
recursive
use
case.
We
do
have
the
EDS
keep-alive
option
to
find
at
moment,
but
that
is
not
a
great
solution.
It
just
about
works,
but
because
of
the
year
there
are
semantics.
It
has
some
strange
characteristics.
I
see
this
as
completely
superseding
that
in
terms
of
collection,
management
or
TCP
and
TLS
in
particular,
okay.
H
Brick
with
mike
brick
Taylor,
this
is
just
a
general
comment
sort
of
following
on
from
your
from
the
previous
point
about
removing
the
additional
record
counts
and
the
query
counts.
I'm.
Moving
on
to
this,
isn't
there
a
general
danger
that
you're
sort
of
forking,
the
DNS
packet
format,
no
I,
think
if
the
signaling
is
part
of
DNS,
then
I
think
the
record
should
pretty
much
look
like
the
rest
of
it,
because
we
can't
predict
whether
someone's
going
to
say
actually
I
do
on
these
e
DNS
capabilities
within
the
other
mechanism.
H
I
think
from
an
implementer
point
of
view,
if
it's
just
an
extent,
it's
a
DNS
extension
effectively.
So
let's
make
it
look
like
the
rest
of
DNS
and
not
suddenly
slip
in
20.
Under
these
you
know
requests
or
session
establishment
messages.
Suddenly
he
doesn't
look
like
DNS
messages
for
the
rest
of
your
implementation.
You've
got
to
drop
into
a
whole
separate
code
path.
It's
just
a
gut
reaction
thing.
E
And
another
interesting
question
is
if
the
additional
record
count
is
there
for
the
purpose
of
allowing
ed
in
at
0
and
T
sig
TC
is
normally
the
last
thing
you
add
to
a
packet
because
you
sign
all
the
contents
of
the
packet,
but
in
this
structure
the
TL
v's
would
come
after
the
additional
records.
So
that's
a
little
NIT
that
we'd
have
to
think
about
is
if
we're
tacking
stuff
on
the
end
of
the
packet,
then
the
t
sick
is
no
longer
the
last
thing
in
the
packet.
E
Another
one
of
these
tricky
questions
because
the
hardest
questions
answer
the
ones
that
don't
really
matter
so
people
can
always
come
up
and
argue
both
sides
right
now.
The
session
signaling
document
says
every
request
must
be
matched
with
the
response,
even
if
the
responses
empty
and
really
has
no
meaning
are
right.
Now,
in
the
push
draft
it
says
that
change
notifications
from
the
server
to
the
client
don't
need
a
response,
because
there
really
is
no
response.
That
would
make
any
sense
right.
E
The
client
doesn't
get
to
say
yes
or
no,
whether
it
likes
the
update,
it's
just
it's
being
informed.
So
it's
a
coin
toss
I
if
I
had
an
opinion,
I'd
state
the
opinion,
but
I
really
don't
care
so
sending
back
an
empty
reply
is
wasting
a
few
bites.
On
the
other
hand,
TCP
is
going
to
send
an
ACK
anyway
and
if
you
don't
send
a
reply,
you're
going
to
wait
for
the
delayed
act
timer
to
fire
so
actually
giving
it
a
reply
to
send
might
make
the
TCP
stack
happier.
E
E
If
you
have
an
active
subscription
and
you
don't
lose
the
nap
mapping,
this
is
the
in
full
of
keeper
lives.
You
should
send
to
keep
the
connection
life
and
decoupling.
The
idle
timeout
from
the
keepalive
interval
seems
like
it's
a
good
idea,
because
they're
not
the
same
thing
and
right
now,
they're
described
as
if
they
were
the
same
thing.
Yeah.
I
Yeah
Bernie
volts
I
just
wanted
to
point
out
on
the
previous
slide
that
TCP
arguments
is
kind
of.
Not
because
again
the
reply
has
to
be
echoed
back,
you
know
has
to
be
act
and
stuff,
so
you're
really
not
winning
anything.
So
I'm
not
sure
that
now
you
know
I
would
remove
that
argument
because
it
doesn't
matter.
The
only
benefit
you
might
have
is
that
you
know
if
the
connection
has
gone
down,
not
getting
a
reply
might
give
you
know
if
the
client
is
expecting
a
timeout.
You
know
sensor.
I
C
I
E
I
Not
arguing
that
I'm
just
trying
to
explain
that
I,
don't
think
that
TCP
argument
has
any
water.
That's
all
I'm
trying
to
say
is
that
that
are
that
doesn't
make
any
difference.
The
only
benefit
you
have
by
sending
the
reply
is
that
it
I
could
have
a
short
time
out
time
for
that
right,
because
it
knows
it's
going
to
get
a
reply
back,
and
so
it
might
learn
that
the
connection
is
down
sooner
than
it
would
otherwise.
I
A
E
Yes,
I,
maybe
should
have
had
a
slide
listing
all
the
documents
that
I'm
implicitly
promising
get
more
than
one
are
snowballing
away.
They're
here
so
I've
been
working
on
these
three,
the
hybrid
to
push
the
session
signaling
and
that's
been
taking
up
a
lot
of
my
time.
The
things
that
I've
got
in
the
back
of
my
mind
to
explore
in
the
coming
weeks
and
months
before
the
next
idea
of
meeting
other
advertising
proxy
that
lets
a
remote
device
advertise.
There
is
also
the
thing
that
we've
talked
about
for
a
while,
which
is
the
discovery.
E
Proxy
right
now
is
sort
of
a
simplified
model
where
each
link
has
its
own
name
and
their
separate,
and
many
people
have
pointed
out
the
obvious
limitations
of
this
and
having
some
way
to
merge,
links
or
combine
them,
so
that
name,
conflicts
are
resolved
and
three
different
links
can
appear
as
one
from
the
users
point
of
view.
Yeah.
G
E
Would
be
a
good
thing.
This
is
like
a
Venn
diagram
with
overlapping
things,
because
the
advertising
proxy
could
actually
provide
potentially
a
tool
to
solve
that
other
problem,
because
if
you
have
conceptually
in
your
home,
you
have
sort
of
the
main
Wi-Fi
network
and
then
maybe
three
or
four
little
leaf
links
around
the
edge.
Those
could
all
be
considered
secondary
to
the
main
one.
They
could
use
the
advertising
proxy
so
that
all
services
in
your
home,
as
well
as
existing
wherever
they
exist.
E
They
also
request
a
remote
presence
on
the
quotes,
main
network
and
then
that
may
network
apparently
is
the
place
that
all
services
are
visible.
Any
name
conflicts
are
detected
and
resolved
on
that
main
Network.
One
discovery
proxy
on
that
name.
Net
main
network
then
serves
to
make
all
services
visible.
Now
it
does
give
you
kind
of
a
single
point
of
failure
that
your
main
network
has
got
to
be
up,
but
that
is
that
is
one
direction
here.
E
J
J
Stuart,
hey,
listen!
What
you
just
described
arm
sounds
like
moving
a
lot
of
spectrum
to
a
single,
a
single
centralized,
unicast
dns
server,
Hanlon
DNS
SD.
Do
you
have
you
know,
I
can
sort
of
see
what
the
advantages
are
one
way
or
the
other,
but
but
is
that?
Do
you
see
that
moving
along
a
spectrum
like
better.
E
Yes,
that
if
we
pursuit
this
to
its
logical
conclusion,
you're
absolutely
right
how
far
along
that
spectrum
we
will
go
in
reality
is
hard
for
me
to
predict,
because
many
years
ago,
I
was
hoping
that
DNS
update
to
a
centralized
server
would
be
a
widely
used
solution.
Right
and
I
guessed
wrong
kid.
It
has
not
turned
out
I
still
don't
have
a
single
printer
or
network
camera
or
any
other
device
that
has
a
DNS
update,
client
in
it.
For
whatever
reason
those
vendors
were
okay
with
multicast
DNS.
E
Some
of
the
people
have
been
talking
to
this
week
have
heard
the
story.
I
just
bought
a
new
house
and
moved
into
the
house
and
bought
a
bunch
of
stuff
like
you
do
and
I've
been
shocked.
My
my
the
pool
controller
has
a
Wi-Fi
interface
with
Bonjour.
The
solar
panels
have
inverters
that
have
got
a
Wi-Fi,
but
they've
got
a
web
UI
advertise
with
Bonjour
the
Sony
amplifier,
the
blu-ray
player,
the
yamaha
r
amplifier,
the
new
printer.
That's
not
a
surprise.
All
printers
have
Bonjour
just
the
amount
of
stuff
in
my
house,
the
thermostats.
E
J
A
E
That's
right
next
to
be
on
this
side,
because
I'm
right
at
the
edge
of
a
boundary,
so
some
kind
of
sliding
window
model
yeah,
where
I
just
go
for
where
I
am
and
11
segment
down
the
corridor.
That
way,
and
one
second
upper
corridor
that
way
and
then,
as
you
move
around
you've,
got
this
sliding
window
of
three,
and
that
would
be
something
I'm
trying
to
think
of
the
right
term
sort
of
like
it's
like
the
discovery,
hybrid
proxy,
but
I'd
call
it
an
aggregating
proxy.
E
It's
kind
of
it's
one
level
up
we're
with
the
discovery.
Props
your
hybrid
proxy,
now
we're
talking
about
when
you
send
a
query
to
it,
it
does
it
by
multicast
on
the
local
network.
This
would
be
a
similar
concept
where,
when
you
do
a
discovery
to
it,
it
knows
which
three
other
discovery
proxies
to
talk
to,
and
then
it
aggregates
those
three
into
one
result
which
it
gives
back
to
the
client.
So
that
would
save
the
client
doing
three
separate
queries
to
three
different
properties.
A
There
may
be
a
similar
thing
there,
for
example,
and
on
our
campus.
We
have
on
the
wireless
there's,
VLAN
pooling
happens
so
you're
in
a
different
subnet
to
the
person
stood
next
to
you
can't
do
bonjour
to
the
device
to
the
person
stood
right
next
to
you,
because
they're
in
a
different
subnet,
because
of
the
way
the
wireless
LAN
controller
provisions,
the
network.
So
there's
other
thing.
A
J
Man
I'm
taking
that
and
do
Stewart
I'm,
not
convinced
it,
but
I
am
convinced
that
what
you're
talking
about
is,
let's
say,
they're
sort
of
what
we
talked
about
at
the
last
ITF
meeting.
There
are
lots
of
opportunities
for
taking
these
building
blocks
and
putting
them
together
in
clever
ways
and
now
with
the
advertising
proxy
concept.
That's
that's
another
dimension
for
putting
things
together.
Cleverly.
A
So
I
think
we
did
discuss
it
in
Berlin
that
well
Ralph
presented
some
thoughts
towards
a
document
that
he
and
Tom
have
said
they
may
produce
soon,
which
would
be
sort
of
the
usage
guidelines
for
how
you
deploy
this
stuff
in
a
campus
type
environment,
enterprise
environment.
So
some
of
these
things
are
going
to
drop
out
of
that
I
think
yeah.
E
J
J
The
mechanism
you
just
described
I
think
might
also
have
some
advantages
in
terms
of
configuration
administration,
it's
more
centrally
configured.
Your
only
you're
only
doing
that
definition
of
the
overlapping
circles
in
the
Venn
diagram
in
one
place,
rather
than
trying
to
configure
it
specifically
to
a
bunch
of
clients
and
a
point,
but
the
individual
clients
in
a
bunch
of
different
places.
Right.
E
E
All
the
clients
talk
to
that
server
and
the
queries
they
send
may
serve
to
tailor
the
responses
they
get
and
that
big
iron
server
may
be
talking
to
your
hundred
discovery
proxies
yes,
spread
across
the
links
of
your
network,
but
it
is
the
only
thing
directly
talking
to
those
discovery.
Proxes
those
nice.
E
J
I
apologized
everybody
else
in
the
group
of
trying
to
engineer
this
on
the
fly.
The
other
thing
that
comes
up
comes
to
mind
is
a
very
low,
pragmatic
level.
I
think
there
are
some
difficulties
in
reconfiguring
the
list
of
search
domains
in
the
Bonjour
client
dynamically.
As
the
host
moves
from
from
from
point
to
point
in
the
network,
this
might
I
might
add
a
little
new
direction
to
avoid
that
problem.
A
Okay,
let's
sum
I
think
the
way
time
is
at
the
moment
now
we
take.
That
is
I,
think
it's
like
it
would
be
useful.
Clearly,
this
BCP
thing
would
be
a
useful
document
to
try
and
move
forward.
So
if
there's
potentially
one
or
two
authors
in
the
room
that
can
help
Ralph
and
and
Tom,
that
would
be
great
OPP
siege
to
it
has
a
list
of
his
own
I.
A
H
Taylor
again
very
quick
point:
there's
another
use
case
for
the
advertising
proxy,
which
I'm
not
sure
we
mentioned
have
been
talking
about
campuses,
but
actually
there's
a
containerization
use
case
here,
where
you've
got
a
composite
device
which
creates
containers
for
third-party
applications,
and
the
third
party
applications
can
think
that
there's
an
advertising
proxy
there.
That
is
actually
advertising
out
across
the
network,
but
actually
it's
a
proxy
for
that
container.
That's
then
up
revving
the
advertisement
out
to
the
external
advertiser.
H
A
Alright,
thank
you
very
much
Stewart,
so
Ralph
used
to
wear
I
think
you
think
you
may
need
to
come
back
to
the
microphone
q
Ralph
for
the
next
thing,
the
you
privacy
stuff,
Wow
year.
We
go
ok,
so
we
move
on
now
to
the
dns
st
privacy
workers,
as
a
situation
has
precluded
either
christian
or
daniel.
From
talking
about
christian,
we
had
a
great
plan
and
then
we
realized
it
was
actually
the
wrong
day.
A
A
J
A
A
J
A
Herring
draft
we've
got
about
four
hands
as
well.
I
mean
I've,
obviously
read
both
so
Ralph
as
well.
So
we've
got
about
six
people
in
the
room
that
have
read
these
so
yeah
I
guess
you
might
need
to
say
a
little
bit
more
background
other.
Otherwise,
then,
because
other
people
went
to
read,
it
may
be
okay
anyway,
so
yeah
I've
just
moved
on
to
slide
one
I
guess
you
can
see
this
yeah
guys.
J
So,
what's
the
big
picture
here
is
Tim,
make
sure
I
get
this
right.
The
there's
a
decision
to
take
the
one
document
for
doing
DNS,
SD
privacy
and
split
it
into
two
documents:
keeping
data
SSD
privacy
as
one
document
and
then
the
pairing
as
a
second
document.
So
now
we're
at
two
I.
Don't
think
we
could
done
that.
That
last
time
had
we
know.
A
J
That's
not
happened,
so
the
pns
SD
privacy,
just
to
review
quickly,
is
motivated
by
the
fact
that
that
dns,
SD
generally
and
especially
on
multicast
DNS,
has
some
real
privacy
issue.
It
exposes
a
lot
of
information
about
hosts
on
a
on
a
network
and
this
this
technology
from
Cristiano
Daniel
is
an
attempt
to
hide
as
much
of
that
information
as
possible
from
exposure.
J
J
Is
a
basically
a
two-step
solution?
First
of
all,
a
client
that
wants
to
do
some
dns
sdd
queries
asks
on
the
network
for
all
of
the
other
devices
that
are
willing
to
do
private
discovery
service.
The
client
then
picks
the
devices
then
picks
the
appropriate
keys
for
doing
the
pairwise
private
discovery
with
all
those
other
devices
that
it
has
previously
paired
with
it
can
use
the
the
privacy
service
with
this
mechanism
doesn't
address
sort
of
sort
of
general
privacy.
If,
if
a
client
chooses
to
do.
J
J
To
do
n
times
n
amount
of
work
to
discover
which
devices
to
compare
with
and
there's
a
suggestion
to
scale
this
back,
so
that
the
this
computation
only
has
to
be
done
once
every
five
minutes
so
that,
rather
than
for
each
discovery,
getting
a
new
nods,
the
I've
got
this
right.
The
the
knots
the
servers
can
re-add
verte
eyes
using
the
same
knots
on
a
with
a
five
minute
interval
that
way
that
the
client
device
doesn't
have
to
do
the
recomputation.
J
A
J
A
Think
he
was
going
to
raise
in
this
security
area
group,
so
we
have
Christian,
has
put
these
both
of
these
drafts
to
the
security
area
group
asking
for
feedback
that
he's
got
none
yet
so
I've
had
a
discussion
with
Steven
Farrell
yesterday
and
he's
going
to
fire.
Someone
else
find
someone
to
do
in
a
more
formal
review
of
this
at
an
early
stage,
rather
than
waiting
both
doctors
to
get
the
isg
and
then
have
that
we're
going
to
try
and
get
some
feedback
on
that
just
this
type
of
thing
sooner
rather
than
later.
A
Okay,
but
yes,
clearly
I,
don't
whether
anyone
in
the
room
here
has
any
feel
on
this
as
to
whether
these
type
of
optimizations
are
of
interest
or
the
approaches
that
it's
going
to
be
a
problem.
If
you've
got
quite
a
large
scale,
number
of
devices
of
doing
a
large
number
of
services
I
mean
you
could
imagine
if
this
type
of
thing
caught
on
and
you're
on
a
campus
with
a
lot
of
pairings
between
devices,
they
are
possibly
yeah.
J
A
Nobody
is
dashing
to
the
mic
at
the
moment,
but
I
think
we
do
need
to
get
this
out
there
in
sag
to
actually
get
some
discussion
going
there.
We
did
have
the
discussion,
obviously
after
Berlin
as
to
where
this
work
would
be
done.
The
trade-off
is,
if
we
do
it
here.
At
least
there
should
be
more
interest
or
theory
here.
A
If
we
did
take
it
to
suck,
then
there
would
probably
be
less
interest,
as
witnessed
by
the
fact
that
no
one's
commented
on
it
yeah
all
right,
so
we
do
need
to
no
pun
intended
push
that
to
get
more
review
of
this
work,
because
it's
a
interesting
be
important
and
we
need
to
get
some
early
comment
as
to
whether
the
direction
it's
heading
in
is
is
good
seems
so,
but
some
more
expert
review
would
be
great.
It's
a
microphone
comment
here.
Oh
this.
K
Is
a
high
office
is
heading
for
Tony
I
via
I
haven't
followed
means
not
about,
but
one
or
things
that
has
usually
doomed.
These
type
of
efforts
is,
or
two
of
them
are
configuration
complexity,
both
implementation
kind
of
complexity,
what
it
takes
from
implementer-
and
this
does
seem
to
be
something
which
require
somebody
to
taking
a
substantial
amount
of
crypto
to
good
light,
at
least
and
the
second
one
which
is
probably
more
worrisome,
is
how
much
pre
configuration
do
you
need
on
behalf
of
all
participants,
because
man,
if
you
think
of
a
campus.
K
A
A
J
A
J
In
doing
that,
pairing
step
and
exactly
as
Tim
suggests
it's
it's
incremental.
It's
look.
It's
like
adding
up
names
of
printers
in
your
room,
available
printers
in
jerz,
your
your
members,
you
don't
have
google
all
over
the
printers
of
amazon
once
you
can
walk
up
to
a
lot
of
to
pair
with
errors
unlimited
as
haunted
eight.
A
Yeah
and
the
pairing
document
describes
methods
of
doing
that
online
or
even
via
QR
codes.
So
there
are
different
ways
that
could
be
done
again.
I
think
that's
where
Christian
wants
feedback
fairly
early
on
as
to
which
of
these
approaches
make
sense
and
what
the
practical
issues
are
with
actually
deploying
them
again.
So.
K
A
A
J
J
On
this,
these
slides
describe
the
increment.
What's
happened
in
this
document
since
the
breloom
meeting
and
and
basically
the
the
the
pairing
process
is
for
two
devices
to
decide
they
want
to
pair
they
exchange,
they
exchange
the
keys
and
then
confirm
that
they've
actually
exchanged
the
keys
that
they
thought
they
exchanged
and.
J
So
this
is
tim
pointed
out.
This
is
an
incremental
process.
It
can
be
done
pairwise
between
between
devices
as
needed.
You
don't
have
to
go
through
in
set
up
Perry
all
the
devices
you
ever
want
to
you'll
ever
want
to
pair
with
all
at
once.
You
can,
you
can
just
add
additional
pairings
on
yeah
as
time
goes
on,
although
there
is
in
the
kind
of
scenario
that
that
heading
point
out,
there
will
be
scaling
issues
on
the
part
of
the
the
devices
that
are
providing
the
services.
A
J
Side
another
example
that
is
in
one
of
the
documents
is
those
of
us
who
carry
multiple
devices
around
that
are
communicating
through
a
public
network
right.
If
I've
got
both
the
a
Wi-Fi
enabled
phone
and
a
laptop
and
a
tablet
and
they're
communicating
across
the
cross,
a
public
Wi-Fi
I
can
pre
I,
compare
those
things
up,
pairwise
once
and
then
the
matter
which
public
Wi-Fi
I
get
connected
to.
They
will
be
doing
private
discovery,
privacy
to
enable
discovery
amongst
themselves
and
I,
don't
have
to
I.
Don't
have
to
do
that.
J
J
So,
just
as
with
the
other
one
I
think
these
document,
the
other
documents
I,
think
these
documents
are
baked.
Well
enough
that
I
want
to
encourage
the
the
working
group
to
take
a
close
read
and
if
we
can
encourage
through
stephen,
to
get
the
security
walks
to
take
a
look
at
it.
That
would
be
great.
A
J
Then
lets
me
sad
last
slide,
we'll
go
to
the
next
one
right.
So
there's
that
so
this
is
it's!
It's
a
DNS
SD
adopted
document
some
next
steps,
as
I
just
asked
for
review
and
feedback.
There
needs
to
be
a
decision
about
the
design
and
implementation
of
the
TLS
extension
and
implementation
experience.
If
we
can
get
that
feedback
from
security,
we
can
get
the
implementation
experience.
We
should
be
able
to
move
this
forward
and
have
a
working
request.
Call
at
the
next
IETF
needing
and.
A
So
I,
my
understanding
is
that
daniel
has
been
implementing
I'm,
see
all
parts
of
this
within
a
project.
So
if
anyone
else
is
interested
in
implementing
this
as
well,
that
would
be
fantastic,
but
we
will
certainly
have
feedback
from
Daniels
implementations
by
Chicago
next
I.
Think:
okay,
that's
it
ok,
Ralph
I'm,
just
curious!
You
sat
in
front
of
all
your
patents
is
that
what's
on
the
water.
J
D
L
A
L
Great
perfect,
you
get
there
thanks,
so
the
hybrid
proxy
solution
is
a
great
solution
in
the
sense
that
it's
stateless,
easy
to
implement
and
so
forth,
but
it
also
isn't
DNS.
Really,
there
are
things
the
DNS
does
that
the
hybrid
proxy
model
can't
do,
and
so
the
motivation
here
is
to
come
up
with
a
proposal
for
how
to
actually
support
DNS
fully.
L
Goals
extend
en
SSD
hybrid,
don't
invent
something
new
I.
It
would
be
nice
to
be
able
to
populate
DNS
zones
using
service,
scurry
announcements,
support
standard,
DNS
protocol
infrastructure,
make
service
discovery,
announcements
more
secure,
because
right
now,
they're,
not
at
all
secure,
provide
a
means
of
announcing
services
for
devices
that
don't
support
multicast.
L
This
is
something
that
Stuart
talked
about,
and
you
know
this
may
be
the
right
way
to
do
that,
or
there
may
be
some
better
way
to
do
that,
but
and
then
eliminate
the
need
for
regular
multicast
queries
on
networks
for
multicast
is
expensive.
You
know
Wi-Fi
next
slide,
so,
unfortunately,
this
is
actually
a
hard
problem
and
the
end
state,
where
we're
not
doing
multicast
a
lot
requires
that
pretty
much
every
device
its
advertising
service
on
your
network
implement
the
new
way
of
doing
service
advertising.
L
Obviously,
it's
more
me:
it's
more
work
to
maintain
state
and
keep
the
state
accurate
than
it
is
to
just
cash
and
allow
the
stuff
in
the
cash
to
expire.
Naturally,
it's
not
a
huge
amount,
more
work,
but
it's
definitely
more
bookkeeping
and
you
have
to
be
more
careful
to
be
correct.
So
the
idea
there
I
guess
I
didn't
really
explain
the
idea
there
is
that
that
essentially
you're
doing
when
you,
when
you
do
dns
service
discovery,
you
store
the
information
in
a
DNS
zone.
L
So
another
disadvantages
approach.
You
know
if
you
want
stable,
naming
an
infrastructure,
that's
great,
but
if
you
don't,
this
is
extra
work.
So
not
everybody's
going
to
want
this,
and
in
order
to
use
the
mdns
style,
trust
model
of
trusting
whatever's
on
the
link
you
need
to
have
forwarders
on
each
link.
L
L
L
So
why
do
it
be
nice
to
be
able
to
have
real
DNS
to
be
able
to
publish
things
in
the
DNS
that
can
be
reached
globally
when,
when
the
information
is
useful
globally,
obviously
don't
want
to
publish
things
globally
if
the
information
is
not
useful
globally
or
if
it
would
be
a
privacy
problem
to
publish
it
globally,
it
probably
makes
a
lot
of
sense
in
some
managed
networks.
It
has
the
potential
to
be
more
secure
than
mdns
hybrid
and
it
does
support
all
ends
with
the
don't
support.
Multicast
next
slide.
L
So
the
I'm
not
going
to
go
into
huge
detail
about
this.
If
you're,
if
you're
interested
in
this
work,
I
did
write
a
draft,
the
draft
is
pretty
sketchy
right
now,
but
it
covers
this
in
a
lot
more
detail,
but
just
to
cover
it
in
a
little
bit
of
detail
to
serve
the.
What
how
this
works
is
that
services
need
to
go
out
and
look
and
see
if
they're
on
a
stateful
ml
DNS
SD
network.
If
they
are,
they
do
registration
using
DNS
updates
with
60.
If
they're,
not,
then
they
just
do
the
NSS
d.
L
Let's
see
if
you
have
a
device
providing
service
on
your
network
that
only
provides
mdns,
it
still
has
to
be
discovered
using
hybrid
proxy,
and
then
you
know,
zones
are
populated
using
both
methods.
So
if
you
have
devices
that
are
doing
NS
update
and
that's
how
they
populate
the
zone,
otherwise
the
zone
is
populated
using
you
know,
by
discovering
things
through
mdns,
which
means
that
the
zone
probably
won't
contain
every
service
on
your
network,
only
the
ones
that
someone's
tried
to
discover
or
for
which
we've
seen
announcements.
L
L
How
to
do
the
update
process
is
that
it's
really
kind
of
a
pain
in
the
ass
and
it
might
be
better
to
just
do
you
know
some
kind
of
HTTPS
transaction
to
do
the
update,
rather
than
rather
than
doing
like
5,
dns
updates
with
dependencies
and
60
and
all
that
stuff.
So
that's
that's
the
basic,
the
basic
pitch
I'm
curious
to
know
what
people
think
about
this.
If
everybody
thinks
this
is
a
crazy
idea
or
if
anybody
thinks
it
might
be
useful.
Okay,.
A
Thanks
Ted,
so
yeah
I
mean
I,
know.
What's
true,
it's
about
to
say,
but
I
think
he's
made
it
clear
earlier
in
terms
of
the
vendors
are
doing
and
or
not
doing
with
the
NSF
tatum
devices
so
got
time
to
little
bit
of
discussion
Stuart's
at
the
mic.
If
anyone
wants
to
come
in
on
me
check
out
just
press
your
indie
hand-raising
button
and
you're
free
to
come
in
so
Stuart
fast,
I,
actually.
E
Came
to
the
mic
just
to
make
a
very
quick
comment
that
I
agree
with
you
that
the
DNS
update
stuff
does
seem
like
a
pain
in
the
ass.
We
used
that
for
back
to
my
Mac
like
eight
nine
years
ago,
and
yes,
it
is
very
complicated-
are
trying
to
combine
all
the
updates
into
something
that
is
efficient
are,
and
we
actually
never
did
that.
So
it
ends
up
just
being
a
bunch
of
separate
updates
which
is
not
efficient
at
the
prerequisite,
so
that
you
fail.
E
If
someone
else
already
has
that
name
are
complicated,
and
it
is
interesting
that
overall,
the
20
or
30
or
50
dynamic,
dns
services
that
are
available
on
the
Internet
I,
don't
know
a
single
one
that
uses
DNS
update
yep.
They
all
basically
have
a
web
UI
that
you
fill
in
username,
password
and
IP
address,
and
then
they
have
clients
that
effectively
reverse-engineered
the
web
UI
and
pretend
to
be
a
client
filling
in
username
password
an
IP
address.
So
that
does
seem
to
be
a
large
precedent
here
for
just
doing
it
over
HTTPS.
L
L
A
L
A
K
I
I'm
still
confused
as
to
what
the
practical
use
cases
would
be,
because
that
would
determine
to
some
extent
also
as
to
what
roulette
mechanism
is.
So
in
many
cases,
kind
of
thing
coyote,
since
this
seems
to
be
kind
of
rethink
to
think
about
these
days,
is
what
you
have
devices
in
a
home
that
need
to
communicate
what
somebody
else
you
would
probably
not
my
putting
it
in
DNS
somewhere
is
probably
not
going
to
help
you
because
right,
which
domain
name
would
I
put
it
under
usefully
dot,
hein
yeah
yeah.
Please.
A
K
L
L
That
is,
if
you
is,
if
you
either
actually
has
two
ways
to
do
it,
one
is
you
can
just
have
the
hybrid
dns
proxy
reachable
from
the
outside,
which
I
think
is
a
little
bit
dangerous
because
the
device,
that's
answering
those
queries,
isn't
visit
a
high
powered
device
and
be
really
easy
to
do
s
it.
The
other
option
is
to
is
to
have
a
zone,
and
maybe
actually
second
have
a
have
the
zone
that
you
are
updating,
be
a
hidden
primary
that
is
secondary
to
some
service
outside.
L
K
This
could
potentially
be
of
a
shop
blade
that
is
headed
towards
you
know
your
foot,
given
that
discoverability
in
the
iot
space
is
showed
on,
and
all
of
that
is
certainly
a
contributor
problems
that
were
seeing
where
people
inadvertently
much
bender
is
inadvertently
disclosed
stuff
that
they
probably
shouldn't
be
giving
the
security
state
devices.
Certainly.
L
E
Just
came
back
to
answer
Tim's
question
or
implied
question
I
thanks
for
doing
this
worked
at
I
think
this
is
interesting,
you're
right.
It
is
kind
of
preliminary
at
this
stage,
but
I
think
it's
a
good
area
to
explore.
So
and
then
it
will
talk
about
adopting
work,
move
document
at
this
stage,
but
I'm
I'd
be
happy
to
work
with
you
more
on
this.
We
can
get
together
and
chat
about
our
phone
calls
because
I
think
there's
a
bunch
of
interesting
stuff
to
explore
here.
I'll.
E
A
H
A
Okay,
good
so
right,
okay,
so
I
think
there
are
a
couple
of
things
just
to
look
at
before
you
wrap
more
three
things.
One
is
just
a
quick
review
of
where
he
might
be
with
other
drafts.
Second
thing
was
looking
at
our
milestones
and
the
third
thing
was
just
recapping:
the
outcomes
that
we've
got
from
today.
A
So
the
first
one
of
the
other
drafts
that
are
out
there
is
as
Tom
and
Ralph
were
we're
working
together
on
the
idea
of
a
BCPs
to
it
puts
it
for
using
this
technology
in
a
large
campus
stroke,
enterprise,
environment,
I.
Think
that's
going
to
be
a
very
important
thing.
Tom
has
written
a
draft
which
is
more
about
configuration
rather
than
deployment
and
operation.
A
Maybe,
but
if
we
can
bring
all
those
things
together
in
a
draft
that'd
be
great
so
again,
if
we,
if
there's
one
or
two
people
out
here,
who
would
like
to
help
Tom
and
Ralph
with
that
I
think
that
would
be
timely.
I
mean
the
other
thing
from
what
Ted
was
saying.
There
is
maybe
what
you're
hinting
at.
There
is
a
similar
type
of
thing
for
a
home
network.
How
you
actually
make
this
work
what's
putting
together
what
bits
might
be
missing
in
from
a
practical
point
of
view?
Maybe
that's
what
we're
looking
for?
A
There
was
a
DA
SSD
fret
document
that
hasn't
been
updated.
Now
for
more
than
six
months
there,
the
author
hosny
hasn't
really
answered
the
open
questions
that
were,
but
they
I
think
Andrew.
Sullivan
are
some
very
good
questions.
Those
haven't
been
answered,
so
I
think.
As
far
as
Ralph
and
I
are
concerned,
that's
parked
pending
those
questions
being
answered.
There's
the
hybrid
proxy
zeroconf
or
maybe
know
that
this
discovery,
foxy
zeroconf
over
in
the
home
networking
group,
so
Ralph
and
I
will
have
a
check
with
Marcus
to
see
where
we
are
with
that.
A
A
A
So
what
we
have
here
in
so
the
lq
is
no
longer
really
called
llq
that
we're
working
on
I
think
we
have
probably
parked
the
threat
model
document
longer
queries
has
become
DNS
push
new
company,
Jocasta
NS
problems
and
challenges.
I
think
that
was
really
the
focus
of
that
was
the
label
interop
which
which
we
got
done.
A
The
white
area
service
discovery
solution,
draftees
Howard
pops,
your
discovery
proxy
now,
so
we're
very
close
with
that,
and
the
implementation
draft
I
think
was
the
guidance
on
how
to
use
it
so
that
stuff's
kind
of
there,
but
I
think
the
things
that
we're
picking
up
potentially
is
additional
additional
items.
Now
one
would
be
the
advertisement
proxy
that
Stuart
talked
about.
The
second
would
be
the
we
called
it
in
the
past,
the
stitching
document,
which
is
about
how
you
bring
together
multiple
links,
for
example
in
the
home
network
case,
and
deal
with
that.
A
Then
we've
got
ya
the
the
bcp
for
campus
stroke
enterprise
we've
got
the
the
home
thing
that
Ted
spoke
to
as
well,
so
there's
there's,
certainly
future
things
that
we
could
put
into
the
milestones
then
does
that
all
seem
reasonable
things?
We've
measurements
a
few
nodding
heads
there
so
Ralph
and
I
will
have
a
chat
with
Terry
about
that
about
updating
the
a
nice
thing.
Now
with
the
tools
team,
you
do
a
fantastic
job.
A
This
part
of
the
edit
edit
button
now
for
the
working
group
you
can
just
put
in
a
list
of
suggested
milestones
and
click
submit
for
review.
I
think
so
it's
a
nice
interface
for
the
chairs.
Now
to
do
that,
and
so
we'll
look
at
that,
I
think
I
think
everything
makes
sense,
I,
don't
think
we're
not
hugely
behind.
A
I
think
there's
good
reasons
for
things
having
involved
the
way
that
they
have
and
also
spitting
out,
some
of
the
work
to
dns
or
we've
obviously
also
got
to
get
some
review
by
security
area
on
some
of
I.
Think
in
general,
we're:
okay,
okay!
Is
there
any
other
business?
Anyone
wants
to
raise
any
other
comments.
We've
got
eight
minutes
left
I
just
want
to
do
a
quick
recap
as
well
of
the
outcomes.
We're
all
happy
good.
B
What
I
was
going,
oh,
oh,
what
I
was
going
to
say
about
the
session
signaling
document
is
we'll.
Do
some
updates
but
I'm
hoping
to
get
like
a
working
group.
Last
call
out
of
Dina
stop
by
early
part
of
next
year,
like
by
January
sort
of
thing,
so
figure
to
use
the
next
month
and
a
half
to
sort
of
sort
out
the
edits
and
get
that
moving
sort
of
thing.
So
yeah.
A
Push
that
by
mid-december
it'll
disappear
to
exact
into
January
great,
so
yeah,
that's
certainly
one
one
outcome.
We
have
also
the
unanimous
view
of
the
room
to
change
hybrid
proxy
to
discovery
proxy
book
or
to
run
that
by
the
list
as
well.
Otherwise,
when's
do
it.
Does
the
the
publication
of
06
that
will
have
a
new
name
in
the
title.
A
Third
thing:
DNS
push
we're
going
to
move
towards,
completing
that,
and
probably
a
working
group
last
call
on
that
soon
as
well,
and
the
signaling
draft
you've
just
heard
about.
We've
got
a
couple
of
open
questions
to
resolve
them
and
move
on
with
that
privacy
in
pairing.
It
looks
like
we're
going
to
be
in
a
good
position,
with
some
implementations
from
Daniel
to
review
those
come
IHF
98.
A
There's
some
decisions
to
be
made
there
as
to
whether
the
communications
are
using
TLS
are
going
to
be
done
as
a
TLS
extension
or
as
application
specific
thing
that
needs
some
review
by
the
TLS
experts.
The
whole
thing
needs
to
move
you
by
security
area
on
Ted's
work.
I
think
we've
all
agreed
it's
it's
very
useful
and
we're
very
pleased
that
Ted's
documented
it
and
we
will
have
ongoing
discussions
about
how
we
move
that
forward
on
the
bcp
for
campus
and
enterprise.