►
From YouTube: IETF99-CORE-20170721-1150
Description
CORE meeting session at IETF99
2017/07/21 1150
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
B
That's
this
green
background
on
my
second
desktop
right
now,
so
it
has
turned
out
to
be
useful
until
you
forget
changing
it.
So
welcome
to
the
core
meeting.
We
assume
people
have
read
the
drafts,
it's
Friday,
so
I
probably
don't
have
to
remind
anyone
of
the
IPR
principles,
but
just
in
case
I
do,
and
we
have
only
90
minutes
today,
so
we
are
going
to
rush
through
a
number
of
items
here
generally.
B
Most
of
the
items
are
things
that
are
kind
of
almost
done,
but
we
have
this
last
t2
stroke
and
in
the
last
I
2
dot,
and
we
need
to
get
some
decisions
out
of
that.
Of
course,
all
these
sessions
will
be
verified
on
the
minis
and
in
the
previous
meeting
in
the
LP
one
meeting.
Actually
an
item
came
up
that
occasionally
has
been
coming
up
before
so
I
would
hope.
B
So
that's
something
right
now
we
don't
have
a
mechanism
for,
and
we
may
want
to
invent
a
mechanism
for
for
the
ap1
environment,
where
we
often
have
milli
sustained
raids.
So
you
may
get
a
pic
at
once
every
hour
and
it's
that's
something
that
probably
the
the
other
side
should
be
informed
about.
Okay,
so
let's
hope
that
we
have
time
at
the
end.
Are
there
any
other
things
which
would
should
change
in
the
agenda
so.
C
In
the
meanwhile
kind
of
someone
volunteered
to
help
on
the
etherpad,
not
everybody,
it
works
this
time,
yeah
they
fix
it
and
one
Java
scribe
as
well.
Maybe
Ari
no
doesn't
work
all
right.
C
But
is
Mattias,
will
you
be
taking
the
minutes
as
well
all
right
and
when
Jabbar
works
may
be
added,
you
can
do
the
job
or
not
all
right,
okay,
Krister,
how
about
no
all
right,
yeah
we
take
notes.
Can
someone
do
the
job
Michael?
Thank
you.
I
know
he's
about.
Alright,
then
I'll
get
out
of
the
Jabbar
party.
Thank
you.
D
Okay,
quick
update
on
the
sentiment
and
a
couple
of
open
issues,
so
we
actually
ramped
up
our
five
versions
between
class
two
idea.
Last
idea
and
this
one
key
updates
there.
Now
the
base
values
can
be
repeated.
That
was
something
cause
all
it
part
of
the
earlier
crafts.
Then
we
took
it
away.
Cuz,
we
didn't
see
much
value
for
the
complexity,
then
we
realized.
Actually
it
is
a
very
useful
thing
to
have.
D
And
finally,
we
had
a
long
discussion
on
the
mailing
list
and
we
had
a
call
with
with
the
author,
asana
and
and
few
others
Michael
was
there
Christian
was
there
and
we
decided
okay.
That
actually
makes
a
lot
of
sense
for
variety
of
reasons,
and
now
it's
back
in
the
draft.
Also
that
decision
we
had
in
the
last
IETF
that
we
can
now
support
most
Anderson
fields
and
they
will
be
any
with
the
underscore
that's
part
of
the
current
draft.
Then
there
was
one
inconsistency
in
the
draft.
D
A
lot
of
the
examples
were
using
forward
to
us,
but
that
was
actually
not
in
the
normative
part
of
the
allowed
character
set.
So
it
was
a
discussed
and
okay
is
the
whole
character
that
is
relatively
restricted
in
order
to
have
it
safe,
for
example,
in
database
keys
and
such,
but
the
forward
slash
is
highly
useful,
as
this
was
already
used
in
the
cleric
examples,
and
also
in
a
lot
of
use
case
of
sin
ml.
It
made
a
lot
of
sense
to
have
it
in
the
allowed
character
set.
D
D
So
then
we
had
the
big
last
call.
We
got
very
good
review
comments
from
Christian
and
Peter.
Some
things
that
we
are
now
adding
post
last
call
is
clarifying
the
rest,
really
character,
character
set.
What's
the
reason
for
it
with
more
justification,
especially
that
it's
used
in
database
keys
and
that's
one
of
the
reasons,
and
also
that
not
all
URIs
can
be
used
as
names
cause
you
our
eyes,
actually
allow
a
wider
character
set
than
the
names
do
so
bit
more
text
on
that,
then
Salma
can
only
be
is
not
only
used
for
sensor
measurements.
D
Medical
calls
are
used
for
activation
or
configuring
parameters
that
was
slightly
under
specified,
perhaps,
and
we
did
add
more
text
to
it
in
the
person
that
is
currently
posted.
But
what
Peter
was
asking
also
a
couple
of
examples,
and
how
would
you
know
if
a
resource
is
accepting
send
ml
as
a
as
an
actuation?
D
Then
a
couple
of
issues
to
be
discussed.
First
of
all,
the
registration
policy
for
units.
Currently,
we
have
their
eye
on
a
registry
for
all
the
units
that
you
can
have
in
Sen
ml.
Currently,
policy
is
expert
review
or
iesg
approval,
so
the
comment
we
got
from
Peter
was
that:
do
we
really
need
to
creates
a
bit
of
confusion?
What
was
to
be
had
it
there?
D
B
E
E
D
D
Okay,
let's
move
on
links
extension,
so
this
was
something
that
was
mentioned
in
the
group
last
call
when
we
initiated
it
that
then,
with
the
material
graphics,
were
very
mature,
stable,
but
does
one
piece
this
link
extension
that
is
currently
in
the
appendix
that
way?
Maybe
was
not
at
the
same
level
of
maturity
as
the
rest
of
the
document,
and
maybe
it's
better
that
we
take
it
as
a
separate
document
spend
some
time
looking
to
it
properly
see
how
we
want
to
do
it.
D
The
main
reason
for
having
it
here
was
that
he
would
get
the
Seaport
tag
and
they
would
you
could
actually
say
one
byte,
but
maybe
links
in
general
are
quite
long,
so
saving
one
byte
per
link.
Maybe
it's
not
worth
the
effort
of
doing
it.
You
know,
let's
say,
to
expedite
it
way
with
this
draft.
So
what
we
would
suggest
here
that
we
take
the
links,
extension
as
a
separate
document
and
just
start
it
right
away
and
make
sure
we
get
it
right.
I
see
people
nodding,
they've
given
comes
up
micro,
nothing,
no
one
objecting!
D
Then
two
more
issues,
one
that
was
actually
discovered
just
today
when
we're
discussing
the
rest
reading
character
set
in
their
names.
Currently,
the
names
don't
allow
semicolon,
and
there
are
some
URI
schemes,
for
example
ni
that
uses
semicolon
to
as
the
separator
between
the
hash
of
something
and
they're
all
written
that
the
hash
was
used
to
generate.
So
it
could
be
useful
to
be
able
to
use
that
kind
of
URI,
so
rather
URI
schemes
that
use
semicolon
as
a
sentinel
name.
D
But
the
key
question
here
is:
is
semicolon
a
safe
character
and
and
say
it
in
a
sense
that
you
would
be
dumping
it
safely
through
various
database
keys,
for
example.
So
that's
the
reason
why,
for
example,
we
don't
allow
backslash,
Co
specialist
has
very
special
meaning
a
lot
of
these
places,
and
you
don't
know,
but
you
don't
know,
be
escaping
and
doing
too
many
safeguards
on
those.
So
is
semicolon
a
safe
character.
In
that
sense
like
would
you
dump
it
in
your
in
your
databases
and
as
such,
without
worrying
too
much?
D
G
So
I
haven't
read
this
draft
in
a
while.
I
need
to
go
back
and
reread
it,
but
I'm
taking
flight
lessons
right.
An
altitude
is
actually
described
in
two
ways
for
pilots.
One
is
above
MSL,
which
is
the
mean
sea
level.
The
other
is
above
ground
level,
so
I
guess
my
advice
here
would
be
to
have
some
sort
of
a
reference
for
your
altitude
definition.
D
Yeah
I
guess
that's
the
discuss
in
them
coordinates
are
much
more
complicated
than
we
think
and
right
now
we
have
very
basic
model
for
coordinates,
I'm
thinking,
we
need
a
separate
Sen
ml
document
just
for
coordinates
eventually
to
get
like
to
the
core
of
it.
There's
gonna
be
like
relative,
coordinates
and
absolute
and
different
systems,
etc.
So
maybe
that
would
be
part
of
that
document.
H
D
Yes,
no,
in
other
worries
more
about
databases,
big
data
as
such,
where
you
would
use
it
as
a
key,
so
definitely
the
URI
schemes.
It
has
a
special
me
now,
okay,
but
that
that
should
not
be
an
issue.
What
is
more
like
if
you
would
use
this
on
your
big
data
database
and
such
systems?
If
there
is
an
issue.
B
The
damage
might
not
be
very
big,
so
semicolon
is,
is
a
dangerous
factor
if
you
start
feeding
these
things
to
the
shell.
The
UNIX
shell
environments,
like
that,
so
what
we
might
want
to
discuss
is
the
likelihood
of
people
putting
out
senator
Mayer's
names
unprotected
into
a
UNIX.
Shell
commands
I.
Think
anybody
who
does
that
no
further
comment
now,
on
the
all
thing,
one
confusion
that
that
we
consistently
have.
Is
this
the
confusion
between
units
and
quantities?
B
So,
for
instance,
if
you
have
a
pressure,
you
might
have
an
absolute
pressure
or
you
might
have
a
relative
pressure
compared
to
the
the
environmental
pressure
and
traditional
engineers
who
use
kitchen
units
have
made
up
different
unit
names
for
this.
So
there
is
something
called
psi
gauge
and
and
PSI
absolute
and
so
on,
but
that's
not
the
way
SI
units
work
in
SI,
you
actually
have
units,
and
then
you
have
quantities
and
quantities.
B
B
So
you
don't
know
when
something
is
there
that
is
expressed
in
meters.
We
don't
know
whether
it's
the
height
of
the
operator
or
the
size
of
the
operator
or
the
size
of
their
left
arm
or
the
altitude
in
the
pressure,
altitude
or
altitude
compared
to
a
wgs84,
contextual
information.
You
also
need
knowing
that
it's
in
meters
or
even
knowing
that
it's
an
entity,
it's
not
sufficient
in
order
to
get
real
semantics
and
triology.
You
need
more
information
anyway.
B
We
should
stick
with
the
unit
and
the
unit
for
altitude
is
usually
meters,
so
I
think
we
are
done
with
that
one,
but
we
may
want
to
think
about
the
the
other
aspect
about
I
mean
if
I
have
three
sensor.
Readings
which
are
all
in
meters
are
all
in
kaeleen
or
whatever
I
need
to
know
what
what
they
need
and
okay
one
is
the
outside
temperature.
One
is
the
inside
temperature
and
I
need
to
name
label
them
in
some
way
to
get
that
semantic
information,
so
I
think.
F
D
D
Not
not
really
cuz
I
mean
the
semicolon
was
part
of,
for
example,
in
a
URI
specification,
so
I
mean
either
you
use
the
such
or
you
do
something
else
and
then,
if
you
do
something
else
yeah
you
can
change
with
a
colon
and
but
if
you
want
to
avoid
that
kind
of
tweaks
and
tricks,
that
was
the
reason.
Okay,
maybe
you
want
to
add
that
okay.
J
D
J
D
Uri
format,
like
me,
oh
yeah,
yeah
I
mean
this.
Is
this
not
only
crane
I
I
mean
I
was
as
an
example
that
has
that
semicolon,
because
that
was
out
what
Peter
st.
Andre
pointed
out.
For
example,
in
I
you
our
eyes,
don't
work
that
was
like
and
in
lie.
You
are
seeing
very
useful
for
able
to
do
the
hash
paste
like
this.
Yes,
I
was
like
okay.
That
seems
like
an
easy
thing
to
fix.
Then
there
was
the
tag.
Uri
switch
have
the
add
sign
that
could
be
going
a
bit
more
risky
territory.
D
Okay,
so
what
I'm?
But
we
have
to
check
the
semicolon,
also
on
the
list
and
especially
with
Colin,
because
Cohen
gonna
come
here
and
color
has
been
very
strict
on
what
kind
of
characters
that
we
have
there,
because
he
has
most
experience
of
the
database
side.
So,
let's,
let's
confirm
that
on
the
list,
not
what
I
heard
so
far.
No
one
has
been
objecting
that
so
it
seems
like
a
good
idea
objecting
adding
semicolon.
So
adding
semicolon
seems
okay,
but
let's
check
it
on
the
list
and
recording
the
alt
I.
Guess
we
cannot.
D
D
C
Question
have
you
thought
about
using
communits,
for
we.
K
D
D
I
Take
Taylor
that
sounds
good,
although
there
was
actually
an
implied
question
and
in
my
comment,
which
I
just
realized
right
now,
the
document,
as
is,
does
list
Celsius
and
Kelvin
as
two
separate
units
values.
If
we
think
we're
going
to
go
in
the
direction
of
character,
I
was
saying
you
may
want
to
remove
one
of
those.
B
Right
so
there
are
several
units
in
the
table
which
are
marked
with
a
star,
which
means
this
is
not
really
what
you
should
be
using,
but
we
know
that
this
is
widely
being
used
and
temperature
is
one
of
these
weird
cases
where,
where
people
somehow
are
emotionally
attached
to
the
unit
of
Celsius,
which
I
don't
understand,
but
they
don't
know
that.
That's
about
that's
a
bug.
That's
a
bug!
That's
about.
B
We
so
there
are
some
some
five
units
in
there
that
really
don't
belong
there,
because
they're,
not
SI
units,
but
even
the
people
who
wrote
I
saw
eighty
thousand
recognizes
us
as
a
unit
that
is
in
such
a
wide
use
that
they
cannot
really
put
it
into
an
appendix,
but
it's
actually
and
as
I
recognized
unit.
Even
though
it's
really
weird,
because
you
really
only
have
to
subject
270,
315
and
and
then
you
are
there.
L
B
M
So
in
the
interim,
since
Chicago
I
think
even
maybe
before
Chicago
we've
added
a
new
editor
to
the
draft
Christian
Zeus
to
take
the
role
of
dotting,
all
the
I's
and
crossing
all
the
t's
and
spending
the
time
necessary
to
to
make
it
a
good
product
and
get
it
get
it
finished,
and
we've
been
having
regular
teleconferences
about
once
a
month
or
sometimes
a
little
more
frequently
to
discuss
issues
and
resolve
things,
and
one
of
the
things
that
we
realized
was
that
there
was
a
lot
of
ambiguity
about
what
different
things
meant
in
resource
directories.
M
So
one
of
the
one
of
the
things
that
Peter
created
a
an
entity
relationship
diagram
to
represent
what
Rd
is
and
we're
planning
on
using.
We
use
that
as
a
as
a
good
tool
to
discuss
things
and
to
make
make
choices.
We
improve
some
of
the
text
and-
and
you
know,
addressed
a
lot
of
comments
that
we
got
fix.
Some
things
up
made
some
decisions
on
these
remaining
issues
and
clarified
through
the
ER
diagram.
You
know
what
the
deep
domain
parameter
really
means,
which
was
one
of
the
one
of
the
questions
we
kept
getting.
M
So
there's
also
to
talk
about
resource
directory
is
sort
of
a
shadow
of
well-known
core,
so
the
ER
model
includes
well-known
core.
This
is
what
Willam
core
has
basically
I.
Don't
don't
pay
too
much
attention
to
thing,
because
that's
really
just
any
any
any
item
I
didn't
know
whether
they
call
it
a
device
or
a
you
know
an
end:
it's
not
an
endpoint,
a
node,
whatever
its
it's
a
node
on
the
network.
M
It's
a
thing
that
has
a
scheme,
Authority
import',
and
it
has
a
well
known
core
with
links
in
it
resource
resource
directory
as
sort
of
has
the
same
basic
pieces
in
it.
But
it
has
a
number
of
shadows
of
these.
These
are
registrations
and
the
registrations
have
additional
parameters
on
them.
They
contain
links
and
also
resource
directory
can
have
groups,
and
groups
are
associated
with
multicast
address
and
groups
are
composed
of
registrations.
M
So
you
can
put
a
number
of
these
red
stations,
which
is
the
shadow
of
the
stuff
that
comes
from
one
thing
into
a
group
and
then
talked
to
them
through
a
multicast
address.
So
this
is
for
things
like
putting
a
bunch
of
lights
together
in
a
room
and
actuated
them
all
together:
registration
parameters,
side,
each
one
has
a
location,
that's
assigned
when
it's
registered,
that
you
can
use
to
reference
that
information,
an
endpoint
name,
an
endpoint
type,
a
lifetime
and
domain.
So
domain
is
really
just
a
registration
attribute.
I
Dave
Taylor
I'm
not
responding
to
what
you
said,
but
since
you
pause
because
I
gave
you
a
word
Lucas
because
I
realize
you
have
a
terminology
error
on
the
slide
which
may
be
in
the
document,
which
is
the
port,
is
part
of
the
authority
component,
not
something
that
comes.
Oh,
okay,
okay,
thanks,
yeah,
good.
M
M
Hosting
hosting
port,
so
scheme
hosting
port
is
okay,
so
that's
that
okay,
original
origin,
or
which
constitutes
an
or
a
way
of
origin
or
an
internet
origin.
Yes,
okay,
so
next
steps
we're
gonna
make
those
make
sure
the
specification
is
consistent
with
the
model
which
you
know
is
mostly
that
way
now,
but
let's,
let's
make
sure
we're
not
saying
anything,
that's
different
from
what
our
abstract
model
is
well,
we'll
put
a
representation
of
the
model
in
the
documents
and
fun
ASCII
art
simplify
the
section
about
finding
an
RD.
B
About
26
years
ago
a
working
group
was
started
called
DHT,
which
provided
a
way
to
have
the
network,
provide
information
to
devices
that
come
up
on
on
that
networking.
Now,
whether
that
is
applicable
or
not,
is
dependent
on
your
security
model.
So
that's
a
complicated
thing,
not
not
for
the
resource
right
for
each
resolve,
but
the
assumption
is,
it
actually
does
make
sense.
B
To
also
say
what
should
happen
if
the
the
network
is
trying
to
provide
information
for
the
device
where
to
find
a
resource
directory,
then
the
third
branch
is
one
where
the
device
comes
up
doesn't
find
anything
it's
in
its
own
configuration.
That
would
help
habit,
nor
finds
anything
at
the
network
configuration
level
and
the
question
is:
what
should
the
device
do?
Well,
one
answer
to
that
might
be
keep
silent,
pretend
it
doesn't
exist
or
something
like
that
now.
B
So
this
is
really
the
complexity
of
the
section
right
now
we
have
three
different
branches
we
have
to
address,
and-
and
this
branching
is
not
written
tower,
it's
in
the
head
of
the
person
reading
that.
So
let's
talk
about
this
first
branch,
the
device
is
specifically
configured,
it
might
be
configured
with
an
IP
address.
It
might
be
configured
with
a
DNS
name,
plus
an
R
type
to
use
with
that
DNS
names
or
that
needs
to
know
whether
it's
looking
up
the
a
or
a
quad
a
record
or
maybe
looks
up
the
service
record.
B
We
don't
know
that
it
might
use
em
DNS
to
find
in
our
the
service
in
mdns
so
that
it
then
uses
to
do
a
resource
directory
registration,
which
probably
has
Carey
would
say
in
a
moment,
will
then
be
copied
over
back
through
the
mdns
or
it
might
be
a
user
using
another
discovery
mechanism,
for
instance
UPnP.
So
these
are
kinds
of
situations
in
in
the
case,
the
device
is
specifically
specifically
configured
to
use
some
mechanism.
That
is
not
default,
and
the
second
case
is
the
device
is
not
specifically
configured.
B
So
this
is
the
case
that
is
described
in
the
document,
so
the
others
would
be
mentioned,
but
this
is
really
described
in
the
document.
That's
why
it's
yellow
on
this
slide,
and
here
we
really
want
to
limit
the
choices,
because
we
have
gotten
a
lot
of
feedback
that
we
are
offering
too
many
choices
and
it
looks
like
we
are
not
going
to
solve
this
leg
versus
the
HP
bar
today.
B
So,
let's
just
put
both
in
I
note
that
the
DHCP
option
doesn't
exist
so
in
practice
this
might
for
a
while
be
an
easy
choice,
but
unless
until
it's
someone
defines
that
the
HDP
option
and
the
third
branch
then
where
we
probably
still
have
to
write
up
something
there,
but
it
can
only
be
a
suggestion.
I,
don't
think
we
want
to
actually
define
a
default
behavior
here
and
right
now.
B
True
sources
we
identify
is
any
Rd
NSF
information
in
a
slag
or
a
bra
information
that
we
find
in
a
six
token,
ng
document
both
point
to
places
that
are
rather
likely
to
actually
support
some
form
of
resource
directory
functionality.
So
a
device
that
finds
itself
out
there
in
the
desert
might
want
to
try
those.
So
these
are
also
called
out
explicitly
but
more
in
the
sense
of
being
a
list
of
suggestions.
So
this
is
my
my
proposal
for
how
we
structure
the
section.
B
N
N
N
E
N
But
it
seems
that
the
way
this
is
split
seems
very
odd
to
me,
because
on
on
your,
if
you've
got
a
Mac,
you
go
into
printer
settings
and
hit
plus,
and
you
will
see
terminal
rim
printer
with
air
print
on
your
iPhone
and
your
Mac
was
not
specifically
configured
with
the
ietf
terminal
rim
printer
before
you
came
here,
you
brought
it
here
and
they
discovered
it
so
that
really
ought
to
be
listed
and
your
third
choice
use
other
search
discovery
mechanism
such
as
UPnP
I,
assume
by
you
pimpy.
You
mean
SSDP,
not
like
european
penises,.
N
Making
it,
yes,
is
that
you
pimp
is
like
saying
use
I,
Triple
E.
Is
that
it's
a
very
broad
term.
That's
what
you
you
mean
one
specific
of
the
hundreds
order
right
before
you
settle
for
I,
think
you
main
use
SSDP,
but
but
those
I
would
put
those
under
the
not
specifically
configured,
because
that
is
what
you
use
when
you
come
into
environment,
and
you
know
nothing,
can
you
ask
the
environment
help
tell
me
something
so
that
that
seems
like
an
odd
choice
to
call
those
the
specifically
configured
ones.
N
Keep
I
think
mdns
and
I
keep
saying
it's
not
emptiness
when,
when
you're
here
at
the
IETF
meeting,
discovering
the
IETF
Terminal
room,
printer
and
you're,
not
in
the
terminal
room
on
that
network,
you're,
not
using
multicast,
DNS
you're
using
wide
area,
DNS
serves
discovery
and
on
a
mesh
network
like
15.4.
That's
what
you
would
use,
not
multicast.
I
David,
so
yeah
I
actually
agree
with
everything
that
Stuart
said
this
time.
I
I
often
do
I'm
saying
this
time
to
yeah,
so
the
if
you
have
a
DNS
server,
so
I'm
just
going
to
echo
Stuart's
going
why
we
were
saying
yes,
it
is,
if
you
have
a
DNS
server,
even
over
a
15-4
network,
you're
just
doing
do
necessity
over
a
DNS
instead
of
over
m
DNS,
and
so
that's
why
it's
not
just
M.
I
I
The
so
when
I
got
up
here
to
say
is
it's
a
lot
like
getting
your
DNS
server
address,
so
you
can
take
one
of
two
approaches
right.
You
can
either
get
your
Rd
address
the
same
way
as
you've
got
your
DNS
server
address,
okay,
which
is
one
it's
a
branch
that
much
of
the
internet
area
often
goes
down.
Another
branch
is
the
one
that
Stuart
is
talking
about,
which
is
you
use
the
DNS
server
address
to
get
the
other
addresses
okay,
and
so
that's
the
DNS
st
approach
right
and
so
at
a
high
level.
I
Okay
and
if
you
said
that
as
the
principal
that's
actually
more
understandable
to
internet
area,
people
and
I
say
that,
because
these
are
not
just
the
only
two
things
it
internet
area,
people
are
talking
about
so,
for
example,
and
I
don't
want
to
do
up
a
meeting
I'm
just
giving
you
why
it's
more
complicated
than
this
and
limiting
the
choices
is
something
that's
more
of
an
internet
area
discussion
because
there's
discussion
about
something
called
provisioning
domains
and
I.
Don't
want
to
have
to
define
it
here.
I
But
my
point
is
even
this
week
in
the
6-man
group
those
discussions
about
another
way
of
getting
things.
It
has
on
a
per
per
fishing
domain
basis,
because
you
might
want
to
have
a
different
answer,
because
your
router
is
multi-home
to
two
different
networks,
each
of
which
has
a
different
answer,
and
so
I
can't
just
put
it
in
the
RA
because
that's
ambiguous
or
something
right
and
so
they're
defying
these
other
ways
and
whatever
that's
doing
an
HTTP
request
getting
back
on
JSON
blob
or
whatever
it
is
right.
I
J
Okay,
well,
what
I
wanted
to
say
was
just
oh
by
Dave,
but
a
little
I
did
some
work
with
service
location
protocol
many
years
ago,
and
he
was
useful
to
make
a
distinction
between
service
discovery
and
service
lookups.
So
their
service
discovery
meant
that
there
was
an
active
process
already
available
in
that
book
and
your
device
goes
there
and
it's
configured
just
listening
for
the
disciplines
and
you
can
solicit
and
service
lookups
are
specifically
when,
when
you
actually
have
to
configure
the
device
to
do
something.
J
So
that's
that's
one
thing
and
I
think
that
would
that
would
help
a
lot
to
separate
how
to
come
the
resource
directory.
The
second.
The
second
thing
that
I
wanted
to
say
was
that
yeah,
let's
be
consistent.
How
you
find
this
resource
discover
should
be
the
same
way
is
how
you
do
your
resolution
to
find
a
DNS
service
and
so
on,
but
just
sort
of
experience.
J
O
Dave
Robin
I
also
want
to
pick
apart
how
these
branches
are
broken
up
a
little
bit
here.
It
seems
to
be
branch.
One
bullet
one
is
consistent.
You
know,
in
other
words,
I
I
know
for
some
reason,
I
know
a
DNS
name
or
an
IP
address
of
my
server
and
I
just
go.
Ask
for
it.
I've
been
configured
to
do
that.
O
The
second
bullets,
though
I,
don't
think,
follow
under
specifically
configured
because
they
really
fall
under
branch
two,
because,
if
I'm
using
a
circus
says
use
MDS
or
@dn
SSD,
as
was
pointed
out
to
find
a
service,
not
a
particular
name
of
a
server.
So
if
I'm
just
saying
find
a
service
I'm
doing
that
either
through
UPnP
the
service
discovery
there
or
mdns
or
dns
SD.
O
Anything
I'm
still
need
to
know
what
I'm
asking
for
a
service
name,
and
my
point
for
coming
to
the
mic
is
that's
exactly
the
same
as
looking
for
a
DHCP
option
with
a
particular
name:
I,
don't
see
those
as
being
any
different.
I
have
to
it
branch
to
is
not
I'm
completely
clueless
I,
don't
know
what
to
do.
If
you
it's
lying
there
in
your
DHCP
message
with
an
option,
name
or
number,
but
if
I
don't
know
to
look
for
it,
then
I
still
am
helpless.
O
So
on,
but
I'm
saying
that
the
second
two
bullet
points
of
looking
for
something
are
part
of
branch.
Two,
you
have
to
know
what
you're
looking
for
it's,
either
a
service
name
or
an
option
number
or
whatever.
You
still
are
that
level
of
configuration,
but
not
a
location
configuration
not
a
specific
server
in
mind.
K
Hi-
this
is
honest,
so
I
think
constant.
You.
You
started
this
presentation
because
you
were
wondering
of
what
should
actually
be
done
in
the
ADI
document.
I
guess,
and
it
seems
that
the
in
the
area
has
standardized
so
many
different
mechanisms
that
it
would
be
pretty
much
impossible
to
get
any
form
of
interoperability
here.
So
I'm
wondering
what
are
the
most
obvious
approaches
to
half
the
Rd
document
just
be
punt
on
that
issue,
be
silent
on
it
and
maybe
work
on
a
separate
document
that
lays
out
the
different
options.
K
Whatever
the
classification
is
because
there
are
many
options
and
then
presumably
some
other
organizations
to
go
and
then
pick
a
subset
but
or
select
one
or
two
there
preferred
mechanism
in
there
will
just
be.
It
would
just
be
in
practice
difficult
to
have
devices
working
with
each
other
and
finding
the
stuff,
because
there
would
be
like
too
many
choice
too
many
choices.
I
is
that
is
that
so
why
you're
heading
or
are
you
that's
not
what
I
would
suggest
I
would
suggest
to
deliver
resource
discovery?
K
B
K
N
Find
the
whole
discussion
very
strange
because
it
seems
like
you're
really
bending
over
backwards
to
avoid
using
the
solution
that
already
exists.
You
have
an
entity
on
the
network
called
the
resource
directory.
You
talk
to
it
by
exchanging
packets,
it's
a
service.
You
want
to
discover
it.
We've
been
through
this
process.
We
have
had
lots
of
debates
with
published
RFC's.
We
have
code
running
on
Apple
products.
N
N
P
Alexander
Pro
here
just
a
question:
I
mean
we
are
talking
a
lot
about
the
night
constraints
of
devices,
but
there
are
networks
that
are
constrained
and
there
are
places
that
we
don't
want
for
a
multicast
and
that
things
don't
work
like
with
so
I
mean.
Maybe
this
is
not
the
only
question,
but
it's
like
I
just
don't
want
to
get
over.
Okay,
microcontroller
this
and
this
they're
the
networks
already
that
we
don't
want
to
I.
N
Feel
like
it
should
be
a
schoolteacher
with
a
whip
with
the
ruler
in
my
hand,
and
wrap
everybody's
knuckles
when
they
say
the
word
multicast,
there
are
few
rfcs
67
62
defines
multicast
dns
67-63,
which
was
very
deliberately
and
intentionally
a
separate
RFC
defined
service
discovery
which
does
not
have
to
use
multicast
and
I
just
gave
the
example
here.
At
the
IETF
meeting,
going
to
print
a
set
up
and
set
up
a
printer,
you
are
not
using
multicast.
So
anytime,
somebody
uses
the
argument
about
multicast
they're
talking
at
the
wrong
RFC.
F
So
Eric
not
Marc,
so
maybe
maybe
there's
some
different
assumptions
from
different
people
in
the
room.
What
it
means
to
work
with
constrained
devices
and
constrained
networks.
I
know
what
a
Raspberry
Pi
is
I
call
those
things.
Iot
super
computers,
because
25
years
ago
they
were
super
computers,
every
gig
of
ram
right,
it's
very
different
to
think
about
that,
and
then
we
have
the
milli
packets
per
second
networks,
that
cars
to
the
coin
I
think
that's
very
hard
turbo.
F
The
people
that
defect
that
people
are
building
networks
that
can
deliver
13
byte
frames
a
few
times
a
day
is
very
different
than
the
environment
that
arrests
be
by
exhibits.
So
so
I
think
that
there's
a
disconnect
when
you
talk
about
constrained
devices
here
and
I,
think
that
that's.
Why
there's
some
tension
here
saying?
Do
we
have
to
have
17
different
ways
of
doing
this
stuff
that
needs
to
pull
in
service
discovery
mechanisms
that
might
trigger
the
DMS
include
UTP
and
do
all
of
these
things
the
fact
that
they
fit
on
a
Raspberry
Pi
irrelevant.
N
Well,
if
that's
their
constraint
and
I
think
the
constraint
ought
to
be
written
down
about
what
is
the
code
space?
What
is
the
packet
size?
What
is
the
processing
I
gave
an
example
earlier
this
week
from
one
about
developer
workshops
we
had
at
Apple
fifteen
years
ago.
Product
is
still
on
the
market.
It's
called
the
site
player
telnet
neat
little
box
that
you
can
plug
into
things
with
serial
ports
unless
you
tell
that
to
them
over
the
network
that
device
15
years
ago
had
16k
a
flash
memory.
N
N
B
I
think
yes,
72
28
right,
so
basically
I
think
that
there
is
a
non-negligible
group
of
people
who
would
want
to
avoid
the
coop
ecosystem
to
become
dependent
on
DNS
and
I
happen
to
be
a
member
of
that
group
and
I.
Don't
think
we
want
to
make
hype
independent
of
IP,
so
I
believe
that
relying
on
neighbor
discovery
or
for
those
people
will
I
get.
The
HTTP
is
the
right
way
to
solve
this
bootstrapping
problem
and
from
then
on.
G
Guess
I'll
I'll
make
a
microphone
point
to
the
last
to
the
last
slide,
and
that
is
that
I'm
guessing
that
the
resource
directory
is
going
to
be
fairly
resourceful.
If
you
go
on
by
a
printer
today,
you
find
that
that
printer
supports
a
variety
of
discovery
schemes,
a
variety
of
printing
protocols
and
so
forth.
So
I
think
the
optionality
is
from
the
standpoint
of
the
clients.
They
don't
necessarily
need
to.
G
We
don't
need
necessarily
specify
a
method
for
the
clients
to
find
the
Rd,
but
the
Rd
should
be
fairly
resourceful
and
be
able
to
support
a
variety
of
discovery
methods.
Okay,
I
sort
of
wish
that
I
had
come
before
the
the
DNS
SD
debate.
I
have
to
feel
like
I
have
to
sort
of
justify.
Now.
Why
we're
doing
this?
G
We
this
work
here
on
on
mapping
was
sort
of
a
result
of
that,
because,
ultimately,
core
came
up
with
a
way
of
doing
discovery,
using
Co,
app
and
and
and
as
a
further
efficiency.
The
resource
directory
was
posited
as
a
way
of
you
know,
collecting
all
that
information
in
one
place
and
eliminating
the
need
to
do
multicast
for
discovery,
and
so
our
fallback
at
that
point
was
to
at
least
say
well,
let's
at
least
describe
how
to
translate
between
one
naming
system
and
the
other.
G
G
It
really
doesn't
make
sense
to
map
every
single
resource
in
the
resource
directory
into
DNS
SD,
but
at
least
at
the
level
of
what
are
variously
called
function,
sets
or
command
classes
or
objects
which
are
defined
by
SDOs
that
have
you
know,
sort
of
a
collection
of
you
know
functionality.
It
all
belongs
in
one
unit,
the
the
link
that
gives
you
the
entry
point
into
there
is
proper,
probably
the
proper
granularity
to
map
between
Rd
and
it's
a
DNS
st.
G
So
one
of
the
reasons
that,
back
to
historical
note,
we
worked
with
Zack
Shelby
on
on
the
mapping.
It
was
decided
several
years
ago
that
we
would
roll
this
in
to
the
Rd
draft,
but
as
we're
trying
to
mature
the
Rd
draft,
a
couple
things
happen.
First,
nobody
could
really
remember
the
context
in
which
this
stuff
was
done
in
the
first
place,
so
I'm
here
to
sort
of
resocialize
it,
and
secondly,
we
felt
that
the
resource
directory
draft
would
get
to
the
finish
line
faster.
G
If
we
remove
this
and
put
it
back
into
an
individual
draft,
it
was
a
why
actually,
it
was
at
originally
an
individual
submission,
but
it
because
it
was
in
the
Rd
which
was
a
working
group
document
and
then
pulled
out.
This
draft
has
basically
gone
to
working
group
working
group
draft
immediately,
so
I
just
want
to
describe
briefly
DNS
based
service
discovery
for
anybody
who
might
be
unfamiliar
with
it.
G
What
it
really
is
is
a
conventional
use
of
existing
DNS
infrastructure,
namely
the
resource
records
and
the
protocol
elements.
So
we
have
things
like
hosts,
which
could
be
described
as
a
or
quad-a
records.
The
pointer
record
is
actually
used
to
do
a
lookup
on
a
service
type,
so
essentially
you're.
Looking
for
a
class.
It's
a
way
of
discovering
a
class
of
things
like
printers.
What
you
get
back
in
return
is
a
set
of
instances
which
then
can
be
used
to
name
SRV
and
text
records
which
always
come
in
pairs.
G
The
SRV
is
used
to
give
you
the
host
and
port,
so
you
know
you're
not
bound
to
a
well-known
port.
The
original
use
of
SRV
was
to
basically
get
us
out
of
the
tyranny
of
well-known
ports,
and
then
text
records
can
come
back
and
contain
arbitrary
key
value
pairs
that
can
give
you
attributes
on
that
resource
or
on
that
service.
So,
as
I
said
earlier,
this
proposal
was
but
essentially
equates
one
type
of
resource
in
particular,
which
is
a
restful
api
entry
point
with
the
concept
of
service.
G
So
in
terms
of
mapping,
let
me
just
pop
forward
here
the
proposal
talks
about
some
new
link
target
attributes
and
requires
that
some
existing
definitions,
be
there
I'm,
not
sure
we
have
a
term
for
exporting
these
things
is
optional.
But
if
you
do
export
them,
then
you
have
to
do
it
in
a
certain.
In
a
certain
way,
certain
things
will
be
mandatory.
If
you
decide
that
you
want
to
export,
you
know
your
resource
into
the
DNS
SD.
G
So
exp
is
a
target
attribute,
that's
kind
of
a
hint
that
can
drive
an
automated
mapping
tool
to
say:
I
want
this
API
entry
point
to
be
exported
to
DNS,
or
you
know.
Potentially
we
could
define
this
to
be
exp
equals
and
then
actually
define
the
other
name
system
that
we
wished
that
we
wish
to
map
into.
For
now.
It's
just
a
boolean
and
DNS
st
is.
The
default
instance
is
essentially
a
unique
identifier
within
a
within
the
context
of
the
domain
in
which
this
thing
will
be
registered.
G
G
We
will
require
you
to
specify
your
resource
type,
there's
an
opportunity,
I
think
here
to
go
back
and
look
at
the
RTE
registry,
which
we
essentially
have
expert
control
over
and
right
now,
I
think
it's
a
structured,
namespace
I
think
we
have
the
opportunity
to
make
it
a
federated
namespace.
If
we
choose
to
do
so,
which
would
help
to
you
know,
keep
different
application
definition
separate
and
then
finally,
if'
is
a
semantic
tag
or
a
link
to
the
interface
description.
G
So
here's
a
quick
example:
the
color
codes
are
sort
of
shown
there
to
show
what
gets
mapped
to
what
so,
let's
say
you
formulate
a
query,
we're
sort
of
thinking
that
these
queries
would
be
directed
at
resource
resource
directories
themselves
rather
than
rather
than
multicast,
but
you
know
just
bear
with
me
here.
You
basically
do
a
look-up
on
things
that
have
the
exp
attribute
set
and
here's
an
example
of
getting
back,
something
which
is
it's
got
a
path
there
in
red.
G
It's
got
a
context
type.
The
resource
type
is
defined
by
the
ocf.
In
this
case,
if
we
go
along
with
this
federated
namespace
idea,
the
first
part
of
that
oh
I,
see
becomes
the
resource
type
that
or
the
service
type
that
we
register
down
below.
We
see
the
resulting
resource
records.
We
have
to
basically
create
a
hostname
if
one
doesn't
already
exist.
G
We
register
this
thing
as
being
of
type
oh
I
see
and
everything
under,
oh
I,
see,
is
actually
owned
by
that
Sto.
So
it's
the
subtype
is
the
temperature
sensor
and
and
down
below
the
everything
that's
that's
left
over,
such
as
the
path
and
the
interface
definition.
Basically,
go
into
the
text
record
as
key
value
pairs.
So
that's
the
proposal,
but
we
presented
this
in
DNS
SD
on
Wednesday
and
I.
Think,
although
the
draft
is
here,
I
think
it
would
be
important
to
have
input
from
from
both
working
groups.
Q
Carrie
thanks
Tim
Carrie
nokia,
I
do
have
a
two
comments.
Really
one
is
because
I've
we've
had
some
of
this
problems
before
some
other
SDOs
and
trying
to
map
things.
If
you
will
to
the
instance
numbers
and
stuff,
and
so
a
lot
of
it
was
particularly
like
certain
tools
and
stuff
like
that.
But
in
the
standard
have
you
made
sure
that
the
formatting,
you
know
you
got?
Oh
I,
see
dot
r
dot
temperature
sensor
actually
can
valid
actually
turns
into
an
appropriate
in
terms
of
the
syntax,
an
appropriate
instanceid.
Q
G
Just
want
to
back
up
here
again
I
mentioned
that
our
service
type
in
this
case
yeah.
It's
it's.
It's
not
required
that
you
export
your
api's,
but
if
you
do,
then
the
the
values
of
these
attributes
have
to
be
in
a
form.
The
the
burden
is
on
the
client
to
basically
put
these
in
a
form
that
can
be
directly
exported
into
DN
SSD.
So
in
terms
of
instance,
names,
for
example,
what
DNS
SD
accepts
is
actually
pretty
wide
periods,
for
example,
are
totally
permissible.
So
one
other
thing
to.
Q
Point
out
yeah,
but
starting
something
with
a
period
I
think
is.
But
my
my
only
point
was
is
that
if
there
are
some
restrictions
that
you
have
on
these
DNS
D
elements
right,
I
think
we
ought
to
at
least
compare
those
to
those
elements
that
we
want
to
translate
from.
As
I
was
saying
it
because
we
ran
into
a
couple
of
gotchas
when
we
were
doing
some
implementations.
G
I
think
the
thing
that
I'm
the
point
I'm
trying
to
make
is
that
what
DNS
SD
will
accept,
as
an
instance
name,
is
fairly
broad.
So
if
an
organization
wants
to
say
well,
we
require
our
identifiers
to
be
like
this,
then
I
think
there
might
be
a
lot
of
flexibility
there
as
to
what
you
can
import
insure.
It.
Q
Q
N
Stewart
Cheshire
I'll
just
briefly
answer
that
question:
for
instance,
names
the
character
set
is
completely
unrestricted.
There
are
no
reserved
characters
that
the
way
characters
are
encoded
and
mapped
is
defined
rigorously.
So
there
are
no
dangerous
characters.
You
can't
use
any
valid.
Unicode
character
can
be
used.
There
is
a
length
limit
of
sixty
three
octets
of
normalization
form
Cayce
utf-8
to
text
that
gives
you
the
length
limit,
and
that
is
for
the
user,
visible
instance
names
which
are
intentionally
rich
text,
uppercase
lowercase
e
spaces,
punctuation.
N
Whatever
you
would
write
in
normal
human
communication,
the
service
types
are
machine,
readable
information.
They
are
never
normally
seen
by
humans
unless
you're
looking
in
Wireshark,
and
they
don't
need
to
be
as
expressive
for
coding,
convenience
they're
limited
to
15
characters
of
letters,
digits
and
hyphens.
So
those
are
the
two
character
set
constraints
to
be
aware
of
I.
Think.
G
One
thing
that
we
do
need
to
take
to
the
list
is
this
notion
of
potential?
Having
a
you
know,
federated
namespace,
just
maybe
a
happy
accident
that
the
Artie
directory
already
has
sort
of
these.
These
pre,
these
pre
labels,
like
oh
I,
see
and
Co
re,
and
that
sort
of
thing,
but
an
important
point,
is
that
the
service
type
does
have
to
be
registered
with
IANA.
So
one
thing
that
a
federated
namespace
would
afford
is
that
an
organization
would
only
have
to
go
and
register
this
label,
and
then
they
would
own
everything
under
that
label.
G
I
Dave
dave
taylor.
I
just
wanted
to
comment
on
a
different
topic,
which
is
the
underscore
UDP
and
its
relationship
with
the
presentation
that
I
gave
I
think
in
order
to
talk
about
this
in
awe
right
now
and
it's
Joe
mr.
strapp
zero,
zero
right,
so
I'm
saying
future
work.
Please
talk
about
how
you
cover
each
of
the
different
URI
schemes.
It's
in
there.
I
You
know
it's
how
you
distinguish
between
coop
and
co-op
s
and
how
you
would
handle
the
coop
plus
WS
schemes,
for
which
service
names
are
not
legal,
so
you
need
to
cover
those
in
order
to
have
a
complete
solution,
so
good
work
so
far,
keep
it
up.
I,
look
forward
to
draft,
oh
one,
which
covers
a
more
complete
solution.
Thank
you
all
right.
Thanks.
Thank.
J
J
G
J
Potentially,
but
there
is
a
there's,
a
there's,
a
default
TTL
and
but
it's
it's
not
a
default
value
in
the
in
the
resource
directory.
You
can
adjust
that
value
so.
B
M
This
draft
seems
to
be
going
along
pretty
well.
We've
made
no
substantial
changes
to
what
it
does
since
working
group
adoption.
It's
mostly
been
about
clarifying
things
at
one
point
we
put
some
stuff
in
that
we
thought
was
useful,
but
we
took
it
back
out
we're.
Basically,
the
philosophy
is
keeps
of
protocol
simple
we're.
You
know
not
trying
to
do
queuing
and
we're
just
doing
simple
notification.
We
have
ways
to
enhance
it
later
with
with
other
functionality,
we'll
we'll
touch
on
here,
but
you
can
go
find
out
more
offline.
M
We've
addressed
a
substantial
set
of
comments
that
are
going
to
be
feeding
into
the
next
update.
It's
really
really
good
set
of
comments
from
Jim
shod
and
for
reliable
notification.
Well,
basically,
what
we're
looking
at
for
the
more
involved
protocol
where
people
want.
You
know
some
notion
of
quality
of
service
and
queuing
and
some
other
things
we're
looking
at
a
thing,
subscriber
managed,
subscriber
manage
queues.
Basically,
so
you
can
subscribe
and
create
a
queue
and
I've
got
a
little
write-up
in
the
github
issues.
M
If
you
want
to
know
more
about
what
the
proposal
looks
like
for
that,
but
that
would
be
done
as
a
separate
draft
to
add
on
to
this.
We
think
this
draft
is
best
if
it
just
describes
simple
the
simple
notification
system,
so
the
roadmap,
where
we're
going
to
finish,
you
know,
addressing
all
the
outstanding
comments
to
the
next
drafts
of
all
the
ones
that
we've
already
addressed
and
then
any
more
that
we
receive.
M
There
are
a
few
substantial
decisions
that
that
would
impact
things
a
little
bit
in
terms
of
like
I,
guess,
sort
of
corner
cases,
special
cases
of
what
happens
when
you
do
this,
and
this
isn't
just
describing
what
happens
when
you
do
something.
That's
not
been
expected
or
not
been
accounted
for.
We
need
to
rework
the
normative
language.
There
was
a
suggestion
that
we
think
about
how
you
would
test
one
and
evaluate
the
normative
language
based
on
having
to
write
test
cases
and
that's
an
excellent
suggestion.
M
I've
learned
that
in
my
work
and
other
SDOs
that
that's
a
really
good
way
to
go
about
it.
So
we'll
do
that.
We
need
to
put
some
guidance
in
the
security
considerations,
that's
been
suggested
for
all
drafts
and-
and
this
can
be
beefed
up
a
little
bit
and
so
we'll
work
with
OS
co-op
our
profile
for
pub/sub
and
talk
a
little
bit
more
about
what
we
mean
by
access
control.
M
Even
though
there's
no
really
good
access
control
policy,
ACL
kind
of
thing
that
we
know
of
that's
kind
of
standardized,
and
this
isn't
the
place
to
do
it.
But
maybe
that's
some
future
work
and
we
want
to
target
the
working
group
last
call
for
the
Singapore
time
frame.
I,
don't
know
if
we'll
get
to
it
on
the
list
ahead
of
time,
but
we
think
we
can
resolve
everything
and
and
get
a
new
a
new
one.
M
B
For
that
drafted
that
comes
up
at
the
end
of
August,
it
would
be
really
good
to
I.
Have
some
people
who
know
that
that
they're
going
to
review
that,
and
so
so
I
would
check
to
us
who
has
read
any
version
of
the
pub/sub
document
Oh.
Quite
a
few
people
wait
so
who
would
be
willing
to
to
review
the
next
version
that
that
comes
out
in
August
Jim
already
did
the
previous
one,
honest,
Michelle,
Carrie
Peter
bill.
B
S
S
Slides
mm-hmm
and
if
I
say
something
wrong,
please
yell
or
maybe
a
slave
okay.
So
the
draft
last
submitted
version
of
the
draft
is
version
of
four,
which
was
no
major
change
from
version.
Oh
three,
mainly
including
the
use
of
the
request
sag,
which
is
this
option
defined
in
the
draft
presented
on
on
Tuesday,
and
it's
all
already
using
the
replay.
Those
are
the
repeated
tag
which
is
also
summarizing
this
new,
using
this
new
draft.
S
So
coming
into
this
meeting,
there
were
quite
a
few
issues
left
on
the
issue
tracker,
but
we
spent
a
good
deal
of
this
meeting,
actually
closing
off
a
lot
of
these
issues.
So
I
think
there
are
four
issues
left
at
the
moment
and
some
of
them
the
issues
mentioned
here
are
are
closed.
So
we
have
simplified
the
observe
option,
processing
and
we
have
taken
out
all
Scone
from
the
document,
because
that
needs
more
thinking
and
we
think
we
should
do
that
in
a
separate
craft.
We
don't
know
where
that
would
end
up.
S
S
S
So
a
lot
of
a
lot
of
people
good
thing
here.
A
lot
of
people
have
implemented,
read
the
same
draft
and
after
a
few
bug
fixes
they
actually
managed
to
interoperate
and
and
proceed
through
the
test
cases.
We
also
benefited
a
lot
during
this
meeting
sitting
around
the
table.
Closing
the
issues
with
discussion
among
the
implementer
was
the
best
way
to
do
this.
S
Q
Goran,
jim
carrey
nokia.
So
when
we
looked
at
the
draft,
we
had
a
couple
questions
and
I.
Don't
know
if
you're
addressing
him
in
the
dress,
I,
don't
think
I've
looked
at
it
since
maybe
Oh
right
there
was
some.
There
were
some
concerns
that
we
had
with
you
know
we
were
doing
end-to-end
security
and
we
were
able
to
do
object,
security
all
the
way
through,
but
we
still
had
headers
and
that
weren't
integrity
protected
or
confidential.
So
we
had
some
privacy
concerns
where
those
are
those
issues
addressed
or
are
they
going
to
be
addressed.
S
So
I
don't
recall
exactly
our
discussion.
I,
don't
recall
exactly
which
headers
we
were
discussing
there.
There
are
and
not.
If
you
look
at
there's
a
table
on
which
which
options
are
protected,
most
protect
most
are
encrypted.
Some
are
only
integrity
protected
because
of
coop
proxy
needs
to
read
them
and
so
I'm
watching
the
draft
today
I
think,
is
what
what
we
think
it
needs
to
be
protected.
So.
B
S
B
L
B
B
That's
great
until
you
add
security,
because
for
security
you
have
to
make
sure
that
you
get
exactly
the
right
way.
You
add,
otherwise
you
can't
verify
it.
So
the
situation
has
changed
a
little
bit
and
the
solution
that
Appendix
A
provides
is
adding
in
an
HTTP
header
field.
This
would
say:
had
a
field
not
worried
about
that
called
something
like
quiet
code
which
transports
the
the
coop
code
through
HTTP
segments
on
the
way
the
requested
responds
go
and
to
it.
B
So
this
is
not
really
an
s-curve
thing,
I
mean
other
uses
of
HTTP
co-op
cross
boxes
could
use.
This
so
looks
like
the
best
way
to
handle.
This
is
to
just
make
this
a
very
short,
separate
draft
that
defines
that
head
of
here
we
had
a
lovely
lunch
between
the
HTV
with
chairs
and
and
the
contrast
yesterday.
So
we
have
agreed
that
we
want
to
really
make
sure
we
solve
problems
like
this
together,
so
this
would
be
a
shorter
human.
We
can
give
them
and
say
this
is
what
we
we
try
to
do.
I
Coordination
where
they
should
feed
this
is
good,
separate
document
much
better
than
putting
into
the
same,
want
I
agree
potential
comments,
take
into
account
that
other
document
is
in
the
case
where
it
is
so
exactly
the
same
meaning
other
than
the
other
than
the
period
that's
in
there,
and
that
was
201
goes
to,
and
maybe
it's
only
necessary
to
put
it
in
there
when
it's
not
sort
of
exactly
equal
to
the
same
code
number
practice.
So
that
means
you
wouldn't
need
it
in
most
cases
needed.
You
know
protection
only
the
special
cases
you're
alluding
to.
I
I
B
B
Okay,
thank
you
so
I'm
very
impressed
because
we
talked
about
this
this
morning
and
I
am
in
coral
just
right
now
to
just
explain
you
a
problem.
We
are
feature
we
have
with
LP
one
radio,
so
we
have
devices
that
can
sleep.
For
example,
one
hour
send
a
message
sleep
again:
if
I
can
sleep
one
day
and
then
send
a
message.
B
So
if
we
want
to
secure
the
transmission
with
acknowledgement,
then
we
we
have
longer
time
that
what
has
been
defined
in
in
in
coop
right
now
for
the
server
the
server
has
to
maintain
them
to
a
list
of
message
ID
for
a
certain
period
of
time.
So
here
we
may
have
a
big
diversity
of
client.
Sometimes
that
can
be
very
reactive
and
client.
That
can
sleep
a
lot
of
time.
So
we
have,
we
have
to
say
to
the
server,
keep
this
number
longer
than
the
usual
things.
B
Q
F
Q
So
so
it's
probably
it's
probably
just
a
single
set
of
things
that
you
have
to
know
in
order
to
talk
to
that
thing,
but
you
still
got
what
do
you
do
with
the
the
information
you
want
to
give
right?
That's
the
thing
that
you've
got
a
queue
all
that
stuff
up
and
keep
it.
That
could
be
a
bit
problematic
when
you
start
talking
about
you
know,
what's
fresh,
what's
stale
some
to
consider.
B
Yeah,
so
it's
clear
that
this
is
a
requires,
a
little
bit
of
thinking
those
who
have
been
here
for
a
long
time.
We
remember
an
option
called
patience
that
we
discussed
here
and
then
at
some
point
decided.
We
did
need
it
and
this
may
be
resurrecting
the
patience
option.
So
maybe
you
want
to
look
for
an
old
draft
card,
Corp
misc,
that
we
find
that
patient
option.
B
F
Yeah
Eric
Nam
right
so
the
example
he
gave
its
honor
like
there's
only
one
message
or
two.
The
number
of
message,
whatever
IDs
you
have
to
track
is
one
per
client,
but
is
there
does
this
come
with
a
limit
on
that
as
well,
so
that
you
don't
have
to
store?
You
know
a
thousand
of
these
things
because
someone
said
it
24
hours,
but
we're
sending
a
lot
more.
All
right.
If
you
can
limit
that
it
might
be
a
loss
of
a
name.
Is
our
yeah
yeah.