►
From YouTube: IETF102-DNSSD-20180719-0930
Description
DNSSD meeting session at IETF102
2018/07/19 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
B
C
All
right
welcome
to
DNS
services
cover
e
at
ITF
102.
My
name
is
David
skinned
Ozzy,
our
chairs
are
Tim
Joan
and
myself.
Tim.
Couldn't
make
it
this
time,
sir
Tim,
when
since
key
is
deputizing
for
him
thanks
Tim,
first
and
foremost
they're
not
well,
given
that
it's
Thursday
morning,
you
probably
have
seen
it
by
now.
If
you
have
not,
please
take
the
time
to
look
it
up
and
read
it.
It
impacts
anything
you
say
can
have
patent
consequences.
So
please
read
this:
if
you
haven't
already.
C
Other
reminders
that
you
should
already
know
as
well
any
time
you
come
and
speak
at
the
mic.
Please
state
your
name
clearly
and
please
review
other
people's
documents.
What
helps
the
ITF
move
forward?
Is
people
reviewing
documents
and
providing
useful
input?
There
is
no
barrier.
There's
no
small
comment,
no
bad
question.
Please
read
the
documents
at
us,
even
if
it's
just
to
tell
us
that
they're
perfectly
fine
and
you
found
nothing
wrong
with
them.
That's
very
valuable
input.
C
C
C
C
These
are
the
links
for
our
working
group
materials
for
everything,
that's
going
on
and
a
quick
view
of
our
document
status.
We
have
quite
a
few
documents
going
on
in
the
working
group
will
actually
go
into
more
detail
in
all
of
them
and
it'll
be
in
a
bigger
font
which
will
make
it
easier
for
everyone.
C
C
We're
gonna
go
into
the
mdns
relay
and
service
registration,
we're
gonna
drill
down
a
bit
more
on
the
par
ship
we
have
with
core
and
how
we
can
interact
with
how
they
do
service
discovering
we're
gonna
spend
a
little
time
on
how
the
new
drafts
kind
of
all
the
pieces
fit
together
and
we're
gonna
have
a
good
part
of
the
session
on
DNS
as
the
privacy,
where
our
main
goal
is
to
each
consensus
on
what
the
requirements
are.
So
people
can
start
developing
solutions.
C
All
right,
actually
before
we
get
started,
would
anyone
who
was
at
the
hackathon
like
to
see
a
few
words
about
what
happened
there?
I.
D
D
Maybe
Tim
could
talk
about
it,
but
I'll
talk
about
it
first
and
then
you
can
talk
about
it.
Second
yeah
so
so
Tim
Tim
did
a
great
job
and
we
got
a
lot
of
good
feedback
on
the
Service
registration
protocol
document
as
a
result
of
that
which
has
been
ongoing
all
week.
So
the
the
hackathon
was
a
really
effective
way
of
stimulating
some
discussion.
E
Thanks,
yes,
Tim
wattenberg.
Actually
this
is
my
second
ITF
and
first
time
at
the
hackathon
and
I
came
there
knowing
basically
nothing
so
yeah
steward
and
that
guided
me
through
the
draft
and
by
the
end
of
the
weekend
we
had
something
working,
which
was
we
were
able
to
see
like
actually
working
and
for
the
rest
of
the
week.
I
continued
to
working
at
the
server
side,
so
maybe
you'll
have
some
running
code
there.
Also
in
the
next
week's
awesome.
D
F
F
F
Push
notifications
were
submitted
last
year.
We
did
working
group
last
call,
and
that
was
been
in
a
holding
pattern,
waiting
to
see
how
DSO
stabilized,
because
the
work
changes
in
DSO
now
one
of
the
changes
I
think
I
remember
was
we
removed
the
requirements
of
that
every
request
automatically
has
a
mandatory
reply,
even
when
the
replied
doesn't
carry
any
useful
information
and
that
simplified
the
push
notifications.
So
once
we
get
the
outcome
of
the
IFV
teller,
chats
I
propose
that
we
ask
for
an
ITF
last
call
on
this.
F
We
should
probably
review
it
within
the
working
group
to
make
sure
we're
all
happy
with
where
it
ended
up
discovery.
Proxy
has
been
through
working
group
last
call
it's
been
through
IETF
last
call
and
that
likewise
was
waiting
to
see
how
push
and
tear
so
stabilized.
So
once
we
get
the
green
light
from
the
isg
I
proposed
that
we
ask
publication
of
this
to.
G
Hybrid
we're
seeing,
in
my
cue
state
your
name:
terror,
no
I'm,
sorry
Terry,
mandersohn,
responsible
lady
over
from
sitting
in
my
queue
I
was
waiting,
obviously
on
a
whole
heap
of
other
things.
Following
a
discussion
that
I
had
with
Stuart
yesterday
about
35
minutes
ago,
I
approved
that
document.
Thank
you.
H
Two
comments
on
that:
the
teller
chat
is
August
2nd,
so
it's
right
at
the
beginning
of
the
month
right,
so
it's
gonna
happen.
Also
I
did
it
turns
out
I.
Did
the
Shepherd
write-up
for
Nina's
push
so
I'm
kind
of
glad
we
actually
going
to
review
it
because
that'll
allow
me
to
sort
of
review.
My
my
which
I
wrote
I
think
like
six
months
ago,
so
I
want
to
make
sure
that
everything
sort
of
current
as
well
so
and
and
I
can
sign
up
to
do
one
of
the
other
shepherd
write-ups.
I
F
Speaking
for
myself
in
the
next
couple
of
weeks,
my
plan
is
to
reread
all
of
these
in
their
entirety,
because
sometimes,
when
you
come
back
to
a
document
after
a
bit
of
a
break
and
read
it
with
a
fresh
eye,
you
you
see,
inconsistencies
or
ambiguities
in
it.
So
and
I
request
input
from
anybody
else
who
feels
inspired
to
do
the
same.
D
Okay,
so
I'm
here
to
talk
to
you
about
DNS
SD,
discover
DNS.
What
really
is
DNS
SD
discovery
really,
so
this
document
was
adopted
in
in
28
the
end
of
the
year.
We
finally
actually
submitted
a
0-0
in
May
since
then,
I've
been
doing
an
implementation
using
Apple's,
open-source
MBMS
responder
stuff,
and
that
was
really
fruitful
in
terms
of
finding
things
to
fix
both
in
the
both
in
the
in
the
real,
a
discovery,
real,
a
draft
and
also
in
the
DSO
draft.
D
Some
of
the
stuff
that
store
was
just
talking
about
actually
came
out
of
that
as
well.
So
this
is
actually
I
have
code
working
right
now.
The
code
is
not
a
full-blown
discovery
proxy
using
the
relay.
It's
just
essentially
a
client
of
the
relay.
That's
doing
DNS
discovery
over
the
relay,
so
I've
been
able
to
find
my
printer
in
the
in
the
Apple
UI,
while
traveling,
which
has
been
really
cool,
not
that
I've
printed
to.
J
D
So
so
the
document
is
pretty
solid
and
it's
in
last
call
the
big
changes
that
we've
done
to
the
document.
Previously
we
assumed
that
link,
configuration
stuff
would
be
out-of-band
and
it
turned
out
when
I
was
implementing
the
code,
that
that
was
really
not
fun,
and
so
so
I
added
support
for
in
band
signaling
of
links.
So
that
means
that
when
a
relay
discovers
that
a
link
is
present,
it
note
you
can
subscribe
as
the
client
of
the
relay.
D
D
So
you
got
a
complete
list
of
all
the
links
that
are
available
and
that
just
made
the
the
implementation
of
the
the
real
a
client
a
lot
easier
for
debugging
and
I
think
it's
also
useful
for
sort
of
the
ad
hoc
network
case
and
then
the
provisioning
vocabulary.
There's
there
was
a
whole
section
at
the
end
this
this
document,
when
I
started
out,
had
this
giant
section
on
how
to
provision
it.
That's
gotten
simpler
and
more
clear
over
time,
and
at
this
point
it's
it's
actually
quite
clear.
D
D
We
updated
that
to
talk
about
crypto
algorithm
lifetimes,
one
of
the
issues
with
crypto
algorithm
lifetimes
on
something
like
this
is
what
we're
trying
to
do
is
create
something
that
will
sit
in
a
device
that
you
buy
it'll,
be
on
a
rack
in
your
network,
closet
somewhere
and
hopefully
it'll
be
sitting
there
for
awhile,
because
you
don't
want
to
just
chuck
these
devices
every
five
years
and
what
that
means
is
that
you
may
have
some
software
on
there.
That
is
not
running
the
very
latest
crypto
algorithms.
D
So
your
TLS
connection,
the
the
connections
between
the
relay
and
the
client,
are
protected
using
TLS,
your
TLS
connection
might
be
using
not
the
most
recent
crypto
algorithms
and
you
still
probably
are
better
off
using
that
than
not
so.
We
also
took
out
layer,
two
source
address,
reporting
I
had
put
in
layers
layer,
two
source
address
reporting.
D
So
when
it
when
an
EM
DNS
message
comes
from
the
relay
to
the
discovery,
proxy
or
the
relay
client,
it
includes
the
IP
address
that
sent
it
and
it
was
supposed
to
include
the
layer
two
source
address
that
sent
it.
Of
course,
implementing
that
is
actually
hard
and
we
weren't
able
to
actually
articulate
a
reason
why
we
needed
it
and
since
we
weren't
able
to
articulate
a
reason
why
we
needed
it,
we
decided
to
take
it
out.
That
doesn't
mean
that
that
was
the
right
move.
So,
if
anybody's
listening
to
this
and
thinking
oh.
E
D
F
Stuart,
chair
sure,
I'll
say
a
couple
of
words
on
that,
because
it
was
me
that
advocated
for
taking
that
out,
it
was
in
the
draft
as
optional
and
I.
Don't
like
optional
things
in
specifications.
It
should
either
be
mandatory
or
not
they're.
Making
it
mandatory
was
tricky
because
not
all
platforms,
let
you
get
access
to
the
MAC
addresses
and
I
also
felt.
It
was
important
that
you,
when
you,
when
you're
tunneling
these
multicast
DNS
packets
over
TCP,
the
link
layer
technology
at
the
other
end,
might
not
be
Ethernet.
F
Now,
one
of
the
things
I'm
working
on
right
now
for
home
automation,
stuff
is
thread
which
is
an
industry
consortium
using
a
two
2.15
dot
for
radios,
and
there
may
be
other
technologies
as
well
and
then.
The
final
point
is
that
the
current
multicast
dns
code
on
Apple
products
and
as
far
as
I
know
other
things
like
a
ver.
He
don't
really
care
about
the
MAC
address,
so
when
I
put
it
all
together,
I
was
thinking.
Why
do
we
have
this
optional
thing
that
the
client
doesn't
even
use?
D
Everything
is
working
except
the
TLS
bit
and
the
TLS
bit
isn't
working
because
I
cared
more
about
getting
the
the
basic
stuff
going.
However,
there
is
a
certain
amount
of
funkiness
to
the
way
that
TLS
is
specified
in
this
document.
So
doing
the
TLS
implementation
is
actually
pretty
important,
so
also
I'm,
the
only
one
that
I
know
of
who's
implemented
this.
Unless
Tim
have
you
done
anything
on
this?
No
really,
no.
Okay,
sorry
tom
Tim
and
Tom
are
sitting
next
to
each
other.
D
So
it'd
be
great
to
have
a
second
implementation
of
this
just
so
we
can
make
sure
that
I
haven't
you
know.
I,
don't
have
any
blind
spots
that
are
represented
in
the
code
so
and,
as
I
said,
the
current
implementation
is
just
mdns
responder,
it's
not
the
discovery
proxy.
So
that
means
that
we
don't
actually
have
a
discovery
proxy
using
the
relay
right
now.
D
The
code
that
I'm
working
on
is
an
MBS
responder,
which
is
an
open
source
project
supported
by
Apple.
Releasing
code
is
slow,
but
we're
working
on
it,
and
so
that
will
be
out
at
some
point.
I
can't
tell
you
exactly
when,
because
I
don't
know,
and
if
you
are
interested
in
doing
interoperability
testing
on
this
stuff,
one
of
the
fun
things
about
it
is
that
interoperability
testing
over
the
Internet
is
very
doable.
In
fact,
I've
done
a
lot
of
my
testing
using
my
home
network,
while
I've
been
away.
D
D
H
Should
do
there?
One
comment:
I
noticed
it's
in
working
with
last
call,
but
there's
been
no
comments
on
the
mailing
list.
So
I
will
scold
you
because
I'm
not
really
your
chair
I
can
do
that,
get
away
with
it
so
and
also
I
just
signed
up
to
Shepherd
this
Dave
and
I
just
flip,
for
it
so
I'll
be
reviewing
it
as
well.
So
you
you're
lucky
guys
right
party
down
so
so
yes,
please,
please
folks,
read
it
and
sort
of
pass.
Some
comments
to
list
plus
or
minus
on
working
group
last
call.
C
Actually
could
I
have
a
show
of
hands
for
people
in
the
room
who
have
read
a
recent
version
of
the
draft
Thanks
so
for
people
who
haven't
it's
not
a
very
long
draft,
if
you
could
take
a
look,
that'd
be
helpful
and
for
those
of
you
who
have,
could
you
please
you
know
the
list
saying
like?
If
you
don't
have
any
comments
say
that
you
don't
have
any
comments
and
you
think
it's
fine.
That's
always
helpful.
D
Protocol,
okay,
so
the
next
document.
This
is
a
slightly
longer
presentation
because
we
actually
had
a
lot
of
turn
on
this
document
in
the
last
two
weeks.
So
the
document
was
expired,
that
we've
been
prioritizing
working
on
the
relay
document
and
the
relay
implementation,
but
we
really
wanted
to
get
it
going
for
this
ITF,
and
so
so.
I
got
a
bee
in
my
bonnet
and
did
a
pretty
major
update
of
the
document
right
before
the
deadline.
D
So
I
was
posted
prior
to
the
ITF
and
that's
the
one
that
that
if
you
haven't
been
following
the
mailing
list,
that's
probably
the
one
that
you
read.
There
was
a
ton
of
discussion
on
the
mailing
list
following
publication
of
the
oh
one
as
a
result
of
that
publication.
I
posted
a
second
update,
which
had
really
pretty
significant
changes
when
the
when
the
the
embargo
ended
and
oh,
this
is
the
old
version
of
the
slides.
D
Excellent
yeah,
so
right
so
so,
Tim
Battenberg
did
a
service
implementation,
and
so
we
posted
OH
on
Monday,
following
that
there
was
a
ton
of
discussion.
I've
actually
been
up
late,
two
nights
in
a
row
updating
the
the
github
version
of
the
document
to
track
the
discussion,
because
I
do
not
want
to
lose
all
the
discussion
we've
had.
It's
been
really
valuable.
Thank
you
all
for
for
doing
that.
So
the
call
for
adoption
is
under
way.
I
think
the
working
group
is
already
working
on
this
document,
but
that's
fine.
Hopefully
we
can
adopt
it.
D
I
think
that
the
evidence
of
all
the
the
churn
that's
been
going
on
is
evidence
that
the
working
group
wants
to
work
on
this.
But
if
you
objected,
this
would
be
a
good
time
to
say
so.
I
think
the
documents
actually
been
really
thoroughly
reviewed
if
it
weren't
for
the
fact
that
we
hadn't
adopted
it
yet
I'd
say
it
was
ready
for
publication.
D
Be
that
as
it
may,
there
are
still
things
to
talk
about.
So
let's
talk
about
them.
So
what
the
document
does
is
provide
a
lightweight
way
of
registering
services
in
the
actual
DNS.
As
opposed
to
mdns,
it
provides
a
way
of
authenticating
updates
so
that
if
you
have
successfully
published
a
name,
somebody
else
can't
come
along
and
override
your
publication
of
that
name.
This
is
cryptographically
authenticated
it's
first-come,
first-serve,
so
it's
not
actually
super
secure,
but
it's
secure
in
the
sense
that
it's
difficult
to
take
over
a
service.
D
Once
it's
been
established,
it
provides
garbage
collection
using
the.
We
have
a
companion
document
which
I
don't
actually
discuss
in
here,
but
it's
drafts
a
car
et
nsz
release,
or
something
like
that-
and
it's
mentioned
in
the
in
the
references
to
the
document,
and
actually
we
need
to
talk
about
that.
I
don't
have
it
on
the
slides,
but
that
document
is
required
for
this
document
to
happen.
A
D
That's
drafts
a
car
is
documents
the
the
the
IDI
and
s0
update
lease
option
and
then
update
lease
option
is
required
to
to
say
how
long
these
updates
last
so,
in
other
words
the
standard
DNS
update.
Just
you
do
the
update
and
it's
just
in
there
forever,
but
for
service
registration.
We
want
the
update
to
expire
after
a
while,
because
otherwise
you're
gonna
have
a
pile
of
garbage.
H
H
I'm,
sorry
yep,
so
we
can
probably
do
it
in
here,
because
I
believe
the
EDS
options
go
through
an
extra
review
anyway.
Yeah
yeah,
so
it'll
be
plan
to
do
it
in
here
and
and
at
that
point
you
know
we'll
get
the
DNS
off
folks
coming
out
without
sort
of
dragging
the
whole
working
group
through
it.
Okay,
so
well,
unless
Stuart
wants
to
do
something
different.
F
Well,
just
a
bit
of
trivia
for
Stuart
chair
shirt
from
airport.
We,
the
the
lease
update,
was
put
in
I
think
ten
years
ago,
when
Apple
used
it
for
the
back
to
my
Mac
service,
I
honor,
assigned
that
up
an
option
code
I
think
it's
number
two
I
think
we
have
the
first
two
Idina
zero
options,
one
and
two,
so
that's
already
recorded.
So
there's
no,
no
problem.
There.
A
C
D
K
In
carsten,
maybe
we'll
may
be
able
to
speak
this
more
eloquently
than
I
can.
But
there's
discussion
going
on
now
in
the
core
working
group
visa
vie
the
resourcedirectory
about
how
a
device
can
actually
assert
the
veracity
of
its
claim
that
it
provides
a
given
service,
and
so,
rather
than
rush
this,
you
know
to
finality
I
wonder
if
there's
any
support
in
this
group
for
investigating
this
question
now,
where
I'm
coming
from,
is
that
in
the
DMS?
K
As
we
know
it,
there's
always
been
a
human
in
the
loop
who
ensures,
let's
say
the
veracity
of
the
zone
file
and
then
DNS
SEC
is
all
about
making
sure
that
the
answers
you
know
the
you
know
the
responses
you're
getting
back
from
to
a
tool
to
a
query,
have
not
been
screwed
with
along
the
way,
but
you
know
we're
relying
on
the
human
in
the
first
place
to
make
sure
that
the
records
in
the
zone
file
are
accurate.
So
this
seems
to
me
a
related
problem.
K
D
I,
don't
question
so
so
you're
talking
about
the
enrollment
problem,
yeah
and
I
agree.
That's
an
issue.
The
document
actually
specifically
mentions
that
you
might
have
some
kind
of
enrollment
process.
It
doesn't
state
what
the
enrollment
process
is.
I
think
that
the
public
keys
that
we
use
here
would
be
the
sort
of
thing
that
you
would
probably
use
in
that
enrollment
process.
So
I
think
we're
okay
with
this
bit
here
and
I.
D
I
would
definitely
love
to
work
on
the
enrollment
problem,
because
I
think
that
it's
applicable
in
environments
like
home.
That's
also
so
it's
not
just
an
IOT
thing
but
and
in
fact
there's
work.
That's
happened
on
the
enrollment
problem
elsewhere,
like
I
think
thread
has
an
enrollment
process
and
I
know
that
anima
has
an
enrollment
process.
So
so
there's
you
know,
there's
there's
stuff
going
on
already
that
we
could
probably
leverage
I
hate
to
see
us
invent.
You
know
many
many
enrollment
processes,
but
you
know
see
Andrew.
L
Andrew
Sullivan,
so
I
agree
with
you,
I
I.
Don't
think
that
this
working
group
should
tackle
that
enrollment
problem
at
all
and
and
just
sort
of
incidentally,
it's
it
isn't
true
that
there
are
humans
involved
in
every
DNS
registration
right
that
isn't
true
for
many
many
years,
so
so
I
think
you're,
right,
I,
don't
believe
that
that
should
be
in
this
document.
I
think
you
know
you
should
say
exactly
what
the
document
says.
There
is
an
enrollment.
You
know
you
have
may
have
an
enrollment
problem
here
and
that's
none
of
our
business.
D
So,
just
to
continue
a
little
bit
on
this
since
we're
talking
about
constrained
devices.
One
of
the
things
that
we
wanted
in
this
is
a
feature
is
that
a
constrained
device
can
send
a
single
UDP
packet
that
registers
its
service,
and
so
so,
and
that
would
use
any
caste.
So
basically,
it
doesn't
have
to
go
out
and
figure
out
who
to
send
it
to
it.
Just
it
just
creates
the
registration
sends
it
to
the
anycast
address
and
on
a
constrained
network
that
supports
this.
D
Instead,
the
NSS
D
SRP
with
underscore
TCP,
so
that
we
have
that
taken
care
of
in
it.
We
talked
about
whether
we
wanted
to
have
a
specific
specific
registration
for
this
I
think
it's
useful
to
have,
but
we
can
discuss
that.
So
there
are
a
lot
of
issues
that
I'm
going
to
go
through
quickly.
If
these
ring
a
bell
for
you,
please
discuss.
D
If
not
it's
you
know,
we
we've
had
pretty
good
discussion
on
this,
so
one
of
the
things
about
this
protocol
is
that
it's
essentially
using
RFC
2136
DNS
update,
but
it
has
some
custom
semantics.
The
reason
it
has
custom
semantics
is
because
we're
allowing
unauthenticated
devices
to
register
themselves
in
the
DNS
here,
and
we
would
like
to
make
sure
that
we
don't
allow
arbitrary
registrations.
We
want
service
registrations,
and
so
when
a
DNS
update
comes
that's,
that's
that's
conforming
to
the
Service
registration
protocol.
Then
we're
essentially
saying
that
update
you
can
process.
D
D
So
the
issue
with
that
is
that
the
semantics
are
more
complicated
than
any
other
update
semantics
that
currently
exist
like
current
update
semantics
or
things
like
your
on
the
local
wire
or
you
have
this
key
or
there's
there's
one
that
allows
you
to
do
an
update.
If
you
have
a
particular
SIG's
Eero
key.
That
is
also
in
the
update
and
there's
another
one
I
think
that
uses
TCP
or
something.
D
So
there
are
a
number
of
different
ways
that
you
can
that,
for
example,
by
nine
will
it
will
allow
you
to
authenticate
updates,
which
I
suspect
to
exist
in
other
servers
that
I
don't
know
about.
So
this
is
a
much
heavier
piece
of
semantics,
and
so
either
we
need
a
shim
or
we
need
the
authoritative
DNS
server
to
have
some
pretty
hairy
semantics
in
it.
Pretty
hairy
just
means,
like
you
know,
there's
some
consistency,
checking
between
the
records
and
the
updates.
D
F
F
What
we
want
to
do
here
is
allow
you
to
buy
some
products
and
plug
it
into
the
network
and
without
any
prior
trust,
credentials.
Trust
it
to
do
some
updates,
and
once
it's
done
the
update,
it
also
puts
a
key
record
into
the
DNS
database
and
that
it
can
use
to
authenticate
subsequent
updates.
So
that's
how
it
claims
ownership
of
the
name
and
nobody
else
can
come
in
and
steal
it
later.
F
So,
if
we're
going
to
allow
this
on
trusted
device
to
do
updates,
we
need
some
kind
of
sanity
check
around
it.
What
I've
been
thinking
about
this
is
I
think
it
would
be
good
if
we
design
this
so
that
the
updates
that
a
device
generates
is
a
perfectly
valid
DNS
update.
That
would
work
with
a
normal
DNS
update
server,
so
you
can
take
find
nine
or
your
favorite
server
turn
on
DNS
update
and
these
devices
will
register.
F
What,
by
nine
won't
do
today
is
do
the
sanity,
checking
that
what
they're
registering
makes
sense
so
so
guarding
against
malicious
or
buggy
clients
becomes
a
feature
on
top
of
that,
but
basic
functionality
and
in
fact
that's
what
Tim
did
at
the
hackathon.
He
was
just
using
standard
by
nine
and
doing
updates,
and
as
long
as
his
updates
were
well-formed,
then
it
did
the
right
thing,
but
the
server
was
not
enforcing
that
yep.
I
D
So,
just
to
add
a
little
bit
to
that,
that's
that's.
That
was
a
great
way
of
introducing
or
explaining
that
the
one
of
the
things
that
we
don't
have
in
these
updates
is
update
constraints
and
the
reason
we
don't
have
update
constraints
is
because
the
way
update
constraints
are
normally
implemented.
Is
you
try
one
thing
see
if
it
works
and
then,
if
it
doesn't,
then
you
try
the
next
thing.
D
So,
in
other
words,
you
do
multiple
updates
and
we
were
trying
to
keep
this
down
to
a
single
update
if
possible,
and
in
order
to
do
that,
we
basically
put
the
the
burden
of
imposing
constraints
on
the
server.
So
if
you're
updating
a
regular,
RFC
2136
server,
then
you
would
need
to
do
something
a
little
different
than
what
you're
doing
on
a
on
an
SRP
capable
server.
So
another
thing
so
one
of
the
things
so
normally
with
DNS
SE,
with
DNS
st
updates.
D
What
you
do
is
you
go
out
and
you
look
for
dr
dot
underscore
DNS
st
domain,
and
you
use
that
to
figure
out
what
domain
to
send
your
registration
or
what
domain
to
to
register
your
your
service.
In
and
the
problem
with,
that
is
that
that's
a
lookup,
and
so
that's
you
know
if
you're,
if
you're
on
a
constrained
device
doing
a
lookup,
is
you
know
more
packets
that
you're
sending
and
shorter
battery
life?
D
D
And
then
that
just
seems
like
really
the
only
way
to
solve
that
problem
and
I.
Think
it's
pretty
easy
to
do
so.
I,
don't
I,
don't
think
it's
bad.
Obviously,
if
somebody
here
thinks
it's
bad,
you
should
let
us
know,
and
then
that
brings
up
a
second
issue,
which
is
that,
since
we
want
all
of
these
updates
to
go
in
a
single
packet,
if
there
were
a
PTR
update
or
sorry
a
reverse
zone,
name
update,
I'm,
realizing
as
I'm
saying
this
that
actually
this
is
not
important
anymore,
because
we
decided
we
weren't
having
the
client.
D
Do
the
reverse
zone
update
if
the
reversal
and
update
happens,
it's
the
server
that
does
it
so
I
guess
I
can
actually
skip
the
rest
of
this
slide
and
I
will
for
sake
of
time,
but
know
that
we
considered
that.
So
we
don't
support
the
ability
to
do
queries
that
will
allow
you
to
connect
to
something
that's
on
the
other
side
of
an
ad
and.
D
So
if
you
register
a
service
that
uses
an
ipv4
address,
then
it
will
only
be
reachable
if
its
global
or
if
you're,
within
the
same
RFC,
1918
routing
domain,
so
I
think
this
is
okay.
If
it's
not
okay,
we
could
talk
about
how
to
how
to
work
around
it.
In
fact,
there's
a
later
slide
that
talks
about
the
really
badass
registration
server
that
I
mentioned
here
so.
D
Another
issue
is
a
record
and
quad
a
record
security.
Do
we
want
to
enforce
that?
The
client
can
only
update
its
own
a
record
so,
in
other
words,
the
update.
If
the
update
comes
from
ipv4
address
and
it
updates
an
a
record,
the
a
record
has
to
contain
the
ipv4
address
that
the
update
came
from
and
similarly
for
an
ipv6
address.
D
Well
so
yeah
you
can't,
you
can't
develop,
you
can't
validate
reach
ability
without
doing
TCP
so
but
on
the
other
hand,
depending
on
like
if
this
is
on
a
constrained
network,
you
may
have
some
other
way
to
validate
that.
The
the
question
act
or
the
update
actually
came
from
the
IP
address
that
that
it
says
it
came
from
so
so
yeah
there
has
to
be.
In
order
for
this
to
be
at
all
useful.
There
has
to
be
a
way
to
validate
a
source
address.
D
M
B
M
D
D
Don't
want
to
get
too
deeply
into
this,
but
there
are.
There
are
actually
mechanisms
for
for
comparing
sources
in
HTTP,
and
so,
if
it's
an
HTTP
port,
that's
listening,
there's
actually
this.
This
could
potentially
be
used
to
get
access
to
the
user
interface
of
some
device
on
the
local
network
by
an
attacker
off
the
local
network,
and
so
so
that's
a
reason
that
I
would
suggest
that
we'd
actually
like
to
not
allow
updates
to
a
or
quad-a
records
if
they
don't
come
from
the
address
being
updated.
D
D
F
Stuart
ChaCha
I
think
I,
agree
agree
with
Mark
Andrews,
although
maybe
for
slightly
different
reasons.
I
think
the
simplicity
of
packing
everything
into
one
update
is
useful
for
constrained
devices,
and
we
need
to
weigh
that
up
against
an
analysis
of
what
the
threat
is.
If
some
rogue
device
creates
address
records
that
point
out
something
else
and
right
now
in
my
head,
I'm,
not
clear
on
what
that
downside
would
be,
it
sounds
like
you
are,
so
maybe
we
can
yeah.
C
Davis
can,
as
you
eat
your
hat
off.
I.
Think
I
really
agree
with
Ted
here.
If
it's
cheap
to
protect,
then
something
we
should
protect
against
it,
because
the
fact
that
we
haven't
thought
of
an
attack
doesn't
mean
it's
not.
It
doesn't
exist
and
I
do
agree
that
in
some
cases
this
might
be
too
expensive,
like
very
small
constrained
devices,
but
those
don't
need
to
advertise
for
addresses
they
just
used
up
one
and
they're
done.
Yeah
I
mean
you
know
there
any
devices.
That's.
D
D
D
We
might
we'll
talk
about
some.
We
might
relax
that,
but
but
this
is
what
it
says
now
service
instance
name,
you
can
only
add
an
S
RV
or
a
txt
record.
The
forward
mapping,
that
is
to
say
the
I,
think
the
name
that
that
we're
using
now
is
the
host
information.
Mapping
can
only
have
an
a
or
a
quad,
a
plus
a
key
record.
Was
there
one
other
record
that
you
thought
it
needed
to
be
able
to
have
Stuart.
D
Okay,
so,
and
then,
if
there's
a
reverse
mapping,
then
it
can
only
have
a
PTR
record
now,
there's
actually
since
I
made.
This
slide.
I
didn't
correct
this
on
this
slide
because
they
didn't
notice
it.
The
service
instance
name
actually
also
has
to
have
a
key
record
on
it,
and
the
reason
for
that
I'll
get
to
actually
I,
don't
know
if
I
don't
know.
If
I
talked
about
this,
but
but
in
first-come,
first-serve
naming
we
have
the
ability
to
add
a
record
to
have
a
record
that
just
has
a
key.
D
We
have
a
name
that
just
has
a
key
record
on
it
and
that
holds
the
name
prevents
somebody
else
from
from
claiming
that
name,
but
there's
no
service
advertisement
on
that
name.
Therefore,
a
service
like
if
you
have
a
printer,
that's
not
on
all
the
time.
Some
other
device
can't
come
along
and
claim
to
be
that
printer
and
take
over
that
printers
registration,
but
the
printer
doesn't
appear
in
the
in
the
list
of
printers
that
you
can
print
to
when
it's
not
turned
on
so.
D
Alright,
so
so,
basically,
there
are
consistency
checks.
The
service
name
has
to
be
pointing
to
a
service
instance
name,
that's
in
the
same
update.
So
if
you're
going
to
add
a
service
name,
if
you're
going
to
add
a
record
to
a
service
name,
then
then
it
has
to
be
a
record
that
is
referencing,
something
that's
also
in
the
update.
A
service
instance
name
has
to
point
to
a
forward
mapping.
D
If
there's
a
reverse
mapping,
it
has
to
point
to
a
forward
mapping,
but
now
we're
just
having
server
do
the
reverse
mappings
if
it
wants
to
so
the
benefit
of
this
is
that
the
updates
are
consistent.
The
disadvantage
is
that
we
don't
allow
random
updates,
may
be
the
limited
limitation
on
flexibility
could
be
relaxed
somewhat.
I,
don't
know
of
a
use
case
for
that
we
talked
about
just
having
a
simple
host
name
that
doesn't
have
any
service
registrations.
D
D
So
in
order
to
do
that,
IPS
or
type
ii
source
address,
address,
validation,
probably
isn't
work
end
to
end.
Although
we've
actually
part
of
my
problem
with
these,
this
presentation
is,
I
did
this
presentation
and
then
we
did
a
tremendous
amount
of
work
on
the
draft,
and
so
some
of
these
issues
have
actually
been
somewhat
addressed
and
I'm
thinking
maybe
this
issue
has
been
addressed.
D
D
D
D
D
If
that's
the
case,
then
discovery
proxies
the
way
discovery
proxies
work
is
that
each
link
has
its
own
subdomain
and
registration
protocol,
because
we
have
first-come,
first-serve
naming
we
have
a
way
to
disambiguate
names.
There's
there's
no
way
to
have
a
name
clash
with
first-come,
first-serve
naming
so
therefore
we
don't
actually
need
to
do
this.
This
one
subdomain
per
link
thing
in
fact,
it's
hard
to
do
so
right
now.
D
I
So
I
think
I
addressed
this
this
morning.
If
you
there
is,
because
you
can't
do
the
collision
stuff,
that
everyone
sees
it's
hidden,
there's
no
way
when
you
get
back
a
response
that
says
that
names
already
taken.
You
don't
know
what
name
to
use
next
to
try
next,
so
you
could
try.
You
could
try
incrementing
by
a
number
and
trying
again
and
again
and
again,
if
you've
got
20
devices,
you
try
20
times
that
doesn't
seem
good
for
battery
life
or
you
could
try
and
generate
some
unique
thing
from
the
beginning.
I
D
So
for
those
devices,
I
think
that
that
you're
gonna
wind
up
having
to
figure
out
a
way
to
I
mean
they're,
there's
no
way
to
avoid
having
the
user
have
some
kind
of
interaction
where
they
say.
Okay,
this
is
the
light
switch.
That's
on
the
wall
on
the
south
wall
downstairs
in
the
living
room
right.
That
step
has.
There
has
to
be
some
kind
of
enrollment
step
like
that,
in
order
for
because
otherwise,
you've
just
got
a
house
full
of
light
switches
and
like
somehow,
you
have
to
know
what
those
what
those
light
switches
are.
D
There's
got
to
be
a
user
interface
where
you're
configuring
all
of
this
stuff
and
if
there's
a
user
interface
where
you're
configuring
all
of
this
stuff,
then
the
only
real
question
is
whether
whether
we,
whether
the
mapping,
whether
the
name
change,
is
actually
a
name
change
on
the
device
or
whether
it's
a
name
change
that
the
network
remembers
and
the
device
doesn't
know
about
yeah.
Well,
if
you
you.
I
E
N
This
is
a
problem
on
that
I
think
we're
all
used
to
you
know:
Alexa
ABCD,
so
use
your
MAC
address,
use
whatever
it's
not
bad.
If
it's
only
four
digits
to
make
it,
you
know
and
big
you're
unambiguous.
It's
not
a
problem.
You
have
25
light
bulbs,
they
all
say
light
bulb.
You
know
so
you're
right.
They
have
to
be
paired
somehow.
The
question
is,
though,
how
you
mentioned
I.
Think
in
your
draft,
the
last
one
I
think
I
read
it
last
night
that
there's
no
delete
me
right.
E
N
D
N
So
that
device
needs
say
I'm
changing
my
name
delete
this
add
this
so
I
think
that's
a
real
strong
use
case
for
not
waiting
for
garbage
collection,
because
it's
going
to
just
clutter
the
namespace
for
a
day
or
two
until
it
goes
away.
The
other
issue
that
I
was
going
to
talk
about
earlier
is
replacement.
N
I,
know
I'm,
replacing
this
device
on
the
wall,
so
I
want
to
power
it
down
and
properly
not
unplug
it,
but
when
I
push
this
power
down
or
I
push
this
format,
but
not
push
the
format,
pin
and
I
clear
it
as
it
in
its
dying
breath.
It
says
to
you,
delete
me
now:
living
room
left
side
is
gone,
so
the
new
device
comes
in
and
it
claims
living
room
left
side.
So.
D
Yeah,
so
that's
that's!
That's
interesting!
I!
Don't
think
that
the
dying
breath
scenario
is
actually
realistic.
I
think
that
even
even
if
the
device
could
do
that,
what's
going
to
wind
up
happening
is
that
people
are
just
gonna
unscrew
the
light
bulb
and
chuck
it
they're,
not
gonna
they're
not
going
to
go
through
that
process.
So
that's
true
well
I'm,
where
it's
already
dead.
N
N
N
N
N
N
D
A
way
to
go
in
and
say
you
know,
delete
that
record
owned
by
a
different
group
to
be
clear,
I'm,
not
saying
you're
wrong,
and
we
shouldn't
have
the
delete
feature,
I'm
kind
of
leaning
in
the
direction
you
are
right
now,
so
so
I,
don't
I'm,
not
saying
no
I'm.
Just
saying
that
that
realistically,
you
probably
also
want
that
UI
right.
N
D
F
Thank
you,
Dave.
Those
are
some
good
comments,
in
fact,
I
think
there's
three
things
that
we
should
make
a
note
of
you
write
about
the
deletion
stuff
and,
in
fact,
using
apples
back
to
my
Mac
thing.
If
you
go
into
the
sharing
preferences
and
turn
the
surface
off,
it
does
do
a
DNS
update
to
delete
those
records
and
I
hadn't
realized.
Until
now
that
we
forgot
to
say
anything
about
that
in
the
document,
so
you
should
definitely
add
a
paragraph
or
two
about
doing
deletions.
F
Its
key
is
inside
that
device.
It's
gone
when
the
device
fails,
you
didn't
make
a
backup
of
it
on
the
USB
stick,
and
at
that
point
you
don't
wait
28
days
for
it
to
expire,
I
mean
if
all
else
fails.
I
guess
that's
the
backup.
Is
you
wait
28
days
for
it
to
expire,
but
but
having
a
quicker
way
to
go
and
delete
stuff
I
think
is
important
and
we
should
talk
about
that.
Yep.
M
Mike-
and
you
see
I
do
stuff
like
this,
with
update
all
the
time
where
you
have
an
administrative
key
yeah,
they
can
use
updating
in
Nuuk
anything
change.
Anything
and
you've
also
got
the
device
keys,
which
is
very
specific.
You
can
have
the
same
pot,
you
can
have
policy,
you
have
policies
tied
to
keys,
and
this
is
all
about
policy
in
the
syrup
in
the
nameserver
yep.
So
this
isn't
the
this.
This
is
a
sole
problem.
It's
been
sold
for
two
decades,
yep.
K
Then
I
just
want
to
clarify
my
earlier
remarkable
in
the
loop,
even
in
the
case
of
dynamic
DNS.
Typically,
the
human
has
delegated
the
authority
to
add
records
to
you
know
by
setting
up
a
security
Association
or
something
like
that.
So
that's
what
I
just
meant
by
you
know
human
in
the
loop.
So
here
obviously
the
problem
is
you
take
something
out
of
the
box?
You
know
how
do
you
trust
it
and
I'm
just
wondering
if
you've
looked
at,
you
know
maybe
weak
forms
of
authentication.
K
So,
for
example,
can
we
assume
that,
let's
say
it's
a
printer
is
trying
to
register
its
service?
Presumably
it's
already
participating
in
mdns
right.
So
is
it
on
the
link
in
defending
that
name
already
and
could
the
registration
server
like
make
use
of
this
fact?
How
does
that?
How
does
that
change
the
security,
but.
K
D
We
actually
did
here
was
try
to
replicate
the
security
of
mdns
in
a
network.
That's
not
a
single
link
yeah,
so
so
I.
Don't
think
that
that
particular
solution
solves
the
problem.
I
think
is
an
interesting
question,
but
I
again,
as
Andrew
was
saying,
I
think
it's
a
separate
problem,
so
so
I
don't
think
we
should
muddy
the
waters
here.
D
I
think
that
you
know,
for
example,
if
you
the
document
actually
talks
about,
you
could
have
a
domain
where
devices
you've
never
heard
of
get
registered
automatically
and
then
once
you
once
you
and
and
and
so
you
might
have
a
little
app
on
your
phone,
that
gets
a
notification.
A
new
device
came
on
the
network.
Now
you
remember
that
you
just
plugged
in
a
new
device
and
gosh
it's
that
device,
so
you
say
okay
authorized
and
then
it
automatically
is
put
in
the
zone
of
things
that
can
be
discovered,
but
until
then
it's
not
discoverable.
K
D
F
Dave
pointed
out
that
you
have
cut
the
mic
line,
but
if
you'd
like
can
I
respond
to
this,
so
one
aspect
to
this
is
I.
Imagine
new
classes
of
devices
and
new
network
environments
where
we
will
only
be
doing
the
active
registrations
and
we
won't
be
doing
well
to
cast
DNS
at
all
and
the
one
case
that
I'm
particularly
thinking
about
right
now
is
this
thread
group
wireless
mesh
network
and
on
low
power,
low
speed,
short-range
wireless
devices
with
battery
power.
F
You,
yes,
you
can
build
a
multicast
distribution
protocol
that
floods
the
multicast
everywhere,
and
you
can
make
that
work,
but
it's
not
clear
that
you
would
want
to
so.
If
we're
successful,
what
I
imagine
happening
is
that
thread
networks
will
only
use
Service
registration
protocol.
I
could
also
imagine
in
things
like
building
automation,
environments,
even
though
you
have
Ethernet
and
you
could
be
using
multicast
DNS.
D
D
D
I'm
sure
there
is
one
I
think
that
personally
I
think
the
answer
to
that
is
just
have
a
common
qubit
between
devices
that's
shared
so
but
I
mentioned
this
I,
don't
think
we
should
talk
about
it
now
because
I
think
we're
a
little
short
on
time,
but
think
about
that.
If
you
think
there's
a
use
case
here
or
send
me,
some
email
send
mail
to
the
mailing
list,
not
just
to
me
so
next
steps,
as
I
said
earlier,
despite
being
called
for
adoption,
I
think
this
is
actually
pretty
close
to
ready
to
publish.
D
I
The
FCFS
stuff
is,
is,
you
know,
I
think
it's
clever
and
it
solves
a
real
problem
here,
but
I
sort
of
think
that
67-63
already
defines
Service
registration
protocol
as
dynamic,
DNS
update
and
so
I
think
that
this
confuses
things
with
that
and
I
think
that
if
we
would
change
the
name
of
this,
then
I
would
fully
support
adoption
and
I
think
a
name,
something
like
a
dynamic
update
protocol.
I'm,
sorry,
dynamic,
update
profile
for
constrained
services
would
be
a
better
name
for
it,
because
it's
really
just
a
profile
of
dynamic
update.
I
I
C
H
Make
this
quick,
Tim
ocinski
supported
options,
send
an
email
about
it.
I
made
one
comment
that
you'll
want
to
address
the
underscore
at
a
relief
work
that
Dave
Crocker's
been
doing
just
to
make
sure
that
we're
all
covered
I,
don't
think
I,
don't
think
guys
cover
it,
but
I
think
that's
gonna,
because
that
stuff's
moving
through
working
group
last
call
right
now.
So
just
I
made
a.
H
M
C
So
from
the
interest
on
the
list
and
in
person,
it
sounds
like
there's
interest
to
working
on
this
in
the
working
group.
The
adoption
call
goes
until
next
week.
If
anyone
thinks
that
this
should
not
be
adopted
by
the
working
group,
please
bring
that
to
the
list,
otherwise
we're
probably
going
to
be
leaning
towards
adoption.
Also,
if
you
do
support
adoption,
please
say
so.
That
would
be
helpful
as
well.
K
Good
mornin,
Carolyn
and
I
am
presenting
a
proposal
for
mapping
between
information
in
the
core
resource
directory
and
DNS
SD
on
behalf
of
my
other
co-authors.
So
first
question
that
might
occur
is
why
do
we
care
about
this?
The
first
simple
answer
is
that,
as
part
of
course
Charter
that
they
should
interoperate
with
the
DNS
I
find
myself
in
an
interesting
position
of
trying
to
convince
the
core
people
that
they
should
care
about,
DNS
at
all
and
convincing
the
DNS
as
deep
folks
that
core
resource
directory
is
not
going
away
anytime
soon.
K
So
it
helps
to
talk
about
a
couple
of
use
cases
that
I
see
I'm
sure
there
are
many
more,
but
in
the
case
where
we
have
where
we
assume
that
co-op
clients
will
not
be
all-pervasive
anytime
soon,
and
we
want
to
support
heterogeneous
environments
that
make
use
of
an
edge
device
called
the
cross
proxy
that
support
HTTP
clients
and
co-op
servers.
It
may
be
more
natural
for
the
clients
to
be
existing
in
a
DNS,
SD
kind
of
environment.
K
I
should
pop
up
and
say
that
there's
kind
of
a
meta
question
here,
I'll
talk
a
little
bit
about
rest
and
core
and
that
sort
of
thing,
but
primarily
resource
discovery,
is
concerned
with
very
fine-grained
discovery
about
what
resources
exists
in
in
a
core
server,
which
is
typically
a
web
server
or
very
much
like
web
server.
I
would
say
that
some
subset
of
resources
can
be
considered
services
in
that
they
are
restful
entry
points.
So
that's
kind
of
the
starting
point
for
this
whole
effort.
K
K
The
basic
paradigm
is,
it
supports
rest
over
UDP,
but
now
there
are
other
bindings
such
as
WebSockets
TLS,
that
sort
of
thing,
if
you're
arrested
hearin
that
you
know
that
rest
really
is
a
set
of
architectural
constraints.
The
basic
operations
are
create,
read,
update,
delete
and
notify
crucially
court.
Our
coop
does
support
notify
in
that
it
supports.
You
know,
sort
of
a
an
observe
pattern,
so
you
can
be
notified
of
changes
in
the
resource
and
this
provides
for
a
kind
of
a
a
a
weak
consistency
of
state
throughout
a
distributed
system.
K
All
the
transactions
between
the
client
and
server
are
stateless.
Everything
is
a
resource,
as
I
said
it's
identified
by
URI
and
other
made
it
in
a
metadata,
such
as
content
type,
and
when
we
talk
about
say
a
restful
entry
point
for
an
API.
Typically,
you'll
have
a
link
that
gets
you
to
that
API
and
then
you
can
explore
the
other
degrees
of
freedom.
The
other
things
that
you
can
access
in
that
API
through
other
links
that
are
provided
to
you,
where
a
link
is
essentially
a
uri
+
metadata.
K
So
core
resource
discovery
is
based
on
web.
Linking
there
is
a
sort
of
a
foundational
RFC
80
to
88,
on
which
the
core
web
linking
is
based.
As
I
said,
a
link
is
basically
a
you
are
I,
plus
other
metadata
attributes.
Crucially,
it
typically
involves
a
link
relation
to
tell
you
what
you
will
what
you
will
get
when
you
follow
that
link,
so
it's
identified
by
a
piece
of
metadata
and
for
m2m
transactions.
The
link
relations
are
pretty
much
all
you
have
for
for
driving
state
in
the
system.
K
So
what
we're
proposing
is
that
in
the
case
where
you
have
a
core
device
that
wants
to
export
information
to
the
Rd,
we
will
add
a
new
resource
that
provides
hints
for
some
mechanical
translation
or
mechanical
export.
So
currently
defined
attributes
in
66
90
include
the
resource
type,
the
if'
attribute,
which
is
typically
a
URI.
Some
sort
of
formal
description
like
a
waddle
or
a
hyper
schema
the
size
of
the
thing
and
we're
proposing
some
new
target
attributes
in
our
proposal.
So
exp
is
a
is
right
now
defined
as
a
binary.
K
That
would
indicate
that
we
want
to
export
this
data
instance
name
as
we
define
it
in
R,
as
its
defined
currently
in
the
proposal
is
much
like
the
instance.
In
the
service
instance,
the
instance
portion
of
the
service
instance
name
in
DNS
SD,
except
that
now
you
know
talking
to
other
folks
in
core
that
wasn't
the
original
design
of
I&S.
K
So
we
may
have
to
do
some
things
to
make
that
unique
in
the
namespace,
the
DNS
SD
namespace
will
take
resource
type
and
somehow
translate
that
into
service
type,
and
we
feel
that
you
know
having
the
if'
is
important,
because
that
provides
you
information
about
the
API.
So
this
is
the
rough
proposal
for
how
to
do
this
translation.
K
The
inss
resource
will
provide
at
least
a
foundation
for
the
instance
part
of
the
service
instance
name.
It
may
be
that
we
also
ultimately
include
this
other
piece
of
metadata,
which
is
called
the
endpoint
name
and
somehow
you
know
munge
those
two
things
together
to
create
a
unique
instance
for
dns
SD.
K
Similarly,
similarly,
the
resource
type
is
converted
somehow
into
a
unique
service.
Type.
I
should
just
make
a
side
point
here
that,
while
DNS
SD
provides
for
pretty
strict
limits
on
things
like
the
length
of
a
label
and
the
the
alphabet
that
can
be
used,
the
format
doesn't
seem
like
web
linking
in
core
actually
provides
for
such
constraints,
and
it
seems
to
be
an
S
do
by
sto
decision
as
to
whether
they're
gonna
limit
the
lengths
of
these
things
and
which
you
know
which
character
sets
they
can
use.
K
K
So
one
of
the
team
e
DS
is
how
do
you
figure
out
which
domain
in
which
to
locate
the
devices
Stuart
and
I
have
talked
about
this
there's
actually
a
reference
in
the
draft
to
section
11
of
63-67
63,
where,
for
example,
it
says
you
could
discover
you
know
which,
which
domain
you're
currently
in
on
your
link
and
put
the
records
there.
So
it's
essentially
could
be
a
local
matter
or
we
could
take
some
additional
steps
to
constrain
that.
K
So
this
is
just
a
color-coded
example
to
show
how
you
start
with
a
mechanical
translator.
It
could
start
with
a
query
to
the
core
system
and
it
can
basically
search
for
servers
that
have
this
exp
attribute
set
to
true,
and
it
might,
for
example,
get
back
a
response
from
a
device
with
this
address
that
says
that
it
supports
a
temperature
sensor
at
this
path.
K
The
resource
type
is
this
the
instance
is
set
to
this,
and
you
could
find
some
information
on
the
interface
description
here
and
the
resulting
R
RS
would
look
something
like
this
any
place
where
you
see
an
ellipsis
just
replace
that
with
example.com
dot.
We
just
admitted
that
for
brevity,
but
basically,
if
you
follow
the
colors
and
you're,
not
colorblind,
you
can
see
how
these
translations
occur.
K
One
thing
I'd
like
to
point
out
here
is
when
we're
building
the
service
instance
name,
there's
sort
of
two
ways:
we
could
go
about
it,
assuming
that
we
start
with
resource
type
as
the
base.
We
could
either
sort
of
have
a
flat
service
type
for
each
resource
type
or
we
could
do
it
in
a
hierarchical
fashion,
where
we
basically
have
you
know
kind
of
a
base
organization,
that's
responsible
for
creating
its
own
types
of
labels
and
do
this
in
a
hierarchical
fashion.
K
I
should
say
that,
for
example,
broadband
form
I
believe,
has
done
something
along
these
lines
and
where
they've
got
say,
multiple
different
bindings,
WebSockets
TCP
UDP.
They
actually
use
this
label
to
express
more
information
about
the
protocol
stack
and
this
part
to
to
describe
the
actual
service,
that's
being
it's
being
exposed.
So
that's,
basically
the
idea.
O
Dave
Taylor,
so
first
I'll
just
summarize
the
issue
that
was
brought
up
in
the
core
one
and
then
I'll
offer
maybe
an
idea
that
augment
that,
since
what
I've
been
thinking
about
so
the
issue
that
we
talked
about
in
core
is
coming
up
with
the
underscore
OIC
dot
label
is
really
hard.
In
some
cases
they
are
t-value
on
the
top
could
be
a
string
like
OIC,
dot,
r
dot
temperature
or
it
could
be
any
uri.
And
so,
when
you
have
that
flexibility,
then
it's
really
difficult
to
come
up
with
the
underscore
oh
I
see.
O
So
that
was
the
discussion.
We
said,
there's
an
issue
to
be
discussed.
We
said,
take
it
to
the
list.
I
started
a
list
discussion
and
so
on.
So
what
I'm
thinking
about
now
is
you're
presenting
this
is:
is
there
any
value
in
having
per
organization
underscore
I
see
dot,
or
should
we
just
define
an
underscore
resourcedirectory
dot
and
just
lump
everything
into
the
part
where
you
have
our
temperature,
where
you
have
a
lot
more
flexibility?
That's
there!
O
So
because
you
don't
need
to
enter
registration,
you
could
do
you
know
hashes
or
whatever
else,
to
deal
with
lengths
and
encoding,
and
you
wouldn't
need
to
worry
about
how
do
I
met.
But
this
thing
that
has
to
be
ini
registered,
that's
underscore,
I
see
if
you
just
define
one.
You
said
everything
that's
in
their
butts
coming
through
this
conversion.
Sure
that's
what
I
show
take
your
points
Warner!
It's
that.
K
Take
your
points
one
at
a
time.
The
first
is
that
sixty
six
ninety
was
actually
the
first
output
of
the
core
working
group,
and
so
that
definition
for
resource
type,
which
includes
any
arbitrary
URI
as
a
value,
was
basically
specified
before
there
was
any
operational
experience
with
coop
at
all,
and
so
I'm
I've
actually
talked
to
a
few
people.
Nobody
knows
of
anyone
who's
using
it.
In
that
way,
I
would
propose
that
you
know
there
was
actually
also
some
discussion.
K
That's
in
the
working
group
that
said
now
might
be
a
good
time
to
sort
of
tighten
up
the
definition
of
some
of
these.
You
know
metadata
the
values
of
some
of
these
metadata
attributes,
and
so
I
mean
we
certainly
have
no
shortage
of
attribute
names.
We
could
define
an
RTI
if
you
need
an
arbitrary
URI
and
we
also
have
the
the
AF
attribute
that
could
take
an
arbitrary
URI
that
describes.
You
know
the
resource
as
well.
So
I
don't
know
in
the
general
case.
K
Second
point
you
made,
which
was
why
break?
Why
break
this
up
rather
than
doing
one
flat
service
type?
The
one
thing
that
you
need
to
express
in
the
whole
service
instance
name
is
the
entire
protocol
stack
as
well
as
the
service
that
you're
exporting
and
so
I.
Guess
to
me
it's
a
little
easier
doing
it
this
way
to
use
the
main
service
type
label
here
it's
underscore
oh
I,
see
but
broadband
forum.
For
example.
A
K
I'm
trying
to
just
say
that,
at
the
end
of
the
day,
if
you're
trying
to
you
know
sort
of
figure
out
where's
the
semantic
alignment
between
work,
what
core
is
doing
and
what
DNS
SD
is
doing.
We
have
this
notion
of
services
and
service
types
right,
but
at
the
end
of
the
day
you
need
to
be
able
to
sort
of
express
the
whole
protocol
binding
in
there.
A
service
in
my
definition
would
be.
K
You
know
the
end
point
where
you
can
find
the
listening
sock
at
the
IP
address,
that
the
port
and
and
basically
the
protocol
that
you're,
talking
or
protocol
is
kind
of
the
entire
stack.
So
there
doesn't
have
to
be
a
one-to-one
there's,
not
a
direct
correlation,
but
I'm
saying
we
can
take
one
and
translate
it
into
the
other.
H
P
So
yeah,
as
a
Korean
I
have
discussed,
broadband
form
does
have
some
use
of
coop
where
it
has
some
registrations
and
things,
and
we
want
to
make
absolutely
sure
that
those
uses
are
not
impacted
by
anything
that
the
core
working
group
decides
to
do
and
that
we
don't
suddenly
have
to
do
something
special
or
that
certain
weirdness
is
going
to
happen.
And
so
I
really
want
to
make
sure
that
it's
somehow
you
know
which
devices
are
going
to
do.
P
H
Young
Barbara
anymore,
fine,
okay,
okay,
okay
and
Tim,
with
Sinskey
DNS
op,
co-chair
I
just
want
to
make
you
all,
and
you
may
be
aware
this.
We
have
a
draft.
That's
in
working,
that's
finishing
up!
Working
good
last
call
that
Dave
Crocker's
worked
on
for
the
past
year
or
so
that
addresses
underscore
labeling
in
DNS
names
and
actually
builds
a
whole
I
in
a
registry.
H
So-
and
this
is
gonna-
start
filtering
through
the
IETF
very
soon
so
people
will
want
to
sort
of,
and
he
actually
has
another
one
that
basically
fixes
up
tax
records,
SRV
records
and
give
guidance
into
how
these
things
should
be
sort
of
scoped
and
stuff.
And
so
these
are
sure
gonna
be
roll
through
is
BCP
and
you're.
Probably
aware
of
that.
H
But
I
just
wanted
to
make
sure
that
you
know-
and
this
is
for
Dave
the
chair-
that
as
these-
if
these
documents
come
up,
that
basically
people
pay
attention
to
that
right
so
and
the
appropriate
reference
and
stuff
like
that.
But
there's
gonna
be
a
Hawaiian
or
registry
to
sort
of
scope,
all
those
out
and
make
sure
people
are
sort
of
paying
attention
to
that
awesome.
Wow.
H
K
H
K
C
K
Q
Custom
one
one
of
the
co-chairs
so
I
think
what
we
are
seeing
here
is
it's
just
an
instance
of
the
slight
impedance
mismatch
between
service
discovery
and
resource
discovery,
and
on
the
DNS
side
the
idea
was
to
have
services
that
that
are
registered
on
the
call
side.
We
said:
oh
there's
such
a
wide
variety
of
services.
We
want
to
provide
both
registered
services,
which
is,
of
course,
what
the
stos
are
going
for
at
the
moment.
Q
So
that's
all
we
are
seeing
because
we're
seeing
SEO
documents
and
EDD,
but
everybody
can
make
up
their
own
service
terms
and
that's
what
we
have
the
UI
side
for
so
the
fact
that
there
are
no
sta.
Oh
it's
the
or
documents
using
the
UI
form
of
resource
types,
that's
just
magic
of
that
they
were
not
made
for
cos.
They
were
made
for
people
who
just
want
to
build
something.
So
given
that
dependence
mismatch
just
sounds
right
for
me
to
say:
okay,
that
there
may
be
some
resources.
Q
We
just
can't
map
so
Diaz
Dennis
and
once
that
that
use
a
resource
tribe
that
is
not
registered,
may
belong
to
attach.
And
the
other
question
is:
how
do
we
map
synchronize,
whatever
these
two
registries
and
yeah?
We
need
an
answer
to
that
and
the
answer
also
may
be
guided
by
the
fact
that
there
is
an
impedance
mismatch.
Q
So
not
everything
that
is
registered
on
the
call
side
may
need
to
be
registered
on
the
DNS
side
as
well,
so
that
we
don't
have
to
fulfill
the
requirement
that
everything
translates
and,
of
course,
then
there's
also
the
X
bit
that
you
can
use
to
control
this
some
more.
But
if
somebody
said
sets
the
X
bit
on
something,
that's
not
translatable
restriction
options
that.
C
N
Sneaks
in
there's
the
second
day
anyway,
I
have
a
problem
with
using
RT
as
a
service
at
all,
just
an
in
concept.
Resource
type
is
a
very
fine-grained
thing
and
service
discovery
should
be
I
want
to
find
thermostats
I,
don't
want
to
find
the
unoccupied
holiday
set
point
for
low
humidity.
That
just
doesn't
make
sense,
so
you
don't
explore
everything
so
yeah
right
and
so
right.
N
N
C
O
O
O
Line
back
to
say
was:
if
you
draw
an
elegy,
if
you
look
at
where
I
F
equals
you
Co
the
part,
that's
in
yellowish-orange
right.
That
could
also
be
a
URI
right
and
yep
you're
sticking
that
into
a
text
record
right
and
so
the
text
records
are
used
for
filtering
after
you
get
the
stuff
back
right.
The
client
can
look
through
and
say:
oh
yes,
I
know
how
to
do
this,
I
could
do
filtering.
I
could
do
use
of
them
whatever
it
is
right.
O
O
If
you
wanted
to
do
that
right,
because
that's
one
of
the
limitations
of
DNS
right
and
so
what
I'm
saying
is
you
could
take
the
full
arty
value,
even
if
it's
a
URI
and
stick
it
into
a
text
record
now
you
lose
some
efficiency,
so
you
said:
how
good
can
you
get
at
filtering
by
putting
it
into
the
name?
And
that's
where
your
are?
O
Temperature
comes
from,
and
you
start
off
by
saying:
oh,
but
there's
some
really
complex,
because
different
organizations
have
long
lengths
that
they
have
different
character
sets
and
so
on,
and
and
what
I
meant
to
say
is
that
if
you
can
deal
with
all
that
complexity,
dealing
with
your
eyes
is
not
that
much
extra.
So
when
I
said
it
could
be
something
out
of
the
art
temperature
you'd
like
that
to
be
readable.
But
if
you
can't
make
it
be,
you
know
a
hex,
encoded,
hash
or
something
else.
O
O
F
F
Has
some
impact
on
debugging
when
you're
looking
in
Wireshark-
and
you
said
you
could
you
don't
know
what
it
means?
The
reason
I
came
to
the
microphone
is
Dave
said
earlier.
Rt
has
nothing
to
do
with
protocol
and
there's
a
bunch
of
people
nodding,
and
it
made
me
realize
that
maybe
I'm
confused
about
what
the
resource
type
is
so
so
maybe
mapping
resource
type
to
the
service
type
or
the
subtype
isn't
the
right
thing,
because
at
the
discovery,
filtering
level
so
I'll
take
an
example.
F
I
have
a
thermostat
at
home,
that's
in
the
hallway,
but
maybe
I
don't
want
it
to
be
adjusting
the
temperature
based
on
the
hallway
I
want
it
to
be
using
the
temperature
in
the
bedroom
or
somewhere
else.
So
having
a
way
that
that
thermostat
can
discover
on
the
network.
Find
me
the
list
of
things
that
can
report
temperature
and
I
will
then
use
those
things
to
control
the
heating
and
cooling.
That
is
the
semantics
of
what
you
want
to
do
by
service
discovering
and
in
the
example
you
give
that
the
R
T
is
temperature.
F
K
Really
should
take
it
to
the
lists
again.
My
starting
point
was
the
kinds
of
things
that
should
be
exported
are
really
entry
points
to
restful
api
s,
which
implies
that
you
know
you
know
not
only
start
off
with
a
given.
You
know
with
a
starting
path,
but
that
you
can
discover
other
links
from
that
starting
path
that
will
give
you.
You
know
all
the
information
about
that
anyway.
Thanks
for
the
conversation,
Thank
You
Kari,.
F
I
am
Stuart
Cheshire
still.
If
anybody
forgot
that
Christian
who
eaten
when
was
going
to
be
presenting
this,
unfortunately,
he
had
the
death
in
the
family.
He
is
attending
to
that.
So
I
am
here
standing
in
for
Christian
I
hope
we
also
have
Daniel
Kaiser
on
yes
remote
participation,
because
Daniel
has
been
doing
some
work
with
Christian
on
this
too.
So
Daniel
feel
free
to
jump
in
with
comments.
If
you
have
any.
F
This
started
off
a
while
back
with
an
initial
solution
by
Christian
and
Daniel,
and
I
should
start
by
explaining
why
we
care
about
this
when,
when
serve
discovery,
started
and
back
in
the
days
of
Apple
talk
the
fact
that
you
could
discover
stuff
on
the
network
and
connect
to
it
at
all
was
kind
of
remarkable
and
back
then
in
the
80s.
Nobody
was
really
thinking
very
much
about
privacy.
Laptop
computers
didn't
exist,
certainly
phones
with
Wi-Fi
didn't
exist
in
today's
world.
F
David
has
been
asking
every
opportunity
gets
this
week
for
people
who
care
about
privacy
to
come
and
participate,
so
I
hope
we
have
some
of
some
of
you
guys
here,
because
this
is
really
important.
I
do
not
pretend
that
I
know
what
the
answers
are:
I'm,
hoping
that
collectively
we
can
put
our
heads
together
and
work
out
ways
to
solve
this.
Christian
and
Daniel
started
off
with
a
proposal
for
this.
F
F
F
F
The
client
using
that
service
may
not
want
to
disclose
the
fact
that
they
are
making
use
of
that
service
and
the
queries
that
you
broadcast
may
give
some
cues
about
what
you're
doing
in
one
of
the
previous
working
groups
this
week.
I
remember
somebody
talking
about.
In
fact,
I
was
in
home
net
talking
about
not
advertising
the
SSID
of
their
home
network,
because
that
gives
them
better
privacy.
F
What
they
may
not
realize
is
that,
if
you
do
that,
then
your
phone
then
goes
around
broadcasting.
The
name
of
the
SSA
ID
that
it's
looking
for
everywhere.
You
go
so
within
a
hundred
meters
of
your
house.
Your
SS
city
might
be
private,
but
everywhere
else
on
the
planet,
you're
going
you're
telling
everybody
the
name
of
your
home
network,
so
the
there's
the
flip
side
of
privacy.
Is
you
end
up
exposing
stuff,
the
other
somewhere
else,
if
you're,
not
careful.
F
So
the
fact
that
the
client
is
looking
for
a
particular
type
of
service
may
be
something
we
don't
want
to
reveal.
One
of
the
examples
I
gave.
In
fact
it's
not
this
example,
but
a
similar
one
is
medical
devices.
There's
there's
a
growing
business
in
medical
devices
that
talk
to
an
app
on
your
smartphone
and
I
may
not
want
my
phone
broadcasting
to
everybody
within
rain
that
it's
looking
for
a
a
blood
sugar
monitor
for
treating
diabetes
or
some
other
medical
device.
F
F
Another
example
similar
to
the
medical
device
thing
here:
we've
got
a
watch
and
the
phone,
but
the
same
kind
of
thing
applies
that
we
don't
the
watch
broadcasting
I'm
looking
for
Stewart
treasures,
iPhone
at
the
hackathon
this
week,
I
noticed
that
somebody
was
running
a
piece
of
software
called
handy
print
on
their
Mac,
which
is
a
useful
bit
of
software
from
a
few
years
ago,
before
before
many
printers
had
built-in
Ethernet
or
Wi-Fi
and
they're
connected
by
USB.
This
was
a
bit
of
software.
F
You
could
run
on
your
Mac
and
it
would
react
sport,
a
locally
attached
printer
using
IPP
Apple
marketing
people
like
to
have
their
own
names
of
things.
They
call
that
air
print,
but
under
the
covers
air
print
is
really
just
internet
standard.
Ip,
P
and
and
I
noticed
that
this
laptop
was
discovering
other
printers
on
the
network
and
re
exporting
an
AirPrint
compatible
variant
of
that
which
was
a
nice
service
to
be
offering,
but
probably
not
what
the
person
intended.
F
What
are
the
requirements
and
maybe
they're
not
the
same
in
different
scenarios,
but
I
think
when,
when
we
talk
about
privacy,
it's
very
easy
for
us
to
all
have
our
own
notion
of
what
we
think
needs
to
be
covered
by
that
and
what
isn't
important
and
people
have
different
assumptions.
We
think
we're
communicating
and
in
fact
we're
not
agreeing
on
as
much
as
we
think
we
are.
So
what
we
want
to
do
here
is
actually
get
some
clear
words
written
down
about
what
are
the
things
that
are
important.
What
are
the
things
that
are
important?
F
F
Another
option
is
for
each
device
to
have
a
private
key
and
share
the
public
key
with
its
peers.
We
are
looking
for
volunteers
interested
in
exploring
that
area
that
doesn't
mean
implementing
it.
That
means
thinking
about
the
properties
and
deciding
whether
we
want
propose
that
or
or
whether
we
want
to
rule
it
out,
because
it's
got
drawbacks.
F
Typically,
at
home,
you,
you
share
the
same
password
with
all
the
devices
for
whatever
the
variants
we
consider
and
evaluate
scaling
properties
are
really
important,
because
we
have
many
many
devices
I
looked
recently
on
my
home
network
and
found
something
like
50
or
60
Wi-Fi
devices
on
my
network,
everything
from
thermostats
to
garden,
sprinkler
controllers
to
the
pool,
filter,
pump
controller,
the
inverters
for
the
Soul
panels,
I'm
sure,
if
I
bought
a
washing
machine
today
at
probably
comes
with
Wi-Fi.
So
it
can
send
me
a
text
message
to.
F
Let
me
know
that
the
laundry
is
done.
We're
going
to
have
many
many
devices
with
a
lot
of
the
home
automation,
that's
being
done
with
things
like
the
Google
home
and
whole
works
with
Alexa
program
to
Google,
nest
works
with
nest
program
and,
of
course,
Apple
home
kits.
We
might
be
seeing
not
just
50
or
60,
but
a
couple
hundred
devices
on
the
network.
So
we
need
to
keep
that
in
mind.
We
have
people
here
are
interested
in
commercial
automation
for
buildings,
where
you
may
have
thousands
of
light
switches
in
an
office
building.
F
S
This
is
my
first
time
Indian
SSD,
so
well,
I'm,
not
one
of
those
who
who
you
were
looking
around
who's
interested
in
privacy,
I'm,
trying
to
read
up
on
on
some
of
these
drafts.
I
wonder
like
what
do
you
mean
by
shared
public
key?
So
every
device
has
a
keeper
and
then
they
share
the
public
yield
or
a
hash
of
a
public
key
printed.
Somehow.
S
But
my
question
is:
if
I
have
this
printer,
that
has
has
a
keeper
and
it
shares
its
public
key
and
I
know
no
its
public
key.
Now
later,
any
new
pair
who
comes
and
talks
to
this
public
key
or
does
a
key
exchange
or
anything
with
that
public
key
I
will
still
know
he
is
talking
to
to
a
printer
or
to
that
printer
in
that
room.
So
I
could
do
something
like
wardriving
like
where
I
know.
Okay
in
this
building,
these
are
all
the
devices.
S
F
T
Crispin
Apple
I,
just
wanna,
ask
a
quick
clarifying
question
to
your
comment
or
your
concern.
Are
you
assuming
that,
in
the
shared
public
key
case
that
the
public
keys
are
actually
sent
in
the
clear
it's
a
recipient?
So,
for
example,
I
know
your
public
key
and
I
want
to
send
your
message.
I
also
send
the
public
key
in
the
clear.
S
S
T
Know
your
public
keys,
your
public
diffie-hellman
key
share.
For
example,
I
can
just
generate
a
fresh
random
diffie-hellman
key
share,
do
a
diffie-hellman
and
then
send
you,
my
public
ephemeral
diffie-hellman,
which
is
fresh,
and
you
have
no
idea
that
anyone
has
no
idea
that
I'm
sending
you
know
a
message
directed
to
or
your
public
key.
F
I
think
the
point
that
Kris
is
making
is
there
are:
there
are
cryptographic,
algorithms
and
protocols.
You
can
use
that
use
the
shared
public
key
to
derive
new
key
material
in
ways
that
don't
reveal
what
share
key
you
used.
Only
only
the
holder
of
the
private
key
can
make
sense
of
your
message
and
to
anybody
else.
It
just
looks
like
random
numbers,
and
they
don't
know
where
it
came
from.
T
One
more
comment:
we
in
discussion
with
Christian
some
other
people,
are
actually
looking
at
the
shared
public
key
case
in
considering
the
the
very
detailed
description
that
key
put
into
the
scalability
draft.
That
seems
to
come
out
on
top
as
refer
to
pro,
if
you
actually
consider
that
to
be
the
problem
or
the
main
thing
you
want
on
some
ice
for
scaling
to
potentially
many
different
peers.
So
if
anyone
is
interested
in
collaborating
I'm
sure
we'd
be
happy
to
work
something
out.
C
So
or
you
can
stay
up
here,
Stewart
no,
unless
you
don't
want
to
we're
really
interested
in
people's
opinions,
so
either
on
these
variants,
like
it's
great,
to
have
privacy
people
on
crypto,
cryptography
people
here
and
on
the
maybe,
let's
flip
back
to
the
requirements.
Does
this
sound
reasonable
to
people?
Are
we
missing
something,
or
do
we
have
something?
That's
gonna
inhibit
us
that
we
don't
need
I'm.
N
This
day,
Robin
I,
think
I've
said
this
is
a
previous
meeting,
but
this
is
reasonable.
I
think
this
is
good.
This
is
great,
but
what
the
slides
earlier
on
showed
that
the
black
hat
was
saying
Oh
Stewart
is
exchanging.
Some
third
Stewart
is
talking
to
David
something.
Oh
there,
you
are
taking
notes
er
speaking
today,
I'm
assuming
that's
a
problem
that
we
want
to
solve.
We
want
to
have
the
black
hat,
not
be
able
to
know
that
Stewart
is
talking
to
David.
N
However,
unless
Stewart
and
David
both
have
CI
a
totally
locked
down,
phones
that
only
do
this
and
never
phone
home
in
any
public
way
have
never
released
any
other
information
that
would
identify
who
they
are.
People
are
gonna
know
that
MAC
address
is
Stewart
and
the
other
one
is
David.
Now
they
won't
know
what
service
they're
discovering
with
with
the
work
we're
doing
here.
They
won't
know
what
they're
trying
to
discover
what
they're
trying
to
say
to
each
other.
These
are
all
good
problems,
but
this
is
not
a
problem.
N
We're
gonna
solve
because
that
blood
gas
monitor
that's
embedded
in
you
phone's
home
to
the
medical
manufacturer
by
URL,
to
see
if
there's
a
firmware
up,
it's
just
given
away
what
it
is,
and
likewise
my
my
phone
is
going
to
contact
home
day,
Robin
comm
ever
oh,
my
god
now,
I've
given
away
Who
I
am
even
if
everything
else
is
locked
down,
so
basically
I'm
just
saying
that
your
behavior
in
other
things
can
give.
We
can
leak
privacy
so.
C
I
hope
you
could
absolutely
agree
in
the
other,
like
our
people
know
more
about
privacy
can
jump
in,
but
my
understanding
is
privacy
is
about
fixing
all
these
holes
and
we
in
this
working
will
not
fix
all
of
them,
but
it
doesn't
mean
we
should
give
up,
because
there
are
other
holes.
Like
my
favorite
example
right
now,
for
most
web
traffic
is
DNS
NS&I
they
both
leak.
What
you're,
talking
to
two
working
groups
are
completely
independently
trying
to
find
solutions
and
we
will
only
be
safe
once
we
have
both
but
I've
heard.
C
N
No,
that's
not
my
point
at
all.
I'm
supporting
this
work
I
want
this
work
to
go
forward.
It's
just
slides
like
this.
That
say
we're
trying
to
solve
this
problem
of
saying.
I'm
gonna
not
know
that
that
phone
is
owned
by
David
and
I.
Don't
know
that
phone
is
owned
by
Stewart
magically,
there's
no
PII
in
leaking
out
of
either
one
of
them
and
they're
talking
to
each
other.
I,
don't
think!
That's
a
problem
that
this
proposal
and
our
work
presently
solves.
Ok,
absolutely.
C
N
C
Of
DNS
st,
we
don't
want
to
leak
more
like
in
the
printer
example.
There
is
nothing
we
can
do
in
this
working
group
about
the
fact
that
someone
can
see
who's
talking
to
that
IP
address,
but
there's
something
we
can
do
about
it.
Saying
oh
David
like
this
right
now.
If
you
browse
on
this
network,
you'll
see
that
it
and
David's
MacBook
Pro
is
here
and
that's
what
we
want
to
fix
ya.
N
F
Stuart
I
just
wanted
to
quickly
respond
to
the
point
David
made
I
think
we
could
change
some
wording
to
clarify
what
we
talk
about
here
is
we're
not
trying
to
boil
the
ocean.
We
are
trying
to
make
sure
that
we
don't
do
anything
that
contributes
to
making
the
problem
worse.
So,
within
the
context
of
the
discovery,
we
don't
be
adding
information
that
discloses
identity
or
all
of
the
other
things
that
we
talked
about
here
and
then
the
other
query,
quick
point
David
was
talking
about
MAC
addresses
there
is
work
being
done
to
randomize.
F
N
U
Sarah
Dickinson,
the
comment
I
wanted
to
make
was
about
the
methodology
you're
thinking
of
using
so
the
best
thing
we
have
in
the
ITF,
at
least
in
the
moment,
is
RFC
69
73,
which
is
a
document
which
describes
privacy
considerations
for
protocols
and
the
idea
behind
that
was.
It
was
analogous
to
how
we
do
security
analysis
of
protocols.
So
I've
mentioned
this
to
David
and
I
mention
it
for
the
people
in
the
room
who
might
not
be
aware.
U
One
of
the
things
that's
already
been
pointed
out
is
that
that
might
but
that's
the
best
we
have
today,
but
there's
a
lot
of
questions
about
whether
that's
actually
the
right
thing
moving
forward
to
have
so
it's,
but
it's
the
best
starting
point.
We
have
one
of
the
things
that's
helpful
with
is
in
defining
nomenclature,
and
it
has
some
really
good
definition,
sections
on
things
like
anonymity
and
fingerprinting,
and
what
would
be
nice
is
if,
when
we're
looking
at
an
SSD,
we
can
introduce
that
nomenclature
early
and
people
get
used
to
using
it.
U
U
It's
called
the
PRG
privacy
enhancements
and
assessments,
research
group
there's
a
mailing
list
set
up.
We
had
a
first
side
meeting
this
week
and
so
we're
looking
for
people
interested
in
working
on
work
items,
they're
related
to
work
in
the
ITF,
but
also
outside
of
it,
we're
very
keen
for
that
to
be
a
place
to
collaborate
with
open
source
people
who
are
possibly
working
on
solutions
that
are
not
documented
or
standardized.
And
that's
you
know
a
real
potential
source
of
input
to
the
thinking
here,
and
we
also
want
to
link
up
with
academics.
T
Chris,
go
ahead,
a
quick
question
for
I.
Guess
the
chairs
in
the
group.
Is
it
your
expectation
or
is
it
our
expectation
that
whatever
its
solution
we
haven't
come
up
with,
will
satisfy
all
three
scenarios
or
are
we
going
to
have
potentially
multiple,
depending
on
your
scenario,
which
kind
of
feels
dirty
and
fun
that,
but
they
could
be
sufficiently
different,
such
that
different
requirements
apply,
and
you
can
greatly
simplify
things
depending
on
what
scenario
versus
another
I.
C
Well
speaking
for
myself
mostly,
but
my
assumption
would
be
that
we'll
have
to
get
into
solutions
a
bit
more
before
we
can
answer
that
if
someone
comes
up
with
a
solution
that
solves
all
scenarios
and
is
efficient
and
makes
coffee
and
everything,
then
we're
done.
If
it
turns
out
that
we
have
to
make
hard
trade-offs,
then
we
may
end
up
fragmenting
my
personal
Brent.
French
would
be
to
have
one
solution
fits
all,
even
if
there
are
some
costs.
But
you
know
there
are
cases
where
that's
not
always
possible.
Okay,.
T
Then,
in
the
one
solution
fits
all
case
going
to
the
requirements
backward,
how
will
we
identify
what
are
the
mandate
like
pretty
much
I,
don't
think
anyone's
coming
down
the
the
actual
answer
to
this
question?
A
lot
of
these
are
ideal
to
have,
but
a
one-size-fits-all
solution.
These
might
not
all
be
applicable.
That's
good!
Let's
talk
about
that.
What's
your
opinion,
I
want
them
all
right
know
what
my
cake
and
I
want
to
eat.
It
too.
T
T
O
T
To
follow
up
on
that
I
think
many
of
those
solutions
right
now,
particularly
when
receiving
a
message
or
receiving
a
broadcast
message
you
want
to
tell
or
as
the
service
provider
you
want
to
just
remember
the
night
you
should
reply
requires
a
linear
amount
of
work
and
push
back
to
how
many
pairs
you
have,
which
is
not
great
because
and
you
can
just
easily
send
them
garbage
and
causing
to
overwhelm
himself,
but
there
are
I,
think
David
and
I.
We
spoke
offline
about
potential
ways
to
optimize
that
to
like
reduce
it
from
linear
to
logarithmic.
T
C
L
Andrew
Sullivan
just
to
follow
up
on
something
that
Dave
said,
which
I
think
is
what
he
meant,
but
I
want
to
make
sure
if
you're
willing
to
give
up
resistance
to
das
attacks,
you
mean
resistance
to
dr.
das
attacks
on
the
server
rather
than
resistance
to
becoming
an
amplifier
in
a
DOS
attack,
cause
I.
Think
the
the
second
thing:
we've
we've
already
created
several
services
on
the
internet.
That
seem
to
be
very
good
at
probably
causing
problems.
So
that
would
be
a
bad
thing
for
this
to
be
yeah,
yeah
I
think.
C
V
H
A
T
To
them
the
MAC
address
randomization
thing
they
came
up
early.
Unfortunately,
I
just
saw
the
person
who
doesn't
like
step
out
of
the
room.
So
this
is
not
timed
intentionally.
You
were
saying
that
you
want
to
scope
the
problem
too,
such
that
you
don't
want
the
solution
to
reveal
any
new
privacy
preserve
the
III
effectively.
I,
of
course,
agreed.
That's
like
a
perfectly
fine
approach
to
take
this.
Does
that
mean
it
is
out
of
scope
or
will
be
considered?
I
was
go
to
talk
about
things.
T
You
could
also
do
to
help
preserve
yeah
I
say,
for
example,
you
did
have
the
two.
You
know
radio,
with
two
interfaces
you
can
have
two
MAC
addresses
and
you
want
to
do
the
thing
with
discussing
solutions
or
purchase
techniques
insert
your
favorite
word
here
that
make
use
of
that
and
use
this
privacy-preserving
discovery
solution,
the
in
scope
or
not
I.
C
Think
leveraging
this
from
work
would
be
in
scope.
I,
you
would
have
to
define
the
scope
clearly
cuz
I
get
that
that's
becomes
a
blurry
line.
An
example
I've
heard
from
someone
is
given
that
this
private
discovery
is
going
to
involve
some
key
exchange.
You
could
use
these
keys
to
bootstrap
some
other
things
that
could
be
in
scope
as
well.
Okay,
but
I
agree
that
that's
blurry
and
I
put
down
an
action
item
that
as
a
working
group,
we
need
to
clarify
our
scope
more
okay,.
T
Yeah,
so,
just
to
echo
back
my
understanding,
we
can
admit
or
declare
victory
effectively
if
we
get
a
solution
that
solves
this
discovery
problem
without
revealing
any
new
PII
doesn't
mean
we
shouldn't
stop
there.
We
should
potentially
out
for
additional.
You
know
best
practice
advice:
how
to
further
reduce
the
amount
of
information,
that's
leaked,
potentially
by
doing
that,
Kadesh
randomization,
or
what
have
you
correct?
Yes,
yes,
okay,.
T
T
C
T
R
C
Know
and
I
think
and
that's
on
us
chairs.
It's
become
kind
of
complicated
to
follow
along
because
we
have
a
lot
of
drafts.
So
I
think
we'll
try
to
do
so.
Take
an
action
item
to
clarify
when
someone
coming
into
this
room,
saying
I
want
to
see
what
they're
doing
for
privacy
what
do
I
start
reading
thanks
for
that
Chris,
so
we're
going
to
talk
about
the
Charter
soon
but
hold
on
Tom
I'm
going
to
do
a
few
things
before
you
come
up.
C
A
quick
question:
this
came
up
at
the
working
group
chair
meeting
yesterday
or
yeah
yesterday,
they're
discussing
using
github
for
working
groups,
which
some
working
groups,
most
notably
HTTP
and
quic,
have
been
doing
pretty
successfully
in
my
mind,
and
I
would
like
to
experiment
with
that
in
DNS
service
discovery.
So
this
is
mostly
a
question
for
our
document
authors.
One
of
the
concerns
I've
had
is
I've
noticed
that
several
of
you
use
github
to
collaborate
between
each
other
because
you're,
not
necessarily
in
the
same
time,
zone
and
I.
C
Think
that's
great,
but
I
think
that
would
be
a
great
way
to
help
new
people
in
the
working
group
could
contribute
because,
like
for
example,
there
Martin
was
Thompson
was
describing
how
or
and
quick
they
have
people
who
come
over.
Look
at
the
draft
didn't
fix,
typos
for
them
or
just
raise
an
issue
and
say
have
you
thought
of
this
and
it's
a
lot
smaller
barrier
to
entry,
then
like
emailing,
a
list
you
have
to
join
is
another
problem.
That
I've
seen.
C
Is
these
github
repositories
that
the
others
have
don't
have
contribution
guidelines
or
a
mention
of
the
note
well
which
could
cause
some
IP
our
problems?
If
someone
were
to
propose
an
idea
there,
so
they,
the
isg,
has
actually
built
a
framework
for
us
to
build
these
working
group
repositories
that
have
has
been
reviewed
by
our
lawyers.
So
it
clearly
states
to
note
well
and
other
things
before
people
can
contribute
and
I
think
that's
a
pretty
strong
requirement
that
we
want
to
make
sure
the
ITF
IPR
policy
is
clear
to
everyone.
C
H
Timmi,
since
key
in
our
top
co-chair,
we
are
using
github,
mostly
with
the
chairs,
to
sort
of
collaborate
as
well,
but
we
do
have
a
lots
of
drafts.
What
I've
noticed
is
we
do
have
some
documents
in
our
sort
of
organization,
but
when
I
see
collaborations,
let's
say,
Stewart
and
Ted
are
working
on
something
they
may
want
to
work
on
something
before
they
push
it
to
see
how
other
people
do,
especially
with
stateful
operations.
H
You
guys
had
a
lot
of
changes,
but
you
weren't
ready
to
share
it
with
the
world
which
I
understand
until
you
all
that
sort
of
you
know
blessed
it
all.
It's
probably
right
way
to
say
it
so
there's
some
probably
some
good
path
forward
on
how
to
do
that,
where
you
guys
can
work
without
us
sort
of
you
know,
meddling
in
your
process.
F
Structure
from
my
point
of
view,
this
seems
like
a
really
easy
question.
I
can't
see
any
reason
not
to
do
it
right
now.
I
have
some
repositories
under
my
name
in
github
we
have
some
under
Ted's
name,
it's
all
pretty
ad-hoc,
so
this
would
be
the
same
way
of
working
in
a
different
context.
Just
to
address
timorous
point
I,
don't
really
care.
F
If
anybody
looks
at
interim
versions
and
in
fact
we
have
had
that
with
the
session
signaling
and
the
push
notifications,
some
people
are
working
with
at
Cisco
will
actually
email
us
with
feedback
on
a
version
that
we
haven't
submitted
yet,
and
that
kind
of
took
me
by
surprise
a
couple
of
times.
But
if
they're
willing
to
read
those
unpolished
interim
versions
and
comment
on
them,
I
have
no
problem
with
that.
D
D
H
Felt
they
were
private
I
just
felt
sometimes
when
you're
sort
of
hashing
something
out
you
know
between
people.
You
want
to
make
sure
you
get
your
brain
sort
of
a
line
before
you.
You
know
people,
and
we
have
this
thing.
I
have
the
same
problem
in
my
working
environment
but
and
and
I
don't
as
a
chair,
I've
never
felt
to
be
heavy-handed
like
saying
you
must
move
your
repo
into
here.
I
feel,
like
people
have
the
right
to
do
what
they
want
kind
of
thing
right
and
so
I
I,
guide
by
light-touch,
I
think.
F
F
A
working
copy
that
you
haven't
submitted
yet
may
still
be
full
of
typos
and
who
knows
what
stakes
but
as
I
said
before,
if
somebody
wants
to
spend
the
time
to
read
that
I
don't
mind
and
and
if
it
really
is
something
that
Ted
and
I
are
actually
not,
you
know
we're
not
agreed
on
or
we
don't
feel
is
ready
to
share
then
I
think
that's
the
kind
of
thing
we
wouldn't
check
it
in
at
all.
Until
we'd
had
some
private
discussion
and
come
to
agreement
or.
H
The
terminology
biz
trap
in
Tina's
app,
which
is
now
standards
track
and
as
past
working
group
last
call
that's
how
they
addressed
every
issue
as
they
opened
up
stuff
in
the
github
issue,
tracker
and
then
Paul,
Hoffman,
basically
and
Andrew,
went
through
them
point
by
point
and
addressed
them
that
way.
And
yes,
it
is
a
great
way
to
do
that
so
yeah
yeah,
so
and
and
how
I
do
it
is
like
give
everybody
admin
access.
H
C
I
agree:
I
got
I
think
this
would
be
of
like
by
no
means
a
requirement
from
the
chairs.
We
would
do
would
be
work
for
us
to
set
this
up,
and
then
we
would
offer
it
to
the
Tibet
draft
authors
and
then
kind
of
see
where
it
goes.
They're
also
open
questions.
Some
working
groups
encourage
people
to
have
the
discussions
on
the
list.
Some
encourage
them
to
have
them
on
the
github
I
think
we
can
start
with
one
of
the
drafts
and
then
go
from
there.
C
So
our
current
charter
starts
like
even
this
summary
is
way
too
long
for
a
slide
like
giving
the
background
of
how
GNSS
do
you
really
started
with
mdns,
and
our
main
goal
was
to
allow
new
use
cases
a
lot
mostly
focused
on
unicast,
and
so
we
want
to
build
new
scalable
solution,
but
that
it's
still
backwards
compatible
and
look
at
all
the
implications.
There
be
the
it's
security,
your
interactions
with
other
existing
protocols.
We
have
a
list
of
networks.
Are
scenarios
that
we
care
about
like,
for
example,
mesh
networks,
is
one
of
our
multicast?
C
I
I
I
They
have
to
be
independent,
not
for
everybody,
but
for
personal
consumption
and
and
services
are
personal
and
that's
the
transition
that
I
think
we
should
focus
on
as
well
that
we're
not
advertising
services
to
everybody,
and
these
are
all
the
services
that
are
available,
but
you
may
not
be
able
to
connect
to
them.
We
need
to
think
about
the
services
or
they're
available
to
you,
and
why
are
they
only
available
to
you?
I
I
They
may
be
on
my
campus,
so
you
know
I,
don't
literally
mean
a.com
posit
area
to
me,
but
I
mean
what
are
the
services
available
to
me
for
me
that
I
can
use
now,
no
matter
where
I'm
at
independent
of
the
location
and
if
you're
on
a
campus,
you
have
services
that
are
available
to
faculty
members.
You
have
services,
different
services
are
available,
a
student's
different
ones
for
staff
or
for
employees,
and
then
you
know,
guess
wandering
on
campus
that
you
don't
want
to
offer
those
services
to.
I
If
we
think
about
transitioning
from
multicast
services
doing
discovery
over
multicast
to
do
in
unicast
only
what
does
that
world
look
like?
Well,
the
Discovery
proxy
that
we,
you
know
just
completed,
still
provides
a
nice
sync
point
for
all
those
unicast
services
around
different
subnets
to
to
collect
on.
I
I
Let's
see
the
whole
cellular
problem
is
one
that
we
have
to
think
about,
but
that's
really
the
domain
name
issue
as
well.
I
think
we
need
to
think
about
a
general
framework
for
authorization,
and
you
know
some
of
the
problems
that
ted's
fixing
with
update
are
very
specific
to
the
kind
of
constrained
environment
with
battery
is
a
problem,
but
there
may
be
other
issues
with
update
that
we
want
to
enhance.
I
I
Right
now
we're
taking
all
of
the
in
DNS
traffic
and
relaying
it
up
to
the
discovery
proxy
through
the
mdns
relay,
but
we're
carrying
the
EM
DNS
traffic
on
one
another
way
to
do
that
same
thing,
maybe
to
proxy
the
update.
So
if
we
do
unicast
updates
everywhere,
but
we
still
have
this
legacy
M
DNS
traffic.
Well,
we
just
have
a
same
sort
of
relay
that
we
because
it's
distributed
on
every
network,
but
instead
of
sending
all
the
multicast
traffic
it
just
does.
I
The
translates
it
in
does
the
DNS
update
for
us
for
their
services
if
all
of
the
services
and
their
scaling
issues
you
know
to
consider
with
that,
you
can
have
multiple
update
proxies
on
a
network
for
a
redundancy.
You
may
update
to
multiple
discovery
proxies
for
redundancy
you're
gonna.
You
could
still
use
the
subdomain
hierarchy
for
if
you
want
to
make
it
scale
better,
but
you're,
going
to
end
up
with
a
lot
of
services
back
at
the
discovery,
proxy
I
think
we
can
make
that
scale.
I
Okay,
but
if
they're
all
there,
then
we
get
some
new
features.
We
if
we
know
what
all
the
services
are,
then
we
can
do
DNS
SEC.
We
can
have
insect
records,
we
can.
It
looks
like
a
unicast,
DNS
server,
so
I'm
not
sure
all
I
mean
I'm
not
trying
to
design
a
protocol
right
now.
What
I'm
trying
to
do
is
make
us
think
toward
unicast,
and
maybe
that
will
drive
the
milestones
that
we
create
when
we
charter,
maybe
the
discovery
proxy.
H
Thanks
Tom
Tim,
where,
since
key
so
I
worked
through
this
employer
called
Salesforce,
which
you
guys
have
never
used,
but
we
have.
We
have
a
web
app.
We
have
phone
apps,
we
have
watch
apps,
we
have
and
we
have
I've
been
working
with
our
service
discovery
team
internally
on
how
to
map
services,
basically
in
the
same
way
versus
various
levels
of
authentication.
You
know,
as
you
go
in
and
out
of
wireless.
H
K
Thanks
to
Carrie
Lin,
a
rode
shotgun
on
the
chartering
effort,
the
first
time
around
I
didn't
want
to
believe
it's
been
five
years,
but
I
went
back
through
my
email
and
sure
enough
time
flies
when
you're
having
fun.
I,
actually
remember
the
first
time
that
this
group
met
and
it
was
it
was
in
a
giant
hall
and
there
were
so
many
people
that
wanted
to
contribute,
but
I
guess
we're
down
to.
Like
the
you
know,
the
serious
folks
here
now
I
wanted
to
add
a
couple
points.
K
First,
I
expressed
the
desire
earlier
to
see
m2m
service
discovery
be
brought
into
the
fold.
It
was
explicitly
not
considered
for
as
part
of
the
Charter
the
first
time
around
just
because
we
had
more
important
things
to
nail
down.
First,
we
did
have
placeholders
in
our
initial
Charter
for
things
like
providing
solutions
over
mesh
networks.
So
just
an
additional
point
to
your
cry,
for
concentration
on
unicast
is
to
make
things
work
over
multi-link
subnets
as
well.
So
let's
just
not
lose
that
the
second
point
I
wanted
to
raise
was.
K
It
seemed
to
me
that
we
had
several
requirements
that
came
from
the
home
net
group
after
we
chartered,
even
though
we
asked
for
lots
of
input,
I
think
our
one
of
the
things
we
hadn't
might
initially
was
that
we
would
provide
the
service
discovery
solution
for
home.
That
I'm
not
I,
just
want
to
make
sure
that
we
do
a
very
good
job
this
time
around
of
making
sure
we've
captured
all
their
requirements,
if
we
haven't
already
solved
them
and
make
sure
that
they're
also
part
of
the
new
charter,
Thanks.
O
So
take
care.
Thank
you.
I
think
this
is
really
good
presentation.
I
want
to
go
back
to
two
distinctions
that
you
made
for
two
usage
scenarios.
You
had
one
scenario
that
was
on
an
early
slide
that
was
basically
I'm
interested
in
finding
things
near
me,
and
you
talked
about
the
lack
of
relationship
between
say,
network
topology
and
physical
location
right.
That's
the
one
and
then
there's
a
second
scenario
that
you
mentioned,
which
was
the
services,
are
personalized
I
want
to
find
things
associated
with
me,
regardless
of
whether
they
are
right.
O
Those
are
two
very
different
use.
Cases
find
things
around
me
that
I
may
not
know
about
already
like
I'm
looking
for
the
ietf
printer,
but
I've
never
been
here
before
I'm
a
newcomer
right
or
find
things
associated
with
me,
which
may
be
in
my
house
or
maybe
wherever
I
think
those
that
drawing
that
distinction
at
the
sort
of
scenario
level
is
a
really
good
distinction.
O
So
I'd
not
want
to
focus
on
the
one
that's
finding
stuff
near
me
and
because
this
gets
into
you,
it's
tricky
to
come
up
with
if
you're
gonna
put
stuff
into
a
charter.
I
like
that
distinction
tricky
to
come
up
with
what
the
right
scope
is
of
that,
because
it
goes
outside
the
IETF
and
trying
to
figure
out
what
the
right
way
to
do
it
in
the
IDF
is,
and
so
the
funding
stuff
near
me
comes
into
questions
about
preconnect
discovery.
O
So
if
I'm
gonna
look
for
speakers
near
me,
I
may
be
looking
for
a
bluetooth,
pairing
I
may
be
looking
for
IP
discovery
or
I
may
be
looking
for
something
else
right,
and
so
what's
the
right
scope.
When
looking
for
speakers
near
me,
because
in
the
IETF
we
tend
to
think
about
it
as
a
post,
connect
discovery,
I
connect
to
the
network
and
I
look
for
that
stuff!
That's
on
the
network,
but
I
liked
what
you've
done
in
the
explanation,
I
think
it
gets
back
to
sort
of
the
way.
O
The
Stewart
phrase
has
things
about
not
only
we've
heard
of
solving
the
problem
right
where
we
really
ask
you
know:
what's
the
right
problem
to
solve,
when
we
do
that
when
coming
up
with
charters
right
and
so
trying
to
figure
out,
do
we
want
to
scope
discussion
to
be
a
post,
connect
thing
and
I?
Think
in
a
previous
discussion,
Stewart
made
a
suggestion
of
documenting
what
the
UI
assumptions
are
right.
We
don't
do
you
eyes,
but
if
you
can
describe
a
usage
model
or
something
that
helps
to
frame
things
and
so
II.
O
The
problem
is,
we
have
sort
of
disjoint.
Ui
is
right
if
you're
discovering
speakers
in
most
you,
as
you
say,
I'm
gonna,
the
user
knows
that
I'm
looking
for
a
bluetooth
and
so
the
airfryer
go
off
and
I
go
and
look
for
Bluetooth
stuff,
but
we
don't
have
the
user
say.
I
know
that
I'm
gonna
look
for
MD
and
ass
versus
DNS
versus
you
know
some
other
protocol
or
whatever,
and
so
the
UI's
have
sort
of
tried
to
abstract
that,
but
not
always
right.
O
W
W
W
I've
tried
to
do
it
myself,
I'm,
not
sure
that
my
proposal
is
the
right
one,
but
the
reason
I
did
that
is
that
I
want
to
see
that
abstraction
somewhere,
because
DNS
is
fine,
but
you
know
people
are
now
talking
about
doing
DNS
over
HTTP
they're
talking
about
and
I
thought.
That
was
a
crazy
at
first
until
somebody
said:
oh
well,
you
open
up
the
web
page.
You
can
just
squirt
down
all
the
DNS
data
for
all
the
links
and
oh
now,
I've
got
a
censorship
bypass
protocol.
G
Terry
mandersohn
responds
lady.
Thank
you
for
bringing
all
your
thoughts.
It's
fantastic
and
it's
fantastic
to
see
some
mature
discussion
in
in
the
IETF
on
an
uncharted
if
I
can
beg
the
chairs
to
make
sure
that
this
does
go
to
the
list
for
more
discussion
and
additionally,
set
aside
time
a
little
bit
more
time
than
what
we
have
today
to
discuss
this
modulo.
My
concern
that
we
still
have
charter
items
to
complete.
C
C
All
right,
very
quick
conclusion:
if
I
master
there,
we
go
so
just
as
a
quick
wrap-up
of
what
we
did
today.
We
went
over
the
status
for
discovery
proxy,
so
we'll
have
more
activity
on
push
in
the
next
few
weeks.
We're
almost
done.
We
went
over
mdns
relaying.
We
now
have
an
implementation
and
a
shepherd.
We
just
need
more
review.
So
please
review
that
document
service
registration.
We
have
a
lot
of
interest
and
running
code,
which
is
great
so
hopefully
working
group
adoption
will
happen
very
soon.
C
Unless
someone
opposes
that
and
should
scream
now
and
loudly,
we
might
have
a
new
document
for
the
in
this
world
cool
free
DNS,
your
lease
sounds
intriguing
introduction
with
court,
we
had
a
lively
conversation
on
what
the
actual
meat
of
the
mapping
should
be.
So
I
look
forward
to
see
the
conversation
continue
on
the
list.
Please
crossbows
the
core
and
DNS
SD,
because
we
want
input
for
both
communities
on
the
privacy
discussion.
It
looks
like
so
that
was
great,
but
we
need
to
clarify
our
scope
a
little
bit
better.
C
We
need
to
look
into
the
c69
3073
privacy
consideration
and
get
early
review
from
era
RG.
The
new
privacy
research
group
and
the
chairs
need
to
make
it
clear
for
new
people.
What
trust
you
need
to
read
regarding
we're
gonna
experiment
with
github,
because
it's
only
like
we
had
support.
If
anyone
doesn't
like
the
idea,
please
bring
it
to
the
list.
C
Otherwise,
we'll
pick
a
draft
and
an
experiment
there
and
it
looks
like
we
have
new
focus
areas
for
a
recharter
thanks
again
Tom
and
we'll
look
forward
to
people
who
hiding
text
on
the
mailing
list
and
making
progress
on
this.
So
we
can
ask
the
question
of
having
the
actual
test
ready
in
Bangkok.
That
concludes
our
meeting
of
GNSS
dean.
Thanks
everyone
for
coming
and
see
you
in
Bangkok.