►
From YouTube: IETF105-DNSSD-20190725-1330
Description
DNSSD meeting session at IETF105
2019/07/25 1330
https://datatracker.ietf.org/meeting/105/proceedings/
B
B
B
The
blue
sheets
are
going
around,
please
make
sure
you
sign
them,
so
it
is
Thursday
afternoon.
Hopefully,
you've
seen
the
note
well
bye.
Now
this
meeting
is
covered
by
the
IETF
note.
Well,
if
you
have
not
read
it
yet,
please
do
so.
It
covers
things
such
as
patents
and
what
your
responsibilities
are
in
the
ITF
and
also,
very
importantly,
the
code
of
conduct
with
which
this
meeting
is
going
to
run
so
usual
reminders
anytime.
You
talk
at
the
mic,
please
state
your
name
clearly
for
the
minute
taker
and
please
review
the
documents
that
happen.
B
B
Saw
your
email,
this
is
so
more
useful
links
for
people
still
following
online
yeah,
quick
usual
shout
out.
We
have
a
github
organization
for
the
working
group
and
anyone
working
on
a
draft
in
the
working
group
or
that
wants
to
be
in
the
working
group
is
welcome
to
set
it
up.
There
just
talk
to
us
and
we
can
make
it
happen.
B
Our
goals
for
today
we're
gonna,
have
an
update
on
our
currently
active
documents,
both
in
terms
of
standardization
and
actual
running
code,
and
then
we're
going
to
talk
about
discs
about
service
registration
and
discovery
relay
and
we're
gonna
have
fill
up
the
rest
of
the
lot
of
time
with
the
future
of
this
working
group
and
the
privacy
efforts
and
what
we
want
to
go.
So
that's
the
agenda
is
currently
stated.
Would
anyone
like
to
bash
the
agenda.
D
This
is
an
update
on
our
push
notifications
document.
We
discussed
this
at
the
last
IETF
meeting,
we're
on
version
19.
We
had
working
group
last
call
to
review
that
that
went
smoothly.
David
requested
publication
when
I
actually
review
last
call.
We
got
some
feedback,
we
made
some
updates
and
that's
what
I'm
gonna
give
a
quick
overview
of
right.
C
E
E
D
D
There
was
also
a
mismatch
in
the
documents
late
in
the
process.
The
DNS
stateful
operation,
RFC
added
some
explicit
text
about
when
TLS
early
data
is
permitted
and
when
it's
not
because
there
can
be
risks
with
replay,
so
you
only
want
to
use
it
for
idempotent
operations
and
there
is
a
requirement
in
DSO
that
you
state
which
DSA
operations
were
allowed
in
the
early
data,
and
we
had
not
updated
the
push
Draft
to
include
that
required
language.
D
So
we
did
a
bit
of
thinking
and
we
figured
doing
the
SUBSCRIBE
is
not
something
that
will
cause
harm
if
it's
duplicated
and
the
performance
benefits
of
saving
the
roundtrip
may
well
be
worthwhile.
So
we
put
in
the
required
text
saying:
we've
considered
the
security
implications,
and
this
is
fine
with
TLS
early
data,
so
those
two
are
easy.
D
D
He
was
most,
he
was
mostly
write
about
many
things,
but
I
happen
to
agree
with
martin
thompson
on
this
one,
that
being
liberal
with
what
you
accept,
particularly
for
the
first
implementation
of
a
thing
anything
you're
liberal
about
other
buggy
implementations
will
probably
accidentally
do,
and
if
you
accept
it,
then
all
those
bugs
become
entrenched.
And
then
you
have
an
ecosystem
of
lots
of
buggy
code,
I.
Think
for
the
first
implementation
of
anything,
you
actually
have
a
responsibility
to
be
strict
and
reject
invalid
input,
because,
in
effect,
your
implementation
is
the
conformance
test.
D
The
ITF
doesn't
have
conformance
tests
and
certifications
that
have
to
be
passed
to
get
to
use
the
ITF
logo
and
your
product,
so
we
have
very
little
enforcement's
of
our
protocol.
In
effect,
the
deployed
implementations
are
the
conformance
test,
because
somebody
coming
along
to
make
an
implementation
is
going
to
test
it
with
yours
and
if
it
works,
they'll
ship
it
and
if
it
fails,
they'll
debug
it
so
early
in
the
game.
I
think
it's
really
important
to
enforce
all
the
things
you
want
to,
because
anything
you
don't
enforce.
You
don't
get
to
enforce
later.
D
So
with
that
spirit
in
mind,
in
many
cases
the
document
says:
if
you
do
something
completely
bogus,
then
the
other
end
is
going
to
reset
the
connection.
So
if
a
client
connects
to
a
server
and
then
sends
it
a
response
that
makes
no
sense,
tear
down
the
connection,
don't
even
bother
with
an
error
code,
because
that
is
something
that
the
programmer
is
going
to
debug
by
looking
at
a
packet
trace.
This
is
not
a
runtime
error
that
occurs
in
the
field.
It's
just
a
gross
programming
error
and
you
fix
the
bug.
D
So
there
are
many
cases
like
that
that
I
think
a
lot
of
specs
wouldn't
even
mention
we
were
trying
to
be
really
thorough,
and
we
put
this
text
in
Robert
sparks
pointed
out
entirely
correctly.
That
DSO
is
general
and
could,
in
principle,
run
over
any
transports
for
push
notifications.
We
have
specified
for
now
only
TLS
over
TCP
running
it
over.
Something
else
would
be
a
future
document
to
update
this.
So
Robert
said,
since
it's
only
for
TLS
over
TCP,
you
can
remove
the
equivalent
for
other
protocols,
because
there
aren't
any
oh
good
point.
D
Okay,
we'll
delete
that
text.
That's
easy
in
the
ensuing
discussion,
David
helpfully
said
well,
if
you're
using
TLS,
you
should
send
us
close
notified
instead
of
reset
which,
for
a
graceful,
close
is
true,
but
here
we're
talking
about
really
fatal
error
conditions
that
should
never
appear,
except
in
the
development
process,
and
hence
a
long
discussion
went
on
the
mailing
list
and
a
lot
of
off
mailing
list.
Discussion
too
I
just
want
to
confirm
there.
Yes,
I
didn't
have
the
full
context.
D
There
was
some
debate
about
whether
we
can
expect
a
grossly
buggy
client,
the
kind
of
client
that
connects
you
and
immediately
sends
you
a
response,
may
not
pro
the
rest
of
the
protocol
as
well.
So
that
is
a
question
that
we
can't
answer.
It's
speculation
about
implementations
that
don't
exist
yet
that
are
very
buggy.
D
There
was
also
lots
of
discussion
about,
while
the
client
can
enforce
the
delay,
and
that
turns
out
not
to
be
as
easy
as
it
sounds,
because
you
can't
tell
to
subsists
two
successive
connections
could
be
from
the
same
clients
or
they
could
be
from
different
clients
behind
the
same
NAT
gateway,
so
all
with
ipv6
they
could
be
different.
Privacy
addresses
on
the
same
device
or
different
devices.
The
whole
point
of
privacy
addresses
is
to
obscure
the
identity
of
the
client.
D
D
It's
hard
for
the
server
to
enforce
that
I.
Also,
when
I
looked
through,
I
found
that
out
of
the
12
cases,
seven
of
them
are
the
client
tearing
down
the
connection,
because
the
server
did
something
bogus
so
clearly
in
the
case
of
the
client
tearing
down
the
connection,
it
doesn't
need
to
tell
the
server.
D
Those
are
now
back
to
saying:
send
a
reset.
Five
of
them
are
bogus
things.
The
client
does
three
of
those
are
the
client
sending
responses
to
the
server,
which
is
so
bizarre
that
if
you
look
in
most
specs,
if
you
look
in
RFC
1035,
there
is
no
language
about
what
to
do.
If
a
client
connects
you
and
then
sends
your
response,
it's
just
so
silly,
they
don't
mention
it.
D
We
do
mention
it
and
we
say
if
a
client
does
that
you
just
give
up
on
the
client
all
right.
Sending
a
fin
then
puts
the
server
in
close,
wait
state,
while
it's
waiting
for
the
fin
to
be
acknowledged
and
if
a
client
looping
doing
bad
things
that
can
end
up
to
being
quite
a
resource
burden
on
the
server,
which
is
exactly
why
web
servers
do
not
send
a
fin
because
they
don't
want
to
have
their
burden
of
maintaining.
That
state.
D
So
so
the
client
sending
a
response
is
bogus.
The
client
sending
a
push
message
is
equally
bogus
because
that's
a
notification
which
should
go
the
other
way
and
the
last
one
here
is
the
only
one
that
I
think
is
somewhat
debatable,
and
that
is
if
the
client
sends
two
identical,
subscribed,
requests
and
I
want
to
explain
the
reasoning
why
we
had
the
wording
like
that
because,
as
I
said,
we
don't
have
conformance
testing
in
the
IETF.
D
D
If
we
don't
want
that
to
happen,
we
have
to
have
some
safeguard
in
place
that
will
cause
that
developer
to
say,
hang
on
now,
I
can't
leave
this
for
version
2,
because
my
clients
going
to
break
so
that
is
the
reason
for
this
is
to
be
unforgiving
about
our
requirements
that
clients
should
suppress
duplicates.
We
do
not
want
to
climb
that
ends
up
sending
a
hundred
identical
requests
to
a
server
because
of
a
bug,
and
if
that
happens,
the
server
should
protect
itself.
So
that
is
the
summary
of
the
changes.
I
would
welcome.
Any
feedback.
D
D
Ok,
well,
I'm
really
happy
that
that's
uncontroversial,
which
it
should
be
at
this
stage
in
the
process.
We
will
go
ahead
with
publication
of
that.
I
also
saw
on
David's
agenda.
It
said
hackathon
implementation
report,
I,
don't
have
a
slide
for
that,
but
I
can
verbally
tell
you
Ted
and
Barbara
and
I
had
a
productive
couple
of
days
sitting
together
working
at
the
hackathon.
The
code
we're
working
on
is
on
the
hackathon
github
repository.
If
you
go
to
github
org,
slash,
IETF
hackathon
you'll
find
the
MDS
responder
repository
there.
D
Ted
and
I
have
been
working
on
code.
We
have
running
code
that
you
can
run
on
Mac
or
Linux.
We've
also
been
building
it
for
open
wrt.
We
have
these
neat
little
GL
eye
nets.
Home
gateways
buy
at
the
size
of
a
pack
of
playing
cards
that
run
open
wrt.
We
have
pre-built
packages
for
that,
so
you
can
try
it
out.
We
did
demos
at
the
hackathon
and
we
also
went
to
the
hack
demo
happy
hour
on
Monday
and
had
a
table
set
up
there,
showing
it
to
people.
D
You
can
try
this
yourself
at
home
I'm
a
firm
believer
in
living
on
software.
That's
how
you
find
when
it
doesn't
work.
I
have
now
switched
it
using
one
of
these
GLI
net
routers
as
my
default
home
gateway.
My
Mac
and
my
iPhone
are
set
to
connect
to
that
by
default.
Whenever
I
come
home,
so
I'm
normally
on
that
network,
without
thinking
about
it
and
that
GLI
net
home
gateway
is
running
the
discovery
proxy,
it
is
not
forwarding
multicast,
it
is
in
a
normal
configuration.
D
It's
running
DHCP,
it's
running,
Knapp,
there's
isolation
between
the
land,
port
and
the
wine
port,
but
with
the
discovery
proxy,
all
the
stuff
I
do
on
my
Mac
and
my
phone
printing
scanning
anything
else.
That's
using
bonjour
discovery,
it
just
works
and
anything
that
doesn't
work,
I
find
it,
and
then
we
work
on
fixing
the
bugs.
So.
C
In
Ted
I
think
we
said
that
Friday
morning
we're
going
to
start
plugging
things
together
and
if
anybody
wants
to
build
a
load
and
bring
a
router
and
plug
it
together,
we're
going
to
be
meeting
in
the
code
lounge
at
10:00.
Is
that
what
we
said
thereabouts,
ish
and
try
and
plug
things
together,
so
you're
all
welcome
to
help
plug.
H
My
question
Stuart,
so
if
I
understood
what
you
just
described,
that
you
have
plugged
this
device
wired
LAN
part
into
your
existing
home
network,
creating
two
layers
of
router,
yes,
okay
and
on
the
wireless
or
maybe
the
wired
port.
You
now
can
see
the
devices
which
are
on
your
on
your
original
network.
What.
D
H
D
Thanks
for
the
clarifying
question,
yes,
that
the
utility
is
twofold,
worn
for
me
and
Ted
working
on
this
code,
the
utility
is
testing
it
on
a
daily
basis.
In
terms
of
why
anybody
else
would
do
this.
Looking
forward
to
the
broader
picture
of
why
we're
doing
this
work
at
all,
one
benefit
I.
Get
of
that
compared
to
how
my
network
was.
Is
my
client
devices?
D
I
I
I
So
so
the
discovery
proxy
I
assume
most
folks
here
know
what
a
discovery
proxy
is,
but
just
to
recap
my
discovery.
Proxy
is
a
device
that
receives
queries
using
DNS
on
port
53
and
asks
questions
to
answer
those
queries
by
using
multicast
DNS,
and
so
this
is
an
important
goal
for
a
variety
of
use
cases.
The
case
that
dragged
me
into
it
was
home
net
and
so
we've
implemented
a
nice
fully
featured
en
SSD
discovery
proxy.
I
So
it's
a
it's
a
full
working
implementation
of
DNS
push
over
TLS
and
it
also
does
something
that
I
wanted
for
for
home
net
and
it
doesn't
accidentally
like
I,
didn't
actually
plan
it
out.
This
way,
I
just
plan
on
writing
a
discovery
proxy
and
then
figuring
out
a
way
to
wedge
a
DNS
server
in
alongside
it,
but
it
turns
out
that
since
F
DNS
responder
acts
as
a
stub
resolver
for
DNS
and
mdns.
I
So
it's
pretty
sweet
and
you
can
try
it
out
anytime.
You
want
runs
on
Mac
OS,
it
probably
run
on
BSD,
but
I
haven't
tried
it.
It
definitely
runs
on
Linux
and
as
far
as
things
that
can
do
queries
against
it
pretty
much
anything
out
there
that
does
DNS
service
discovery
can
use
it.
However,
we
also
have
implementation
on
various
Apple
new
Apple
devices.
I
Sounds
like
No,
okay,
so
the
next
thing
is
discovery.
Really.
This
is
actually
kind
of
old
news,
but
I
just
wanted
to
mention
it
for
completeness.
We
did
a
discovery
relay
implementation
kind
of
last
year
and
the
purpose
of
the
discovery
relay
is
basically
to
do
something
very
much
like
what
DHCP
relay
does
to
provide
a
really
stupid
thing
that
you
don't
have
to
update
all
the
time
when
you
add
features
that
consider
in
your
router
or
whatever,
and
a
full
service.
M
DNS
resolver
can
contact
it
and
do
em
DNS
through
it
too.
I
So
some
folks
have
suggested
that
you
could
do
this
with
a
with
a
layer,
2
tunneling
program
or
protocol,
or
something
like
that,
and
that's
very
true,
and
if
you
have
that
available
to
you,
you
really
don't
need
this,
but
it
does
seem
like
a
useful
feature
for
a
fair
number
of
use
cases
it'll.
It
takes
advantage
of
IP
routing
and
to
end,
and
it
doesn't
require
any
special.
I
I
I
So
I'm
not
really
inclined
to
ask
the
group
here
to
tell
me
whether
they
love
this
thing
or
not,
because
you
know
you
may
or
may
not
have
read.
It's
probably
makes
the
most
sense
to
just
talk
about
this
on
the
mailing
list,
but
I'm
bringing
it
up
here,
so
that
so
that
when
you
see
the
message
on
the
mailing
list,
you'll
know
what
the
context
is.
I
D
My
name
is
Joe
Cheshire
I
know
you
said
you're
not
asking
for
comments
on
this,
but
I
feel
I
want
to
share
my
opinion
with
everybody
and,
as
co-author
on
this
clearly
I'm
biased,
but
I
think
the
work
we've
done
with
discovery
proxy
is
very
viable
to
put
in
open
wrt
for
home
gateways
for
the
enterprise
market.
Convincing
enterprise
router
makers
to
put
this
in,
is
a
much
harder
sell
and
also
probably
not
a
good
idea,
because
once
it's
in
it
won't
be
updated
until
that
router
goes
in
the
dumpster
ten
years
in
the
future.
D
So
and
for
those
who
don't
know
this
was
this
was
Ted's
idea
and
I
co-authored
document
with
him,
but
it
was
Ted's
idea
and
it's
kind
of
inspired
by
the
bootp
relay,
which
has
been
enormously
successful
for
enterprise
deployments
of
DHCP
I.
Think
this
small,
simple
focused
piece
of
code.
We
have
a
much
better
chance
of
evangelizing
this
to
the
enterprise
makers,
who
who
we
want
to
reach
way
back
when
this
group
was
chartered,
that
was
one
of
the
goals
was
to
improve
discovery
and
enterprise
networks.
So
I
definitely
think
we
should
push
ahead.
D
This
work
is
basically
done.
We
just
need
to
adopt
the
draft.
Have
some
people
review,
it
last
fall
or,
as
you
say,
go
the
independent
route.
I
would
prefer
to
do
it
in
the
working
group.
Tom
made
the
comments.
Can't
you
do
this
with
VLANs
and
I
think
we
should
add
some
text
about
that
in
the
documents.
D
If
you
already
have
a
setup
where
you
have
VLANs
configured
and
trunk
ports
and
maybe
some
enterprises
and
if
you
run
their
DHCP
by
having
VLAN
trunk
ports
instead
of
poopy
trail
agents,
I
think
a
paragraph
or
two
discussing
the
pros
and
cons
of
when
you
might
choose
one
versus
the
other,
that's
a
useful
addition
and
then
I
think
we're
ready
to
publish,
because
we
have
fairly
good
shared
documents
and
we
have
fairly
well
tested
code.
Yep.
B
So
to
comment
on
process
here,
this
is
adopted
as
a
working
group
document.
We
had
a
working
group
last
call
ready
and
it
failed
due
to
lack
of
interest.
So
the
issue
here
is
that
pretty
much
no
one
apart
from
the
authors
expressed
interest
in
this
work
with
I,
think
Tom
had
some
comments,
but
it
was
very
sparse
and
what
we're
asking
us
at
chairs
is
for
people
to
comment
like,
oh,
especially
like
this
is
aimed
at
the
enterprise
market.
B
Is
there
anyone
making
these
devices
that
thinks
this
is
useful,
but
you
don't
have
to
commit
to
I
know
I
want
to
deploy
this,
but
just
saying
that
this
is
useful
would
go
a
long
way,
yeah
that
that's
where
we
are
I
personally
and
not
as
chair
believe
that
this
is
a
good
document,
but
if
we
want
to
forward
it
as
a
working
group
item,
we'll
need
more
people
to
speak
in
favor
of
this.
So
you
can
either
do
this
now
at
the
microphone
or
on
the
list,
whichever
you
prefer
Tim.
J
Rotenberg
just
a
quick
comment
which
came
to
my
mind
when
Stewart
taught
at
the
mic.
So
if
this
document
is
intended
for
enterprise
vendors,
then
those
routers
or
whatever
it's
supposed
to
run
probably
have
the
ability
to
do
violence
or
something
like
this,
so
actually
I
think
we
should
yeah.
It
would
be
interesting
to
hear
if
there
are
good
use
cases
which
are
not
covered
by
this,
because
so
I
don't
have
a
particular
opinion
about.
J
If
that's
a
good
or
a
bad
idea,
because
I
don't
know
this
problem
space
well
enough,
but
I
think
it's
something
to
consider
if
we
are
not
aiming
for
like
customer
premise
equipment
but
for
enterprise
grade
hardware.
Something
like
this
that
the
question
is:
can
it
be
solved
there
in
other
ways
already.
H
Michael
Richardson
I'm,
sorry
that
the
working
of
last
call
was
so
silent
and
there's
issues,
probably
the
the
people
that
we
need.
The
enterprise
reviewers
that
we
need
are
just
not
in
this
working
group,
but
writing
email
to
some
people
that
I
think
may
care
I.
Don't
actually
think
the
VLAN
thing
is
terribly
useful
for
organizations
that
are
running
many
campuses
in
many
places
there
in
Canada
today
you
may
know
that
there
are
significant
issues.
Getting
VLANs
out
to
places
and
multicast
traffic
is
significantly
unwanted.
H
K
H
So
this
would
be
quite
attractive
for
a
number
of
things
where
I
think
service
discovery
is
simply
not
happening
period,
and
so
it
may
be
a
decade
another
decade
before
you
know
enterprises
that
adopted
enough
such
that
everyone
says.
Oh,
we
actually
can
do
service
discovery
in
these
distributed
enterprises.
Well,
that's
what
we
were
charter
to
facilitate
so.
H
H
Well,
that's
an
interesting
question
right.
So
EMU
might
be
very
a
good
place
to
reach
some
people,
because
it's
the
same
problem
of
you
know
with
1x,
going
over
EAP
to
do
authentic,
authenticated,
join
of
the
network.
Okay,
now
that
you've
joined,
you
know
what
would
you
like
and
that
that
whole
model
is
the
same
model
right
that
you
you
you
you
kick
back,
we
don't
we
don't
punt
EAP
messages
back
to
the
controller
with
a
VLAN
right.
H
We
do
it
over
radius,
same
same
same
architectural
things
so
that
that
may
space-
and
maybe
just
we
don't
as
a
group,
have
those
right
and
enterprise
people,
but
we
do
have
some
people
that
just
you
know.
We
always
know
this
problem,
the
ITF.
We
don't
really
have
enough
enterprise
representation
and
enterprise
operators
or
Christina
unicorns
right.
So
so.
I
I
think
so
what
I
would
suggest
is
a
way
forward
is
get
to
the
point
where
I
think
that
everything
that
I
need
to
do.
The
document
is
done,
which
may
be
a
very
short
step.
I
haven't
actually
reviewed
it
in
a
while.
Just
you
know,
due
diligence
and
then
once
that's
done,
then
yeah
try
to
get
I
know
that
there
are
some
folks
from
various
places.
That
would
probably
say
yes
to
this,
but
we
need
to
actually
get
them,
get
them
roped
in
and
so
yeah,
oh,
but
we
should.
B
So
this
I
mean
and
speaking
press
chair
and
procedurally,
it
didn't
feel
like.
There
was
a
whole
lot
of
comments.
I'll
go
back
and
look
at
the
list,
but
if
you
get
people
to
comment
and
say
that
they're
interested
in
this
work,
it
doesn't
have
to
be
in
last
call
we
can
consider
those
as
last
call
or
as
statements
of
interest
interest
doesn't
need
to
happen
during
last
call:
okay,.
B
L
B
I
D
And
I'm
just
gonna
echo
the
requests
for
the
people
here.
It
would
be
helpful
to
review
it.
I
just
had
to
look
it's
only
29
pages,
so
probably
no
more
than
an
hour
of
reading,
and
if
people
have
contacts
at
enterprise
equipment,
vendors
who
are
not
involved
with
this
working
group,
which
is
understandable
that
a
lot
of
them,
they
wouldn't
think
they
have
an
interest
here.
If
you
can
send
us
those
contacts,
we
can
reach
out
to
them
individually.
Thank
you.
M
Composer
Terry,
the
reason
I
brought
up
VLANs
was
because
I
know
from
experience
that
people,
our
operators
have
taken
a
long
time
to
troubleshoot
to
learn
how
to
troubleshoot
bootp
relays,
and
this
is
another
thing
they
have
to
learn
how
to
troubleshoot,
and
so
it's
not
the
same
as
troubleshooting
the
gup-e
relay
it's
a
different
thing.
It's
a
different
problem,
but
VLANs
is
something
they
do
already
know
how
to
troubleshoot
and
there's
two
other
ways.
I
can
also
think
of
solving
this
and
that's
by
GMP
proxies
I'm.
M
I
I
There
seems
like
it's
a
lighter
weight
problem
than
configuring,
a
special
tunnel
and
setting
all
of
the
filtering
correctly
and
getting
you
know
so
so
you
know
it
may
be
that
the
right
answer
to
this
is
that
we
just
have
a
document
that
says
how
you
set
up
the
tunnel
and
get
filtering
right.
But
then
you
have
a
point
solution
that
only
works
on
certain
kinds
of
devices
so
like
the
device
has
to
support
IGMP
tunneling.
So.
M
I
Think
that's
good,
okay,
so
by
the
way
I
just
wanted
to
point
out
in
case
there's,
confusion
remember
that
discovery
relay
and
discovery
proxy
are
two
different
things.
Discovery
proxy
is
the
smart
thing
that
actually
like
does
multicast
resolution
on
the
local
wire
and
discovery.
Really
is
the
dumb
thing
that
just
relays
the
packets
and
let's
there
lets
the
aggregation
and
resolution
stuff
happen
on
a
smart
server
and
you're
in
your
machine
room
or
wherever
so
all
right,
so
moving
right
along.
I
So
the
other
document
that
I've
been
working
on
is
the
Service
registration
protocol
document
and
Tom.
Very
kindly
did
a
review
of
the
SRP
document
a
couple
months
ago
at
this
point,
and
I
was
right
in
the
middle
of
hacking
on
something,
and
there
were
deadlines
and
life
got
away
from
me,
and
so
I
didn't
actually
look
at
it
for
a
while,
after
that,
but
I've
done
some
updates
and
there
are
some
questions
that
I
think
it
would
be
worth
discussing.
So
some
of
the
updates
are
really
stupid.
I
Things
like
the
document
was
referring
to
services
DARPA
and
it
seemed
like
the
when
we
were
doing
the
implementation.
I,
actually
I
had
forgotten
that
it
was
services,
DARPA
and
so
I
typed
service
tower,
and
it
just
seemed
to
make
more
sense,
and
so
the
document
actually
now
says
service
DARPA
instead
of
services,
not
art,
but
because
it's
one
less
letter
and
I
don't
see
any
real
reason
why
it
needs
to
be
service
as
DARPA.
But
you
know
if
anybody
objects
to
that,
please
let
me
know,
and
then
the
document
now
adds
support
for
TLS.
I
You
know
DNS
name
so
for
SRV
records.
So
so
that's
already
been
added
to
the
document.
There
are
further
updates
needed
to
the
document,
so
I'm
gonna
just
go
over
tongs
comments
a
bit
Tom,
so
the
document
was
written
by
me
as
I
was
doing
the
implementation.
So
of
course
I
had
a
lot
of
state
in
my
head
and
it
all
made
sense
to
me.
Tom
read
the
document
he's
like
well.
This
doesn't
make
any
sense
at
all
and
he
had
a
really
good
point,
which
is
that
I
use
the
term
update.
I
M
I
A
register,
so
we
could
call
the
the
whole
message:
an
SRP
registration
instead
of
an
SRP
update
I
like
that
all
right.
Hopefully,
that
will
show
up
in
the
minutes.
Otherwise,
I'll
probably
forget,
but
thank
you
that
was
a
hint
okay.
Tom
also
found
the
discussion
of
the
whole
validation
section
a
bit
confusing
I.
I
Don't
really
have
any
questions
about
what
to
do
there.
I
just
didn't
have
time
to
do
it
before
them
before
the
cutoff.
So
I
will
do
that
when
I
next
wrap,
the
draft,
which
will
be
soon
Tom,
asks
some
some
really
good
security
questions.
This
is
the
first
one.
The
question
was,
you
know:
why
are
we
not
sending
this?
Why
are
we
sending
this
in
the
clear?
Why
are
we
just
making
a
TCP
connection
and
I
hadn't
even
thought
about
it?
I
I
G
I
G
I
A
I
This
would
be
opportunistic
security,
so
so
it
doesn't
need
to
be
signed
certificate,
we're
already
requiring
it
for
DNS
push
and
the
current
implementation
that
I
have
for
DNS
push
the
current
implementation
that
I
have
or
DNS
push
does
not
check
the
sort
it
just
takes
advantage
of
the
of
the
you
know.
If
you
have
an
on
path
attack
or
the
on
path,
attacker
will
be
able
to
intercept
your
connection
and
violate
your
privacy,
but
but
at
least
it
makes
it
more
expensive
to
do
that.
O
I
We'd
have
to
describe
how
to
do
that.
I
think
that
that
it
might
make
sense
to
describe
how
to
do
it
with
certificates,
but
if
we
did
that
I
kind
of
like
to
do
it
using
Dane
and
and
I'm
not
really
ready
to
write
that
text.
So
that's
why
that's
why
I'm
punting?
But
if
somebody
wants
to
offer
text
you
know
we
can
talk
so
Tom
brought
up
another
security
issue,
which
I
think
was
a
really
good
one
that
I
hadn't
thought
about,
which
is
that
we
currently
are
just
asking
for
a
global
anycast
address.
I
So
if
you
send
a
message,
so,
oh
sorry,
a
little
backstory,
there's
two
different
ways
that
SRP
works.
One
of
them
is
that
we
require
TCP
for
for
fully
featured
SRP
clients,
so
the
client
is
required
to
connect
with
TCP,
and
then
we
get
a
three-way
handshake,
and
that
means
we
know
that
we're
actually
talking
to
who
we
think
we're
talking
to
and
they're
roughly
where
they,
where
they
claim
to
be.
I
However,
for
IOT
devices
requiring
the
full
discovery
process
is
kind
of
painful,
and
so
I
came
up
with
a
way
to
on
IOT
networks.
Only
support
this
global
anycast
address
update
and
the
idea
there
is
basically
the
client
just
doesn't
the
client
doesn't
do
any
service
discovery
at
all?
It
just
sends
out
an
update
and
it
says
hi
I'm,
offering
this
service
here's
the
information,
good
luck
and
by
the
way
it
uses
a
domain
of
service,
it
sent
its
DNS
update
server
to
the
service
DARPA
domain.
I
That's
that's
where
that
comes
in
so,
and
that's
like
really
lightweight
and
I'll.
Tell
you
a
little
bit
more
about
just
how
lightweight
it
is
because
it's
kind
of
awesome,
but
the
point
of
that
is
that
is
that
I
just
allocated
a
global
address,
and
so
now
this
this
IOT
device
is
sending
this
update
message
and
if
there
isn't
some
things
sitting
on
path,
intercepting
the
message
to
the
anycast
address:
it's
gonna
go
out
to
the
internet
right.
I
This
is
okay,
it's
just
gonna
get
routed
somewhere
onto
the
backbone
and
then
eventually
get
dropped,
but
possibly
not
before
some
malefactor
sniffs.
It
and
figures
out
that
you
have
light
switches
in
your
house
or
something-
and
you
know
we'd
like
to
avoid
that.
We
don't
want
some
malefactor
to
be
able
to
sniff
your
your
traffic
and
know
that
there
are
light
switches
in
your
house
and.
I
So
so
two
different
scenarios
here:
one
is
the
all-singing,
all-dancing
SRP,
update
scenario.
The
other
is
the
the
constrain
device
update
scenario
so
I'm
talking
now
about
the
second,
the
constrained
device,
update
scenario
and
the
constrained
device
update
scenario,
we're
not
doing
TCP
or
we're
not
doing
TLS,
at
least
in
principle.
Maybe
that's
the
wrong
thing
to
do.
I
think.
H
H
Mean
I,
don't
think
that
this
is
something
that
it
couldn't
be
a
device,
a
IOT
device
which
is
sufficiently
constrained
that
it
can't
do
TCP
and
TLS
should
be
doing
on
its
own.
So
so
we
have
categories
weenus,
72
28,
you
know
aside,
because
it
doesn't
actually
give
us.
You
know,
classes
to
describe
the
devices
that
are
above
it,
but
essentially,
if
you
can,
if
you
have
enough
energy
to
run
Wi-Fi,
then
you
have
enough
right.
Need
you
to
run
TCP
less
the.
H
I
H
I
H
I
H
P
H
I'm
and
I'm
actually
quite
upset
that
we
don't
have
a
good
to
answer
to
the
problem
that
you
just
have
said.
I
think
the
answer
is,
we
need
a
ula
central
address
right.
N
N
H
D
D
It's
a
mesh
network
layered
on
top
of
6lowpan,
which
runs
over
I
Triple,
E,
880
or
15.4,
which
are
core
to
make
a
bit
wireless
technology,
similar
speed
and
range,
and
battery
consumptions
of
Bluetooth,
but
has
a
benefit
of
being
more
IP
friendly,
which
is
why
I'm
predisposed
to
like
that
and
then
I've
been
going
through
this
little
thought
process
of.
If
we
wanted
to
run
home
care
on
thread,
what
would
we
need?
D
We
don't
necessarily
need
a
gateway
to
the
Greater
Internet
I
could
imagine
a
just
a
self-contained
thread
mesh
that
doesn't
even
connect
to
my
home
Wi-Fi,
but
it
allows
like
switches
to
control
life
via
IP
packets
on
that
mesh.
In
order
for
that
to
be
done
with
the
homecare
protocols,
the
light
switches
have
to
discover
the
lights
that
they're
turning
on
and
off
and
homekit
doesn't
use
core
Rd
homekit
uses
DNS
service
discovery.
I
So
that's
a
motivation
for
for
doing
this
work
and
essentially
what
we're
offering
here
is
just
here's
a
lightweight
way
to
do
this
thing
on
on
a
NATO,
2.15
dot
for
network
or
something
like
that,
and
you
know
it's:
it's
not
a
huge
change
to
the
whole
protocol.
In
fact,
it's
it's
essentially
the
exact
same
thing,
except
that
you're
not
going
out
and
looking
up
the
SRV
record
you're
just
sending
it
to
some
well-known
address.
I
So
you
know
one
option
is
certainly
to
say:
no.
You
can't
do
that.
That
would
be
kind
of
a
weird
thing
to
say,
but
certainly
the
working
group
could
say
that
another
thing
to
say
is
sure,
go
ahead
and
do
that.
But
you
need
to
use
a
site
scope
to
any
anycast
address,
in
which
case
we
have
to
go
out
and
solve
that
problem
which
is
kind
of
heavy
weight,
or
we
can
just
make
it
something
where
it's
not
specified.
I
How
the
what
what
address
is
used,
but
just
generally
speaking,
if
you
want
to
use
this
this
light
weight
mode,
then
whatever
IOT
or
constraint,
network
you're,
using
it
on,
is
going
to
need
to
have
a
well-defined
address
to
which
these
packets
are
sent.
So
you
know
I,
don't
know
what
to
say
about
the
whole
core
ID
versus
DNS
is:
do
you
think?
I
That's
really
not
it's
I'm,
just
not
even
interested
in
core
Rd,
so
maybe
I
would
be
at
some
point
in
the
future,
but
I'm
not
right
now,
so
so
I'm
just
interested
in
solving
this
particular
problem,
and
the
question
is
whether
there's
you
know
whether
it's
something
we
should
in
fact
solve
personally
I
think
it
is
I.
Think
it's
useful
I
mean
whether
you
think
core
idea
is
a
good
idea
or
not.
I
think
it
is
useful
to
be
able
to
announce
the
presence
of
a
device
and
register
it
as
a
service
in
DNS.
H
I
H
I
am
working
with
thread
on
enrollment
things,
and
they
do
a
lot
of
things
differently,
just
for
the
hell
of
doing
it
differently.
So
if,
if
I
were
to
learn
that
they
actually
have
a
service
discovery
protocol,
you
know
already
I
would
I'm
almost
certain
of
that
as
the
fact.
So,
if
you
were
to
make
homekit
work
under
threat,
you
would
either
have
to
convince
them
to
run
this
or
do
something
else.
Okay,
so
I
think
it's
not
entirely
a
particularly
important
consideration.
H
The
point
is
that
whatever
I
don't
think
it
matters
whether
they're
running
SRP
or
they're
running
something
else
or
core
Ardi.
The
point
I'm
trying
to
say
is
that
if
there's
going
to
be,
if
it's
going
to
matter
to
devices
outside
of
that
network,
then
there's
a
gateway
that
is
leading
that
process.
Okay,
so
I
think
that
we
could
have
that
that
that
happened.
I
think
that's
a
I
think
that
would
be
a
better
I
think
that
would
be
better.
Having
said
that,
I'm
not
opposed
to
you
going
forward.
H
Okay,
okay,
I
think
that
if
you
don't
want
to
go
through
the
rigmarole
of
trying
to
find
as
I
sight,
scope
address
mode
and
anycast
that's
going
to
leak.
Sorry,
that's
going
to
secure,
be
secure
when
it
leaks
right,
then
I
think
you
should
defer
the
work
until
we
do
that.
Okay
yeah,
this
part
of
it
yeah.
Having
said
that,
I
think
we
should
do
get
the
site
netskope.
H
I
So
basically,
the
the
status
quo
now
is
that
we're
currently
using
a
global
address
and
to
Tom
pointed
out
that
that's
a
bad
idea
and
I
agree
with
him
and
so
I
think
that
the
the
expedient
fallback
and
the
one
that
probably
makes
the
most
sense
is
to
just
consider
the
use
case
that
we
actually
have
in
mind
and
think
about
what
would
work
there.
And
the
answer
is
a
mesh
local
ula,
a
well
known
address
within
the
mesh
local
ula
Stewart
yeah.
D
D
The
way
thread.
Discovery
in
quotes
works
today,
with
the
nest,
thermostats
and
smoke
detectors.
Is
that
everything
phones
home
to
the
cloud
and
the
quote
discovery
is
that
which
devices
are
owned
by
the
same
nest
account
in
the
cloud.
There
is
no
local
peer
to
peer
discovery,
it's
all
mediated
through
the
Clair.
So
that
was
a
disappointment,
because
we
were
hoping
to
find
something
a
little
bit
more
fully
baked
with
apples,
different
priorities.
The
home
kit
is
built
without
a
cloud
service.
D
It
assumes
you've
got
some
brains
in
the
house
and
nothing
has
to
leave
the
house
so
so
things
need
to
discover
them
other
peers
on
the
network.
So
that
is
how
we
went
down
this
path,
which
is
thread,
has
no
discovery
mechanism
currently
defined.
They
need
to
define
one
to
grow
beyond
their
current
limited
use
cases,
and
naturally
this
is
what
we
are
advocating.
D
So
that's
how
work
now
the
feedback
about
the
details
here
is
incredibly
valuable.
I
agree
that
any
address
that
might
escape
the
house
by
accident
definitely
is
not
what
we
want
a
risk
for
privacy
reasons,
so
maybe
for
the
thread
case.
The
answer
is
that
the
thread
local
network
data
conveys
a
configured
address
to
the
clients
and
they
use
that
so
for
the
thread
case.
I
think
we
can
solve
this
for
broader
use
cases.
This
might
still
be
an
interesting
discussion
to
figure
out
how
to
automate
it
for
all
link
types.
N
Just
analysis
I
think
that
we
have
the
the
Rd
and
the
the
DNS
st
discoveries
have
there's
there
dissimilarities,
but
when
it
comes
to
the
anycast
address
and
having
an
R
per
domain
for
all
those
site,
local
things
I
think
we
should
sit
down
together
and
kind
of,
compare
notes
on
what
we
can
unify
and
where
we,
where
we
have
separate
ecosystems,
yeah.
I
Definitely
yeah,
so
it's
a
separate
conversation
but
yeah.
That's
definitely
worth
doing
alright.
So
moving
right
along
I
think
that
the
conclusion
that
I'm
drawing
from
this
is
that
I
should
just
say
that
we
should
use
a
mesh
local
address
and
that
this
document
that's
out
of
scope
for
this
document,
but
but,
generally
speaking,
this
is
what
we
suggest.
So
tom
also
pointed
out
something
in
Stuart.
I
haven't
actually
had
a
chance
to
talk
to
you
about
this,
so
I
apologize
for
springing
it
on
you
on
a
slide,
but
here
it
is
anyway.
I
Tom
pointed
out
that
sleep
proxy
is
not
entirely
compatible
with
what
we're
doing
for
SRP,
because,
as
our
doesn't
necessarily
assume
that
the
thing
we're
updating
is
on
the
local
wire
and
he
was
confused
by
that
and
I
think
it
may
mean
the
basically
so
so
SRP
is
a
router
unicast
protocol.
The
DNS
server
does
not
have
to
be
on
the
local
wire
sleep.
Proxy
requires
a
presence
on
link.
I
H
H
H
If,
for
some
reason
the
document
was
monstrously
too
big
and
you
have
had
the
comment
about
two
big
documents
aren't
possible
to
review
in
advance.
Then
I
would
say
it's
something
to
remove,
but
I,
don't
think
that's
the
case.
Yeah
I,
don't
think
so.
I
think
it's
it's.
Maybe
it
doesn't
really
gel
with
the
rest
of
the
concept,
but
you
know
it.
It's
a-you
know
I,
think
it
fits.
I
Into
the
yeah
the
thing
that
we
really
want
to
add
so
sleep
proxy
already
exists
like
if
you
have
any
Apple
products,
they
already
have
sleep
proxy
built
into
them,
but
what
we
wanted
to
add
to
that
was
first-come,
first-serve
naming
and
so
really,
if
you
could
think
of
this,
as
just
three
separate
use
cases
for
the
general
SRP
registration
update,
one
of
them
is
registering
to
an
SRP
server.
That's
that's
serving
possibly
a
multi
subnet
land.
One
of
them
is
register.
I
Registering
your
IOT
device,
that's
on
a
constrained
network
and
the
third
is
registering
with
a
sleep
proxy
and
a
sleep
proxy
is
not
an
SRP
server
in
the
same
sense.
So
so
essentially
I
think.
Maybe
that's
a
way
to
explain
this.
That
is
less
confusing.
Does
that
make
sense
to
you
Tom?
Okay,
so
so?
In
other
words,
SRP
updates
are
the
same
for
all
use
cases.
However
SRP
updates
to
their.
There
are
three
different
things.
You
might
send
an
SRE,
an
SRP
registration
to
changing
the
terminology.
I
I
What
are
we
calling
these
things,
your
board
or
router,
your
constraint,
network
border
router,
or
you
might
send
it
to
your
sleep
proxy,
three
different
recipients
of
the
same
type
of
message
that
has
the
same
essential
features
and
the
way
that
they're
handled
are
slightly
different,
but
they
basically
all
have
more
in
common
than
than
there.
That
is
different
about
Tim.
Did
you
wanna.
L
I
I
Note
that
we're
gonna
have
these
three
different
use
cases
for
the
for
the
awesome.
Oh,
thank
you.
Much
appreciated,
alright.
So
now
now
that
we're
done
with
the
boring
stuff,
so
I've
done
an
implementation
of
the
SRP
client
that
actually
I
have
running
on
a
thread
board
as
it
happens,
and
it's
pretty
sweet,
it's
the
hole,
the
hole.
All
the
code
is
less
than
10k,
including
key
generation
and
sig
zero
signing
it's
really
simple.
It
just
adds
one
service
and
the
message
that
it
sends
to
the
server
is
about
320
bytes.
So
it's
it's!
J
J
I
Right
yeah,
if
you
need
any
help
with
sig
zero
stuff,
let
me
know
ok,
so
so
that's
the
client
side
I've
also
implemented
an
SRP
proxy.
Yet
another
proxy
right,
so
I
wanted
to
be
able
to
have
to
receive
actual
SRP
registrations
on
port
53
and
have
them
update
an
authoritative,
DNS
server.
But
I
looked
at
doing
that
two
by
nine
and
it
was
actually
a
fairly
big
job.
I
think
it's
doable
and
and
I'm
talking
to
Mark
Andrews
about
that,
but
I
wanted
something
that
was.
I
That
was
not
basically
I
wanted
something
generic
that
could
be
put
in
front
of
any
authoritative
server.
That
xx
accepts
dns,
updates
and
so
I
wrote
some
code.
That
does
that,
and
so
what
the
code
does
is
it
receives
the
the
SRP
registration
and
then
it
figures
out
what
dns
updates
it
has
to
do
now.
The
idea
with
an
SRP
registration
is
that
the
whole
thing
fits
into
one
message,
because
it's
all
of
the
all
of
the
records
are
pointing
at
each
other
and
there
are
no
prerequisites.
I
Dns
update
allows
you
to
use
prerequisites
to
prevent
data
from
being
added
to
the
zone.
That
you
don't
want
to
add
to
the
zone,
and
you
know-
and
it
allows
you
to
do
a
sort
of
it-
allows
you
to
do
an
atomic
update
of
the
database
where
you
know
if
these
pre
records
pre
Rexes
are
true,
then
do
the
update
and
don't
change
the
database
in
between
checking
the
prerequisites
and
doing
the
update.
I
Srp
doesn't
there's
no
way
to
do
a
single
message,
SRP
update
with
prerequisites,
because
there
are
too
many
different
things
and
and
DNS
update
prerequisites.
Don't
allow
you
to
do
things
like
if-then-else,
so
so
what
I've
done
instead
for
the
so
the
proxy
is
receiving
a
single
message
and
then
first
it
just
tries
to
do
the
update
straight
and
sets
the
prerequisites.
If
nothing's
there
do
the
update,
and
if
that
succeeds
great,
we
just
did
it
if
that
fails,
or
actually
the
first,
it
does
no
change.
So
it
did.
I
The
the
the
assumption
is
that
the
record
is
already
there.
We're
gonna
send
an
update
and
the
prerequisites
are
that
the
record
is
there
and
contains
the
same
information
as
before,
and
that
can
that
can
happen
in
one
message:
if
there's
nothing
there,
then
that
can
happen
in
one
message.
But
that
would
be
a
second
message
and
then
the
third
thing
that
happens
is
neither
one
of
those
attempts
worked,
and
that
means
there's
something
there,
but
it's
not
the
same
as
what's
in
the
SRP
registration.
I
So
now
we
have
to
actually
go
through
and
iterate,
and
so
it's
it's.
This
complicated
state
machine
that
just
goes
through
and
does
all
the
iterations
adds
or
or
updates
various
records,
and
if
it
comes
to
a
kata
to
a
situation
where
it
realizes
that
there's
something
in
the
zone
that
conflicts
with
the
SRP
registration,
then
it
has
to
back
everything
out
and
send
a
failure
response
and
on
the
other
hand,
if
it
gets
all
the
way
to
the
end
and
doesn't
have
any
problem.
Then
that
was
success
and
it
sends
a
success.
Result.
I
I've
tested,
I
think
I've,
exhausted
li
tested
all
the
various
different
ways
that
it
can
succeed
or
fail,
and
they
all
seem
to
work.
So
it's
pretty
sweet.
It's
actually
kind
of
fun
to
watch
because
you
see
like
one
SRP
update,
come
in
and
then
like
a
bunch
of
events
occur
in
the
log
that
was
fun
future
work
home
net
integration
we
need
to.
We
were
talking
about
this
on
the
helmet
mailing
list.
Actually
h,
NCP
identifies
links,
it
would
be
nice
if
the
dns
SD
discovery
proxy.
That
was
three
implementations
ago.
I
If
the
discovery
proxy
could
take
advantage
of
the
information
that
h,
NCP
is
sharing
packages
for
open
wrt,
we
already
have
them,
but
there's
still
some
some
work
to
be
done
so
that
you
can
just
install
them
and
it
just
works
without
you
having
to
fiddle
around
with
it,
which
currently
there's
a
readme
file.
That
has
a
fair
number
of
instructions
in
it.
I
So
that's
one
bit
of
future
work
that
we
want
to
do
another
bit
of
future
work
is
a
fully
featured
SRP
client,
similar
to
what
Tim
did,
except
possibly
we
don't
know
whether
he
did
sig
zero
or
not.
So
that
would
be
really
cool
and
it
sounds
like
it's.
Gonna
have
to
support
TLS,
also
and
I.
Don't
think
that's
a
big
come
out
of
work
but
needs
to
happen.
It
would
be
nice
to
have
SRP
support
in
some
DNS
auth
server
and
I'm.
I
Thinking
by
nine
mark
Andrews,
as
I
said,
has
has
talked
to
me
about
some
work
that
he's
been
doing
to
make
by
nine
support
a
wider
variety
of
different
kinds
of
update
strategies,
and
it
would
be
kind
of
cool
to
add
this
in,
as
another
update
strategy
mark
has
indicated
a
willingness
to
to
collaborate
with
me
to
some
extent
on
SLO.
Presumably
I
have
to
do
most
of
the
work
so
I'm,
hoping
that
this
will
happen
before
Singapore,
but
I
make
no
promises.
I
So
that's
that's
my
list
of
future
work,
I'm,
not
promising
that
any
of
these
things
will
be
done
at
any
particular
time,
but
they
are
definitely
on
the
agenda
and,
if
anybody's
interested
in
hacking
on
any
of
this
stuff,
please
let
me
know-
and
also,
if
you're
interested
in
just
like
playing
around
with
the
stuff
that
I've
already
got.
Please
let
me
know
there
will
be
some
information
on
the
next
slide
about
that
SRP,
the
future
of
SRP.
So
s
RP
got
one
review
during
last.
I
I
There
seem
to
think
this
was
useful,
and
so
it
seems
like
we
really
could
have
gotten
enough
comments
to
make
this
work
look
like
it
was
like
it
had
support,
but
we
didn't,
because
we
didn't
actually
ask
HomeNet
to
comment
on
it,
so
we're
gonna
do
that,
hopefully,
in
another
last
call
so,
and
so
hopefully
that'll
mean
that
we
don't
drop
this
and
it
gets
published
as
an
RFC.
So
my
proposal
is
I'm.
I
M
I
M
I
M
I
Well,
so
so
DNS
SD,
/
m
DNS
currently
does
do
that
right.
If
you
have
a
device
that
that
is
sending
out
an
advertiser
or
has
sent
out
an
advertisement
to
somebody
that
it's
on
the
network
when
it
when
you
shut
it
down,
if
it's
able
to
send
out
a
goodbye
packet,
it
does
and
I
think
this
is
the
equivalent
of
that
goodbye
packet
and
I
agree
that
that's
worth
doing.
You
know
it's
just
an
omission.
So
thank
you
for
pointing
that
out
and
then
the
other
thing
is
if.
G
I
I
mean
if
we
were,
if
we
had
it
all
to
do
over
again,
I
mean
I.
Actually,
when
I
first
started
working
on
this
I
was
thinking.
Do
we
really
want
to
do
this
in
a
DNS
packet?
I
wound
up
doing
it
at
a
DNS
packet,
because
it's
just
expedient,
it's
less
work,
there's
already
stuff
out
there
that
accepts
dns,
updates
and
so
I
was
able
to
test
it
very
easily,
and
it's
all
very
straightforward.
I
Well,
yeah
I
mean
sure,
but
but
but
mainly
that,
has
like
a
more
rich
prerequisites
language
so
that
we
can
do
a
single
update.
You
know
an
atomic
update
to
the
database
that
adds
everything
at
once
and
checks
all
the
prerequisites
at
once,
and
so
we
don't
have
the
situation
where
I
have
to
go
in.
Add
things
back
out.
You
know
the
worst
case
scenario
is
I,
add
things
that
I
back
out,
but
something
else
stumbled
over
something
that
I
added
in
the
process
and
it
backed
out
and
now
everybody's
unhappy.
I
I
B
C
B
So
Tom
brought
this
up
on
the
list.
So
though,
thanks
Tom,
that
we
don't
have
that
much
feedback
on
some
of
our
latest
documents
and
we
were
wondering
so
kind
of
where
do
we
go
from
here?
We
were
considering
for
a
while
reach
our
during
this
working
group
and
one
of
the
main
topics
that
we
were
considering
for
the
new
charter
was
the
privacy
work
that
said
so
that
that
is
still
a
possible
viable
path
forward.
B
But
similarly
there's
not
a
it
doesn't
feel
like
there's
a
huge
amount
of
energy
going
into
the
privacy
work,
and
so
one
option
which
I'm
not
saying
over
and
recommending
any
of
these,
but
one
that
has
been
suggested,
is
to
move
that
work
somewhere
else
and
close.
This
working
group
so
I
wanted
to
hear
feedback
from
anyone
in
the
working
group
of
what
are
your
thoughts
on
this
question.
What
should
we
be
doing?
B
D
Stuart
Church
again
I
want
to
echo
what
David
is
saying
from
a
personal
standpoint:
I
think
privacy
is
really
important
and
I.
Think
in
the
last
year
there's
been
a
lot
more
awareness
of
how
important
privacy
is
and
I
think.
That's
only
going
to
continue
I
thought
about
these
questions
of
how
to
do
discovery
in
a
privacy
preserving
way
a
lot
and
I,
don't
know
the
answers,
so
I
think
it's
important,
but
I
don't
know
how
to
do
it.
D
If
there
are
other
people
in
the
working
group
with
good
ideas
and
there's
energy
for
doing
this,
I
would
love
to
support
that
I.
I
think
it
would
be
sad
if
we
wrap
up
the
working
group
or
just
as
the
whole
world,
suddenly
wakes
up
to
the
importance
of
privacy.
That
would
be
unfortunate
timing,
so
I
hope
we
can
find
a
way
to
move
forward.
Unfortunately,
I've
spent
a
lot
of
time.
Thinking
about
this
and
I
have
not
worked
out
any
wonderful
answer
that
just
solves
all
the
problems
and
is
also
efficient
and
reliable.
I
I
I
They
working
the
the
work
that
was
presented
there.
This
time
was
all
about
coming
up
with
and
basically
doing
doing,
ad
hoc
keying.
So
so
some
work
that
that
Daniel
con
Gilmore
has
been
has
been
doing
with
a
bunch
of
other
people
on
coming
up
with
ways
to
do
encrypted,
email
that
doesn't
suck.
That
has
a
good
user
experience,
which
means
it's
less
secure,
but
but
it's
still
it's
better
than
nothing
right.
So
so
that's
interesting
and
kind
of
not.
I
Talking
about
there
was
another
group
that
was
doing
something
similar
with
instant
messaging
I.
Think
that
the
work
that
we're
doing
isn't
exactly
the
same
as
the
work
that
they're
doing,
but
it's
synergetic
with
it
like
they
could
take
advantage
of
what
we're
trying
to
do,
and
they
would
probably
be
interested
in
what
we're
trying
to
do,
and
they
probably
know
something
about
the
problem
space
and
might
be
interested
in
working
on
the
problems
that
we're
working
on
too.
I
Q
Christian
Arita
mom
well
I've
been
the
one
trying
for
some
years
to
get
privacy
walk
to
actually
start
into
this
walking
group
and
I've
come
to
the
conclusion
that
is
not
gonna
happen,
because
I
mean
we
have
been
going
for
oil
things
now.
I
think
that
we
did
some
a
number
of
things
that
should
be
somehow
published
and
I.
B
B
Know
like
if
you
want
to
revive
it
and
then
email
the
list
for
comments,
I
think
moving
it
forward
and
publishing
all
of
the
because
that's
true
a
lot
of
thought
and
work
has
gone
in
this
working
group
on
developing
these
requirements.
I
think
public,
regardless
of
whether
we
come
up
with
a
solution
or
not
I,
think
publishing
the
requirements
is
a
reasonable
thing,
so
Thanks.
K
So
I'm
Michael,
McCool
or
Intel,
and
also
co-chair
whether
things
working
group
in
33c
and
my
interest
in
this
is
we
are
trying
to
distribute
information
about
devices
but
want
to
do
it
in
a
privacy-preserving
way.
In
fact,
it's
one
of
our
requirements
to
get
recommendations
together,
some
that
we
see,
but
we
fundamentally
need
a
discovery
service
to
control,
distribution
of
metadata
and
especially
in
the
home
context,
most
smart
city
context,
and
so
this
is
kind
of
a
funny,
no
requirement
for
what
we
want
to
accomplish
and
we
feel
free
consists
of
adoption.
K
So
the
real
question
is:
where
does
it
work
belong
right,
so
is
it?
Is
it
should
it
be?
An
extension
of
DNS
there's
also
work
over
in
core
on
the
core
resource
directory
right
and
so,
in
my
opinion,
there's
make
two
problems.
One
is
the
service
by
some
metadata
and
there's
the
question
of
how
you
find
that
service
right
and
in
some
cases,
I
see
these
things.
K
These
functionalities,
merged
together
and
I,
really
think
there
should
be
a
two
separate
phase
with
authentication
in
between,
because
really
what
you
do
is
get
authenticated
information
to
data,
and
so
I
noticed
earlier.
Someone
is
saying
if
it's
published,
that
everyone
knows
about
it's
not
secret
anymore,
but
actually
even
like
a
address
as
a
name
temperature
sensor
got
got
that
local
is
a
leak
of
information
about
you
know,
what's
available
so
I
think
it's
extremely
important,
but
I
think
you
know
we
need
to
think
very
hard
about
where
it
belongs.
K
Maybe
it
shouldn't
be
in
this
group
because
maybe
it
shouldn't
be
dns-based,
we
should
be
a
new
thing.
Maybe
you
know
should
only
be
the
springboard
for
the
initial
introduction
to
to
a
controlled
surface,
so
I
think
I
think.
Maybe
we
need
to
think
of
this
as
a
higher
level
and
think
really
hard
about.
Where
did
belong.
A
group
should
be
chartered
to
do
a
privacy-preserving
discovery
service.
K
J
Come
on
back
so
I
think
this
working
group
does
valuable
work
and
we're
not
finished
with
this.
So
closing
it
down.
Right
now
would
just
doesn't
make
sense
and
my
my
view
I
think
there's
we
have
a
problem
with
the
lack
of
participation,
at
least
on
the
discussion
of
the
mailing
list.
I
mean
today,
I
think
we
got
got
a
good
discussion
here
on
the
things
we
bought
brought
up
on
the
agenda,
but
that's
yeah,
that's
I!
J
Guess
the
problem
and
the
question
is:
how
can
we
get
more
people,
maybe
also
from
different
angles
and
doing
different
stuff
to
to
notice
and
also
comment
on
the
work
which
is
done
here,
yeah
and
I?
Guess
after
all,
so
of
course
not
speaking
for
for
him,
but
I
think
Tom
didn't
actually
want
it.
The
working
group
to
shut
down,
but
just
to
give
wake-up
call
on
that.
That's
that
would
be
my
guess,
because
otherwise
I
don't
know
if
he
would
be
sitting
here
so
I
think
yeah.
J
It's
it's
once
again,
a
good
call
to
just
see
if
we
can
get
people
interested
in
what
we're
doing
here.
Maybe
they
don't
even
know
that
there
would
be
something
which
would
be
interesting
for
them
which
they
could
give
use.
The
question
I
cannot
answer
is
how
to
get
these
people
here
and
maybe
some
more
experience.
The
ITF
community
people
have
a
better
idea,
but
I
don't
know.
O
You're
agreeing
here
with
my
idiot
on
so
in
the
lack
of
interaction
about
the
privacy
is
kind
of
concerning
ap
to
see
that
five
people
IP
to
to
review
it.
So
there
will
be
a
good
sign
now.
Typically,
in
this
kind
of
document,
you
will
not
find
the
privacy
people
in
this
room,
but
in
other
rooms
the
document
can
stay
here,
but
making
some
publicity
on
this
document
in
other
working
group,
like
Brian,
will
do
on
deprive
in
a
couple
of
minutes
is
good.
B
The
we
we
have
tried
that
in
the
past,
IITs
starting
I
think
actually
Montreal
a
year
ago
and
didn't
get
that
much
support
from
like
other
people
in
this
community
or
so
in
the
ITF
community
at
large.
To
come
to
this
working
group.
Perhaps
one
of
the
reasons
is
that
they
care
about
privacy,
but
maybe
not
in
this
specific
context
that
then
I'm
speculating
at
that
point.
This
was
a.
H
Michael
Richardson
so
I'll
point
out
that
sag
is
happening
right
now.
Sorry
on
a
psychic
working
group,
the
security
area
where
you
can
group
is
right
now,
where
conflict
with
it.
Okay,
so
you
know
more
empty
chairs
than
full.
All
the
people
you
wanted.
Most
of
them
are
unless
they
came
here
because
they
you
know,
I
probably
would
have
gone
there,
but
I
thought
this
was
interesting.
I
was
unaware,
I
did
read,
Christians
documents,
I
have
a
vision
of
actually
thinking
about
it.
H
In
my
old
office,
which
I
haven't
been
to
in
two
years
so
I
mean
it
was
at
least
that
long
ago
I
was
unaware.
I
just
assumed
they'd
gone
to
last
call
and
gone.
It
I
was
unaware
that
they
were
stalled.
Okay,
so
I
would
support
the
comment
that
yeah
the
working
group
is
having
difficulties
and
but
I
don't
think
it's
time
to
give
up
at
this
point
and
let's
get
SRP
published,
there's
only
so
many
cycles
for
everybody
in
the
whole
and
the
whole
thing
and
I,
don't
think
so.
C
And
so
I
think
one
thing
that
we
were
probably
supposed
to
do
probably
me
was
to
take
Tom's
Charter
discussions
that
are
in
the
github
and
start
forwarding
them
around
to
the
group
to
look
into
potential
reach
our
during
language
to
explicitly
support
the
secure
the
privacy
efforts
here.
So
I
need
to
do
that.
So.
I
I
So
maybe
that's
a
good
thing
in
a
sense,
so
yeah
so
anyway.
The
other
thing
to
point
out
is
that
this
doesn't
have
to
happen
at
IETF
meetings.
So
one
of
the
things
we
can
do
and
I
think
I
might
take
this,
as
an
action
item
is
to
actually
present
something
about
this
unless
one
of
the
authors
wants
to
at
the
next
how
to
RS
c.
I
So
it's
not
because
I'm
not
interested
in
the
document-
and
you
know
I'm
not
saying
this-
to
blame
anybody,
because
I've
done
the
exact
same
thing
right,
like
I've,
been
busy
working
on
implementations
of
all
of
this
stuff
and
I
haven't
actually
updated
my
documents
as
frequently
as
might
have
been
desired.
So
we
I
think
that
we
have
a
lot
of
I
think
we
have
a
lot
of
expertise
in
this
room.
That's
related
to
the
problem
space
that
we're
talking
about.
It
would
be
ashamed
to
disband
that
expertise.
Expertise.
I
However,
I
think
that
the
clock
rate
of
this
working
group
is
not
three
times
a
year
and
part
of
the
reason
why
it
appears
that
there
isn't
energy
to
work.
Is
that
we're
just
not
working
that
fast?
It's
not
that
we're
not
working!
It's
not
that
we're
not
making
progress.
It's
just
that
we're
not
making
progress
on
a
pulse
rate
of
every
four
months,
so
I
think
that
that
that
mere
fact
is
not
a
reason
to
disband
the
working
group.
Thanks.
B
D
D
I,
like
those
suggestions,
I
like
what
I've
been
hearing
I,
think
Eric
right.
We
all
of
us
not
just
the
chairs-
need
to
figure
out
how
to
publicize
this
I
agree
with
what
Ted
said
that
giving
a
hot
RFC
torque
is
a
great
opportunity
on
Sunday
night
to
introduce
people,
and
you
said
you
already
listed
two
security
areas
as
a
conflict
which
is
good.
Let's,
if
we
decide
to
continue
for
next
time.
Let's
try
to
stress
that
more
with
the
IHG,
because
what
I
say
about
the
work
of
this
working
group
evolving
is.
D
We
have
solved
some
of
the
initial
challenges
of
less
reliance
on
multicast
and
more
reliable
discovery,
and
now
really
the
remaining
goal
we
have.
Is
this
privacy
work,
so
we've
almost
shifted
from
being
a
DNS
working
group
into
a
security
area.
Working
group
and
people
outside
this
group
have
no
way
of
knowing
that,
if
we
don't
tell
them
sure.
M
Well,
you
know
who
are
we
doing
this
for
and
then
made
me
think
about?
Well,
initially,
we
had
a
group
of
people
who
came
to
us
and
said
they
had
a
problem
to
be
solved
and
we
solved
it
and
we
those
people
are
gone.
Are
they
deploying
this?
Do
they
have
any
attention
to
play
it?
Are
they
asking
their
vendors
to
implement
it,
so
they
can
deploy
it
and
those
are
the
questions
that
I
think
we
need
to
answer
and
I
think
they're
still
unanswered.
B
I
Yeah,
just
one
thing
to
say
about
the
the
adoption
rate
is
that
if
nobody
is
using,
if,
if
there
isn't
a
device
that
can
consume
some
of
the
stuff
that
we've
designed
here,
then
there's
no
point
in
deploying
that
functionality
on
your
network.
Once
there
is
a
device
that
can
consume
that,
then
then
suddenly
it
becomes
more
worthwhile.
So
the
interest-
let's
see,
if
there's
additional
uptake
now
that
we
actually
have
DNS
Bush
in
iOS
and
Mac
OS
next
generation
and
actually.
B
D
Yeah
Ted
actually
mentioned
this
on
this
slide,
but
I
agree.
It's
worth
highlighting
it.
Ted
has
been
working
initially
as
a
contractor,
and
now
we've
moved
in
hiring
him
full
time.
Ted
has
been
working
at
Apple
implementing
this
work
in
Mac,
OS
and
iOS
and
I'm
not
leaking
any
secrets
there,
because
this
is
in
the
public
betas.
M
H
I
L
I
Did
it
I
did
a
print
print
out
over
the
internet
from
California?
My
printer
was
at
home
and
I
had
an
IOT
camera
pointing
at
it
I
printed
to
it,
and
the
little
page
came
out
and
everybody
was
all
excited.
That's
very
cool
I
just
wanted
to
mention
to
Tom's
point
that,
yes,
there
are
a
lot
of
implementations
of
various
hacks
that
purport
to
make
multicast
dns
work
on
multiple
links
and
our
experience
with
them
is
that
frequently
they
don't
work
at
all.
D
Yeah
I
just
want
to
expand
a
little
bit
on
the
funny
story
that
Ted
told
he
did
this
a
demo
for
the
guy
in
charge
of
our
department,
and
he
wouldn't
think
it
would
make
any
difference,
because
you
could
have
a
diagram
on
a
slide
with
with
boxes
and
arrows
and
things
and
saying
the
packets
go
here,
and
this
happens,
but
there's
something
about
the
showmanship.
So
Ted
Ted
had
the
live.
D
B
So
my
sense
is
to
keep
this
working
group
open.
Keep
the
mailing
list
open
and
then
maybe
we'll
have
a
shorter
meeting
in
Singapore
will
seem
by
the
time
we
get
there.
How
many
or
yeah
joint
with
home
net
that's
it'll
depend
on
what
we
get
on
the
agenda
so
to
our
authors.
Please
don't
wait
to
the
day
before
the
meeting
to
send
us
your
agenda
items.
That
would
be
particularly
helpful
in
scheduling
us
this
time
for
how
much
time
I
want
to
have.
L
L
I
B
And
so
to
wrap
up
I
think
we
got
a
sub
in,
for
we
got
a
good
information
about
the
two
upcoming
documents,
the
ones
that
are
almost
published,
so
we're
gonna
discuss
those
more
on
the
list
and
hopefully,
with
that
renewed
energy,
we're
going
to
get
them
published,
which
is
great
and
then
Christians
going
to
revive
the
privacy
of
Arvin's
document.
So
hopefully
we'll
actually
see
you
on
the
list
and
not
just
in
Singapore
and
hope
to
see
you
soon
there
thanks
for
coming
and.