►
From YouTube: IETF99-CORE-20170719-0930
Description
CORE meeting session at IETF99
2017/07/19 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
A
Who
else
wants
to
be
note-taker,
at
least
for
the
part
where
they
are
not
giving
a
presentation?
Maybe
there
is
an
inner
pad
for
doing
that,
so
you
don't
have
to
do
all
the
typing,
and
you
don't
do
that
question
or
are
you
busy
preparing?
Thank
you
and
please
note
the
note.
Well,
as
you
may
have
noticed,
we
actually
have
a
new
RFC
with
updated
IP
our
route.
A
But
of
course
the
the
actual
relevant
words
are
in
the
RFC's
pointed
to
here
and
in
the
very
short
version
s.
If
you
are
contributing
something
talking
here
in
the
work
group
and
are
talking
about
the
technology
technology
where
you
know
there
are
patent
claims
on
it,
you
have
to
tell
us-
or
you
can
choose
not
to
talk
about
the
technology.
A
Okay
agenda:
we
have
crude
up
some
of
the.
Why
does
it
say
to
you?
Sorry
today
is
Wednesday.
We
it's
going
to
say
Tuesday
about
ten
more
times
on.
Oh
it's
time,
walk
yes,
so
I
mean
just
go
around
the
earth
once
and
then
it's
still
Tuesday.
So
we
have
pulled
up
some
of
the
material
from
Friday
where
we
only
have
a
90
minute
slot.
A
So
we
will
do
a
quick
status
update.
Look
at
two
documents
that
are
in
the
is
G
right
now
then
look
at
documents
that
are
getting
ready
for
working
group
last
call,
and
then
there
are
a
few
things
that
have
been
pulled
forward
from
Friday.
We
have
a
little
bit
of
a
difficult
schedule
and
this
time
because
there
is
TLS
meeting
in
parallel,
so
we
had
to
push
some
of
the
things
through
Friday
and
that's
why
this
is
Friday
is
pretty
food.
C
C
A
D
A
Okay,
so
web
group
status,
one
RFC
got
published
between
the
last
meeting
and
now
our
C
eighty
one
thirty
two.
So
we
now
have
a
few
more
methods
in
coop,
the
patch
methods,
patch
an
eye
patch
and
a
method
that
is
called
fetch
that
that
name
rhymes
nicely
with
patch
but
may
be
confusing
to
people
who
know
about
HTTP
fetch
it's
something
that
is
called
HD
called
search
in
HTTP.
A
E
Thanks
for
the
advert
for
DNS
SD
I'm,
one
of
the
co-chairs,
so
we
have
an
internet
draft
that
Carolyn
Peter
van
der
stock
and
a
couple
of
other
people
have
written.
So
even
if
you
can't
make
the
meeting
I
urge
you
to
look
at
that,
it's
about
mapping
between
DNS,
SD
and
core
Rd
so
have
a
look
at
that
and
it's
on
the
agenda
towards
the
end
of
the
meeting.
So
even
if
you
just
pop
in
for
the
last
20
minutes,
you'll
have
to
be
able
to
take
part
in
that
discussion.
Okay,.
A
Okay,
looking
at
our
own
milestones,
we,
we
are
a
bit
late.
We
actually
managed
to
do
this,
my
song
here,
the
color
of
which
I
cannot
change
in
keynote.
For
some
reason,
you
have
to
find
out
what
anyway.
This
is
interesting,
because
things
came
up
during
the
IETF
last
call
that
we
want
to
talk
to
in
a
couple
of
minutes:
yeah
but
Senna,
Mel
resource
directory
and
the
COO.
My
work
are
in
this
meeting
and
I
hope
we
make
significant
progress
here.
A
Senator
will
complete
its
today
by
the
end
of
today,
I
think
so
we
might
be
able
to
clean
this
up
a
little
bit
more
another
interesting
development.
The
core
interfaces
document
has
had
some
personal
changes
and
now
has
had
another
round
of
personal
changes
and
no
I'm
quite
confident
that
we
will
be
able
to
make
progress,
but
we
probably
only
will
be
able
to
discuss
them
in
Singapore,
so
expect
something
happening
with
didn't
link
and
the
interfaces
draft
soon.
A
So
one
of
the
reasons
why
this
is
complicated
work,
even
though
the
drafts
themselves
are
not
so
complicated,
is
that
early
versions
of
these
documents
have
been
picked
up
by
other
SDOs
and
put
into
their
specifications,
and
we
just
have
learned
from
that.
So
it's
from
useful
to
look
at
that
again
and
see
what
what
the
result
is
on
those
documents.
F
I
Tim,
Carini,
okay,
I
just
have
a
quick
question
on
on
some
of
these
milestones
that
you
have
here
and
I'm
just
trying
to
get
an
understanding
of
potential
published
dates
just
to
try
to
figure
out.
What's
what
we
think
is
gonna
be
published
this
year,
maybe
what
we
pushed
off
and
next
year
because
I
get
these
questions
you
know
as
well.
So
you
know
for
with
respect
to
the
resource
directory
in
the
Sen
ml.
Do
we
actually
think
that
we're
gonna
get
a
something
published
this
year?
C
A
Okay,
just
just
to
give
you
about
my
personal
assessment
here,
Sentinel
I
think
we
can
process.
The
working
class
call
comments
on
Friday
and
then
we
will
take
a
couple
of
weeks
until
the
author's
have
something
that
can
be
pushed
through
the
ISU.
So
this
is
very
close
resource
directory.
We
had
a
pretty
productive
meeting
this
morning
and
the
author's
think
we
now
have.
A
We
now
understand
why
it
took
us
so
long
to
get
where
we
are
and
how
we
can
make
this,
or
we
can
finish
this
quick,
so
this
will
become
evident
on
Friday,
and
this
should
go
to
working
group
last
call,
maybe
after
one
or
two
iterations
and
koumi
of
course
is
a
set
of
documents,
and
we
will
talk
about
their
status
later.
But
at
least
one
of
the
four
documents
is
really
ready
for
working
last
call
now
and
the
other
ones.
A
Well,
they
do
require
some
more
coordination
within
the
ITF
which
is
happening
tomorrow,
so
I'm
also
confident
that
we
actually
can
get
all
these
documents
through
blast
cause
this
year.
They
may
not
be
published
this
year
because
there
are
steps
after
work
with
us
all,
but
we
should
be
able
to
process
them.
F
I'm
sorry
course,
cars
and
I'm
just
again
I'm
just
trying
to
figure
out
in.
Are
we
saying
that
the
the
documents
on
this
list,
or
just
the
the
Comey
said,
would
probably
not
be
published
this
year,
I'm
still
kind
of
curious
about
a
resource
directory
in
Santa
Mel,
because
we
kind
of
use
those
back
and
lightwei
them
down.
So,
yes,
I
I,
just
don't.
A
Know
again,
I
think
sentiment
is
the
most
advanced
at
this
point
in
time.
So
there
are
a
few
things
that
still
can
be
discussed.
Maybe
there
were
best
way
to
handle
those
things
is
to
just
not
include
them
and
put
them
in
as
extensions,
and
apart
from
that,
yeah
wait
until
this
evening
until
we
know
all
the
working
class
Carl
Collins
and
then
we
should
be
able
to
process
them
on
Friday.
So
it's
we.
D
A
F
A
A
A
It
defines
a
serialization
for
web
links
which
are
defined
in
59
88
and
it
also
profiles
59
88,
where
profile
is
well
a
bad
word,
so
yeah
we
took
59
88
and
and
took
what
we
like
and
maybe
ignored
what
we
didn't
like
a
little
bit
more
than
we
should
have
anyway.
So
this
document
has
been
out
there
a
long
time
has
been
the
basis
for
a
lot
of
work
in
other
stos,
and
now
it
turned
out
that
it's
useful
to
have
Jason
and
see
both
civilizations
apart
from
the
text-based
serialization
that
66
90
provides.
A
So
this
is
what
links
Jason
is
about
and
now
the
comment
that
we
should
have
thought
about,
but
didn't
was
well.
This
is
a
66
90
serialization.
Can
we
use
this
as
a
general
5980,
Age
civilization,
and
the
answer
is
so.
We
did
some
things
in
690
that
that
are
a
little
bit
a
key
for
that
one.
Is
we
essentially
disallowed
percent-encoding,
so
we
would
have
to
define
for
this
serialization
what
semantics
percent-encoding
would
have
and
the
other
thing
we
did.
A
We
defined
a
few
default
values
for
certain
elements
of
a
link,
and
we
might
want
to
look
whether
we
can
yeah
make
make
this
work
in
the
general
case.
So
people
don't
want
those
default
they
use
can
do
something
different,
so
that
would
be
a
change.
That
would
not
be
a
big
change,
but
it
would
be
a
change
that
we
would
want
to
coordinate
with
those
stos
who
have
picked
up
the
link
Jason
work
already.
So
this
is
one
area
of
work
now.
A
The
problem
here
are-
maybe
the
fortunate
thing
I
don't
know-
is
that
fifty
nine
eighty
eight
this
is
happening
so
59
88,
which
had
a
couple
of
places
that
were
really
not
very
well
defined
and
is
being
revised
and
a
number
of
bugs
of
potential
implementation
snags
are
being
fixed
and
number
of
clarifications
are
made.
So
what
is
called
link
attributes
is
now
called
target
attributes,
or
it
becomes
much
clearer
that
all
those
attributes
you
you
put
on
a
web
link
are
really
not
about
the
link
itself.
A
There
is
another
thing:
that's
happening
there,
the
the
new
version
explicitly
disowns
the
namespace
for
the
target,
actually
Goods
and
says
the
owners
of
Civilizations
should
coordinate
the
namespace
now
I
think
that's
a
really
useful
clarification,
because
we
were
kind
of
pushing
forward
and
backward
the
the
responsibility
for
managing
that
namespace
and
it's
now
clearly
defined
the
management
is
in
our
Court,
so
yeah
this
is
still
individual
draft,
so
the
consensus
process
has
not
completed,
but
if
that
actually
happens,
we
probably
should
do
that.
Alex.
C
A
A
Openings
of
link
forward
or
links
Jason
on
steroids,
coordinate
with
those
uses
and
variants
and
coordinate
with
other
stos,
so
lightweight
m2m
is
using
a
form
of
the
resource
directory.
All
cf
is
using
a
form
of
links,
Jason
and
there's
just
a
lot
of
people.
We
have
to
talk
to
to
find
out
whether
we
are
doing
something
stupid
and
so
yeah.
We
might
be
find
this
target
attribute
registry.
A
A
A
A
Now
this
document
has
received
osg
processing
and
one
big
comment
was
the
the
way
we
are
handling
your
I
schemes
is
not
good.
So
we
push
this
through.
The
is
three
as
oh,
seven
has
version,
oh
seven,
and
we
had
had
extensive
discussions
about
about
how
to
handle
multiple
transports
with
your
eyes
and
came
up
with
a
solution
to
have
one
URI
scheme
per
transfer.
That's
not
something
that
anybody
in
this
spectrum
particularly
likes,
but
it
came
up
as
the
the
least
worst
solution
that
we
could
come
up
with
now.
A
Of
course,
we
are
not
the
only
people
with
that
problem.
So,
while
we
are
going
through
the
URI
review
process,
OPC
UA
came
in
with
the
very
very
similar
requests.
They
also
have
three
different
ways
of
referencing
OPC
UA
resources,
and
they
were
trying
to
register
through
three
URI
schemes
as
well.
So
it
has
become
kind
of
obvious
that
maybe
there
is
a
bigger
problem
there
and
when
we
have
a
bigger
problem,
we
call
in
the
internet
architecture
board
I'm,
giving
the
microphone
if
they.
G
Okay,
so
I
actually
wrote
a
draft
in
between
last
IETF
and
SIF
and
there's
the
name
of
it
if
you're
looking
for
it.
So
I
gave
the
presentation
arch
area
on
Monday
and
I'm
going
to
be
giving
a
slightly
different
version
of
that
topic
and
glossed
over
a
couple,
things
that
are
outside
of
core
and
go
deeper
into
things
that
are
specific
to
core.
G
Those
schemes
are
now
actually
registered
that
the
ones
in
the
top
bullet
are
actually
registered
right
now
in
that
anti
registry
as
provisional
and
they
registered
to
ocf.
Now
the
message
from
ocf
said,
and
if
you
want
them
back,
you
can
have
them
back.
Okay
and
by
the
way,
the
the
process
for
your
RI
scheme
registration,
which
is
RFC,
75
95
who's
editor
as
me
actually
defines
a
process.
G
So
anyway,
because
of
these
three
things,
there's
all
kinds
of
emails
on
various
mailing
lists,
such
as
URI
review,
which
is
the
mailing
list
that
was
tasked
with
reviewing
requests
for
permanent
registrations,
which
originally
both
core
and
OPC,
were
asking
for
permanent
registration
right
ocf
was
asking
for
provisional.
If
and
only
if,
IETF
didn't
do
it
themselves
because
provisional,
you
can
do
anything
you
want.
However,
the
IETF
for
standards
must
do
permanent
right.
We
don't
have
the
option
of
doing
provisional
any
other,
but
we
don't.
G
Okay,
so
I
wrote
this
document
to
collect
the
different
ways
that
people
are
doing
things,
because
this
is
not
a
document
that
was
focused
just
on
core
because,
as
Carson
mentioned,
this
is
a
common
problem,
and
so
there's
different
people
do
things
different
ways,
and
so
it
surveys
a
couple
ways.
People
are
either
already
doing
things
or
are
proposing
to
do
my
own.
That
did
them
on
the
list
and
it
points
out
the
advantages
and
problems
with
each
of
those
approaches.
G
Okay
and
some
of
those
came
from
the
core
discussion,
some
of
them
came
from
the
other
discussions
and
references
to
even
older
discussions,
all
right.
So
there's
a
couple
documents
such
as
you
know,
the
w3c
has
a
document,
and
so
one
of
the
basic
principles
that
the
iesg
mentioned
and
the
w3c
mentioned-
was
this
notion
that
a
resource
as
named
by
say
an
application,
should
really
have
one
canonical
URI,
that's
independent
of
how
you
get
to
it
right.
G
So
if
you
address
changes,
you
don't
have
to
change
the
URI,
and
in
this
case,
if
the
transport
protocol
changes,
you
know
if
you're
using
UDP
versus
TCP,
if
it
really
is
the
same
resource,
if
you
can
name
it
the
same
thing
right,
that's
the
advantage
or
that
there's
an
advantage
of
that,
and
so
there's
documents
to
talk
about
that.
So
an
example
of
why
that
argument
is,
there
is
in
the
web
architecture.
Things
like
links
are
used
to
say
which
resources
are
more
valuable
than
others
right.
G
This
is
one
of
the
arguments
it's
made
in
the
in
the
architecture,
the
www
missus,
and
so
in
order
to
value
something
you
have
to
count
how
many
in
links
there
are
how
many
places
there
are
the
point
to
it
right
and
if
they
don't
want
to
the
same
thing,
it
messes
up
your
valuation
right.
So
that's
an
example
of
the
style
of
things.
G
Similarly,
you
can
make
the
same
argument
and
in
the
other,
in
like
3986,
which
has
different
ladder
levels
right,
which
is
how
do
I
compare
whether
to
you
our
eyes
are
equivalent
right
as
well.
There's
multiple
different
ways:
you
just
compare
the
string
right.
Do
you
take
care
of
other
types
of
things
like
dot
dot
resolution?
You
go
all
the
way
down
to
saying.
Is
there
information
about
the
specific
to
the
scheme
because
they
pristine
Connecticut
rules
or
do
you
actually
resolve
it
and
see
if
they
pointed
the
same
content
right?
G
So
the
point
is
that
there's
different
algorithms
specified
in
3986
and
that's
when
we
mean
by
latter
levels,
okay,
and
so
it
is
absolutely
legal
to
have
multiple
URIs
that
point
to
the
same
resource:
okay,
but
there's
a
reason
to
minimize
that,
and
so
we'll
talk
about
that.
Okay
now
3975
95,
sorry
in
order
to
get
a
permanent
scheme
it
had
to
list
of
requirements.
G
Okay,
the
list
of
requirements
in
that
RFC
does
not
include
this
topic,
and
so
the
interesting
thing
that
happened
was
to
say
well
is
this
something
that
is
a
blocker
for
this
document
or
not?
And
that's
what
actually
generated
some
of
the
process
discussions,
let
alone
the
technical
discussions
that
slowed
this
down?
G
It's
ocf
:,
it's
not
one
of
the
ones
that
comes
out
of
the
core
working
group,
okay
and
so
the
people
that
say
well,
you
should
be
using
one
common
yura,
that's
independent
of
prints
for
it.
Well
ocf!
Does
that
right?
It's
you
know,
hash
of
public
key
slash
whatever
the
rest
of
URI
is
okay,
but
you
still
need
a
way
to
get
the
actual
transporting
points
right.
What's
the
actual
you
know
hostname
or
IP
address
or
what's
the
actual
port
number?
What's
the
actual
transport
protocol?
G
Is
it
TCP
or
is
it
UDP
years
at
WebSockets?
Is
it
TLS
or
not?
You
still
have
a
way
to
resolve
those.
Once
you
learn
those
now
some
transports
that
we
work
over
like
WebSockets
already
uses.
You
know
you
our
eyes
is
the
way
to
name
endpoints
right:
it's
not
port
number.
You
have
to
have
something
in
D
MUX,
and
this
was
shown
in
draft,
oh
nine
right
and
so
for
consistency,
ocf
found
it
convenient
to
just
use,
URI
format
for
all
the
transports,
and
so
the
schemes
was
in
draft.
G
Oh
seven
was
great
for
that:
I
added
a
slide
on
that's
the
next
one.
That
will
show
an
example
now
how
you
learn
that
might
be
via
some
lookup
step,
which
is
take
this
your
I
do
some
step
to
resolve,
but
to
some
transfer
data
fires
or
it
might
be.
However,
you
got
that
URI
in
the
first
place.
You
also
got
the
other
information
that
came
along
with
it
right,
similar
to
when
you're,
resolving
a
DNS
name
or
when
you're
resolving
a
name
through
the
DNS.
G
You
might
get
back
some
additional
stuff
in
the
additional
records
section.
Thinking
saying
you
might
need
this
too
right,
so
there's
different
ways
to
get
it
now,
when
in
theory
this
could
happen
at
multiple
layers
right,
if
you
have
some
application
layer
protocol
that
sits
on
top
of
something
else,
and
that's
it
some
type
of
stop
of
something
else
and
in
each
of
those
is
a
fork
and
there's
multiple
possible
things
that
the
next
layer
down
it
can
be
really
complicated.
We
just
hope
that
that
is
really
rare.
G
Okay,
Jeff
Conine
started
introducing
that
case
as
you'll
see,
but
draft
o7
did
not
have
that
case.
So
here's
an
actual
example
for
those
of
you
in
front
row
that
can
bring
it
up
on
your
own
screen
in
the
back.
This
is
a
no
CF
example
where
the
red
is
the
top
level
API.
You
can
see
here
it's
split
into
a
base
URI
and
a
relative
reference
that
goes
along
with
it.
G
But
when
you
get
back
those
links
you're
getting
back
the
blue
along
with
each
one,
and
so
the
blue
contains
a
list
of
transport
layer
links,
okay,
so,
for
example,
in
the
first
one
is
accessible
only
overko
FS
and
the
second
example
actually
all
three
other
ones
successful
over
couette
s
and
co,
FS
plus
tcp,
okay.
So
the
point
is
those
aren't
really
supposed
to
be
used
by
the
applications.
They're
just
used
by
the
protocol
stack
to
say:
here's
how
I
get
the
transport
identifiers,
okay,
and
so
this
is
why
ocf
said.
G
Yes,
we
really
like
this
because
it
compresses
stuff
into
one
layer,
because
you
can
see
they
can
only
go
one
layer
down.
This
is
a
single
array
right.
This
isn't
a
tree
of
stuff
right,
and
so
if
this
was
saying
this
was
co-op
s
and
you
got
to
go
another
layer
down
to
get
the
WS
s
:.
That
was
in
graft
r9o,
see
I've,
said
well
that
doesn't
work
for
us
right,
because
we
can
only
do
one
level
of
stuff.
You
have
these,
it
works
great
and
they
already
submitted
their
draft
as
to
ISO.
G
Is
international
standard,
so
they're
past
the
point
that
they
can
make
a
change
right
now,
which
is
why
they
went
ahead
and
registered
them
as
provisional
now?
Could
they
do
something
different
in
the
future
possible?
But
for
this
version
of
the
standard,
that's
already
locked.
So
this
is
just
an
example
that
shows
an
upper
layer,
URI
and
lower
layer.
Api
is
you
can
think
of
this
being
like
an
ID
locator
split
where
the
locators
are
being
transmitted
in
the
syntax
of
a
URI?
Okay,
all
right!
G
So
now
to
finish
up
the
the
sort
of
the
conceptual
things
there
was
a
number
of
discussions
that
sort
of
concluded
so
I
try
to
tease
apart
the
notion
of
discovery
versus
selection.
Okay,
so
discovery
is
I.
Have
to
get
back
the
set
of
possibilities.
Okay
and
selection
is
once
I
know
the
set
of
possibilities.
How
do
I
choose
one
right?
Do
I
use
a
happy
eyeball
style
algorithm.
Do
I
use
something
else?
Okay,
so
most
of
this
is
not
above
the
selection
algorithm.
Although
that's
what
a
lot
of
people
want
to
talk
about?
G
G
Okay,
even
though
there's
a
whole
section
of
the
document
that
I
added,
because
everybody
wanted
to
talk
about
it,
so
I
captured
that
too,
okay,
so
there's
four
possible
discovery,
approaches
that
I've
seen
okay,
the
first
and
probably
the
last
two
means
the
one
of
the
next
slide
are
the
ones
that
are
the
most
relevant
to
us,
and
so
this
is
I'm
going
to
gloss
over
fairly
quickly.
Unless
people
have
questions
the
first
one
is
the
document
the
specifies
the
URI
scheme
specifies
it
and
you
hard
code.
It
right.
G
Tftp
is
an
example
of
that
you
can
read
the
bullets.
Second
example,
is
you
take
all
the
information
that
you
need
and
you
encode
it
into
a
single
URI?
Alright.
So
if
you
support
two
transports
with
different
port
numbers,
somehow
or
a
service
name,
that's
accessible
over
two
things:
you
encode
that
all
in
the
same
common,
URI,
yeah,
that's
really
ugly,
okay!
Next
one
all
right
number
three
is
a
set
of
your
eyes.
One
per
transport
stack
right,
that's
what
draft?
Oh
seven
did.
G
Okay,
that's
what
this
working
group
had
consensus
on
at
the
time
that
it
was
submitted
at
the
iesg.
This
of
course
results
in
there
being
multiple
equivalent
to
our
eyes
right,
multiple,
you,
the
point,
the
same
resource
that
differ
by
say,
URI
scheme
and
maybe
by
things
in
the
authority.
Components
such
as
you
know
a
port
number.
If
there's
a
port
number
present
okay.
Now,
because
of
that,
this
often
results
in
the
need
to
have
a
higher
layer,
API
I,
sorry
higher
layer,
URI
such
as
the
ocf
:
in
the
ocf
case.
G
Right
OPC
in
other
hand,
does
not
have
one
of
these
right
and
so
I
think
a
number
of
the
discussion
among
the
iesg
and
on
the
list
in
response
to
the
draft
o7
was
well
you're
missing
this
thing
right,
okay
and
ocf
said
we're
not
missing
it.
We
like
draft
o7,
please
right,
okay,
so
that's
kind
of
how
that
went.
Now
this
works
great,
unless,
of
course,
you
have
complex
stacks
with
multiple
layers.
So
for
most
purposes,
this
is
okay.
G
If
you
have
a
higher
layer,
one
and
a
set
of
lower
layer
ones,
but
if
you
can
ever
have
a
tree
of
stuff,
it
gets
more
complicated
and
we
hope
that
doesn't
happen
very
often
and
the
only
natural
place
to
very
to
have
multiple
transport.
You
are
eyes,
so
one
for
transport
stack
is
the
very
better
URI
scheme.
Yes,
there's
other
places
you
can
wedge
that,
and
the
draft
covers
that
too.
G
The
last
category
was
also
discussed
again
on
the
URI
review
list,
which
is
why
do
you
even
want
to
use
a
URI
format
for
that
right?
So
if
you
go
back
to
to
the
example
here,
right,
I
get
why
there
to
route
paraphrase
I
get
why
the
read
is
a
URI.
Why
is
the
blue
and
URI
syntax
and
not
some
other
syntax?
Those
would
be
sort
of
from
the
w3c
that
says.
Well,
those
things
are
sort
of
following
the
air
protection
is
world
wide
web.
G
You
should
be
something
other
than
you
are
eyes
for
that
you're
kind
of
messing
with
our
URI
stuff
right,
and
so
that's
that's
category
four,
which
is
using
a
format
other
than
you
are
eyes.
Okay,
now
the
disadvantage
is
that
if
some
of
those
transports
URI
is
the
natural
thing
to
use
such
as
a
web
socket
and
other
things
say,
raw
TCP
sockets,
there's
no
URI
scheme
for
a
raw
TCP
socket
right,
and
so
it
the
well.
No,
there
isn't
you're
looking
at
me,
weird
there's
this.
G
No
no
TCP
:
today
registered
there
could
be
five,
but
there
isn't,
and
so
the
disadvantage
is.
If
you
pick
something
other
than
the
other
than
URIs,
you
have
to
define
some
format
or
agree
that
you're
not
going
to
have
consistent
ones
across
transports
right.
So
if
you
have
some
application
layer
protocol
that
could
be
using
WebSockets
and
TCP
and
DTLS
over
UDP,
say
coop,
maybe
then
you'd
have
to
define
some
other
common
syntax
or
to
find
a
way
to
carry
things
in
multiple
syntaxes.
So
your
eyes
happen
to
be
convenient
for
that.
G
Okay,
and
so
the
advantage
of
three
over
four
is
just.
You
can
use
a
common
syntax
that
exists
okay,
but
that's
the
that's
the
debate
between
three
and
four
just
put
it
out
there
right.
That's
it
so
well-known
debate.
Now
those
the
four
categories
and
the
last
slide
was
specific
to
art,
which
is
that
particular
draft,
and
so
at
this
point,
okay,
that's
the
overview
and
so
I
guess
I'm
gonna
hand
it
back
to
Carsten
to
you
want
to
cover
this.
G
A
I
I
I
will
confess
to
some
frustration
about
this
whole
process.
I've
basically
ended
up
devoting
most
of
my
adult
career
to
working
on
service
discovery.
I
didn't
plan
that
I
thought
I
would
graduate
and
go
to
Apple.
Do
that
a
couple
years
and
move
on
and
it
turned
out
to
be
a
bigger
problem.
I
One
of
the
points
you
raised
Dave
is
about
the
port
number,
which
has
always
been
this
historical
anomaly.
I
would
argue
a
mistake
in
the
IP
architecture
in
in
Apple.
Talk
at
names
named
these
two
pools,
which
are
net
subnet
host
port
and
they
take
you
all
the
way
to
the
target
process
in
in
the
Internet.
I
A
typical
DNS
name
is
a
host
name
which
gets
you
to
a
piece
of
hardware,
and
then
we
go
oops.
We
forgot
to
specify
what
endpoint
on
this
hardware
and
then
you
tack,
:
ports
on
the
end
of
the
name,
so
that
the
pain
you
describe
about.
How
do
you
cram
the
port
number
into
this?
You
don't
describe
the
same
pain
with.
How
do
you
cram
the
IP
address
in
because
that's
looked
up
by
the
name
resolution
mechanism
and
I
know
you
know
this
well
Dave
with
DNS
service
discovery?
I
That's
why
we
used
SRV
records
because
SRV
records
remedy
this
omission
that
the
Internet
historically
left,
the
port
number
out
of
the
resolution.
I
wrote:
RC
67
60,
which
is
sort
of
the
requirements
document
and
there's
a
section
in
there
entitled
I
think
escaped
the
tyranny
of
well-known
ports,
and
it's
very
frustrating
to
me
that
I
wrote
this
up
15
years
ago
and
yet
we're
still
having
years
of
soul-searching
and
navel-gazing
worrying
about
how
to
solve
this
problem.
I'll.
Let
you
answer
that
first
in
the
Nano
7th
element.
G
So
I
think
two
or
three
points
ahead.
The
first
one
is
that
the
discussion,
our
own
service
names,
is
actually
one
of
topics
in
the
draft,
and
one
of
the
things
that
I
complain
about
is
that
that
you
can't
put
a
service
name
in
the
URL.
You
can
only
put
an
integer
where
the
port
number
field
goes.
Okay,
that
is
one
of
the
problems
that
causes
some
headaches
right.
G
Second
point:
in
the
examples
that
are
used
in
the
link
format:
whether
you're
talking
about
the
link
format
used
by
ocf
the
link
format
used
by
the
IETF
okay,
you
can
see
here
there
in
this
particular
example.
All
right.
If
we
looked
at
a
core
links,
example
you'd
see
something
similar
where
the
links
here
are
including
IP
address
is
not
the
unis
names
you
can
say.
Well,
you
know.
Why
is
that?
Well,
it's
because
they
don't
want
to
have
to
go
through
an
extra
step
of
DNS
resolution.
G
G
Okay,
you
could
say
yeah
and
the
other
two
that
minors
say,
because
this
is
for
constrained
devices
and
constrained
devices
already
have
to
support
a
particular
protocol
to
access
the
resource,
and
so
if
they
have
a
fixed
amount
of
code
space
available
than
implementing
two
protocols,
one
for
discovery
and
one
for
accessing
the
resource
as
more
expensive
than
having
one
protocol.
That
does
both
and
that's
why
they
did
this.
A
G
I
G
I
look
right
now.
The
main
argument
is
not
that
one,
the
main
argument
that
I
have
heard
from
people
right,
because
I'm
ATF
person
in
other
communities
right
the
main
argument
that
I've
heard
from
others
is,
we
don't
want
to
have
to
have
a
DNS
which
includes
mdns
implementation
in
these
tiny
devices.
I
Let
me
very
briefly
tell
a
little
anecdote
in
the
early
days
we
had
these
developer
workshops
at
Apple,
where
developers
would
come
in
be
like
hackathon
right.
They
bring
a
laptop
and
a
board
and
would
work
on
code.
One
of
the
ones
I
remember
little
device
you
could
still
bite
is
call
site
player
telnet.
It's
it's
a
little
box,
the
size
of
a
deck
of
cards.
I
It
goes
from
Ethernet
to
serial
ports.
If
you've
got
some
old
device
on
your
network
with
a
serial
console,
you
can
plug
this
dongle
in
and
now
you
can
tell
net
to
it
over
Ethernet.
This
thing
has
16
kilobytes,
not
megabytes,
16
kilobytes
of
flash
memory.
9
K
of
that
is
the
HTML
text
for
its
web-based
UI
and
in
the
remaining
7
kilobytes
he's
got
everything
else.
Ethernet
driver
our
IP,
dhcp
clients,
telnet
server
web
server
to
surf
the
UI
whole
deal
in
7k.
I
He
came
to
this
workshop
and
said
I
have
900
bytes
free
to
implement
multicast
dns
and
by
the
end
of
that
afternoon
he
had
this
thing:
advertising
both
its
telnet
service
and
its
web
UI
using
multicast
dns
in
900,
bytes,
and
that
product
is
still
on
the
market
today
and
it
still
has
16
k
of
flash
memory
in
it,
and
it
still
does
all
of
these
things.
I've
got
a
couple
of
them
in
my
house
to
connect
to
old
legacy
gear
with
serial
ports.
I
So
I
think
in
today's
world,
if
you
don't
have
900
bytes
of
code
space
left,
then
yes,
I
buy
the
argument,
but
anything
that's
gotten
more
than
900
bytes
of
free
code
space.
You
can
do
multicast
dns
anyway.
That
was
the
anecdote.
The
comment
on
this
slide,
which
I
think
you
alluded
to
Dave
but
I-
wanted
to
elaborate
on
it
because
I
have
come
to
realize.
This
is
a
more
subtle
issue.
I
I
I
So
in
the
discovery
step,
you
say
and
I'll
use
the
boring
old
example
of
printers
in
the
discovery
step
you
say,
I
want
to
print,
show
me
what
my
choices
are,
and
here
it
we
have
the
terminal
room
print
or
in
other
places
you
might
have
five
at
the
point
of
choosing
which
one
to
use
you
don't
need
to
know
the
IP
addresses
of
all
of
them.
You
don't
need
to
know
other
details
about
them.
I
You
just
want
to
know
enough
for
the
human
or
the
software
to
make
a
decision,
so
the
discovery
step
is
a
lightweight
operation
that
gets
a
brief
summary
of
each
service
on
the
network
when
you've
picked
one
to
use.
That's
the
step
when
you
need
to
know
the
the
contact
information,
the
address
and
the
port
and
maybe
other
details
about
it
and
in
the
example
of
printing
I,
don't.
I
G
H
G
I'm
going
to
pick
the
blue
one
without
having
any
other
read,
information,
okay,
and
even
if
there's
ones
that
are
mandatory
to
implement.
That
doesn't
mean
that
it's
actually
in
use
by
that
particular
server.
Right.
So
let's
say
one
is
we
for
only
as
a
server
and
one
is
v6
only
as
a
server
right
and
and
if
you're
a
v6
only
node.
G
I
And
the
reason
I'm
saying
that
is
that
the
transport
information
may
change
from
day
to
day
and
I'll
go
back
to
this
printer
example
on
on
on
a
laptop
forget,
iPhones
and
iPads,
but
on
a
laptop
you
typically
go
into
system
preferences.
You
click
the
plus
button.
You
see
a
list
of
printers,
you
select
one,
you
make
a
print
queue
for
it.
That
is
the
selection
phase
after
that
for
a
typical
news
that
they
set
up
the
printer
once
when
they
get
it
and
every
day
after
that
they
hit
command,
P
and
prints.
I
They
don't
need
to
browse
the
network
to
find
the
list
of
printers.
They
know
the
name
of
the
printer
they
want
and
they
say
how
do
I
connect
to
it
today
and
it's
DHCP
address
may
change
from
day
to
day.
If
it's
using
dynamic
ports,
the
port
may
change.
If
it
gets
a
firmware
update,
maybe
yesterday
it
didn't,
have
v6
and
stayed
so
the
details
of
how
you
connect
to
it
change
over
time.
The
selection,
especially
in
the
case,
setting
of
a
print
queue,
is
sort
of
a
once-in-a-lifetime
thing
and
to
conflate
the
once-in-a-lifetime
thing.
I
G
A
I
Costin
with
respect
this
is
an
argument.
I've
heard
a
hundred
times
in
many
different
situations
that
the
animal
working
group
gave
me
exactly
the
same
story,
which
is,
we
need
a
service
discovery
mechanism
to
discover
things
on
the
network
and
we
can't
use
Bonjour
because
that's
only
for
humans,
and
that
is
complete
nonsense.
I,
don't
know
where
this
myth
originated.
I'll.
Give
you
one
example
of
something
that
is
10
years
old.
I
Now
the
bonjour
sleep
proxy,
which
is
what
lets
your
iMac
go
to
sleep
and
still
be
doing
printer
sharing
and
file
sharing
and
screen
sharing.
Even
though
it's
gone
to
sleep
to
save
power
when
it
goes
to
sleep,
it
looks
on
the
network
and
says
I'm
going
to
sleep.
Is
there
a
sleeper
proxy
that
can
act
on
my
behalf,
while
I'm
sleeping
and
wake
me
when
I'm
needed
it
discovers
that
sleep
proxy
using
Bonjour?
The
service
type?
Is
sleep
sleep,
proxy
dot,
underscore
UDP?
I
It
does
a
browse,
typically
white
wireless
base
stations,
Apple
TVs,
anything
this
low
power
and
always-on
is
a
good
candidate
for
being
a
sleep
proxy,
so
you
may
have
four
or
five
on
your
network.
The
iMac
going
to
sleep
will
do
a
browse,
find
them
make
it
determination
which
one
to
use
connect
to
it
translates
records,
go
to
sleep,
we've
been
doing,
machine-to-machine
surf
discovery
for
10
years
and
I,
keep
being
told.
Bonjour
can't
do
machine
to
machine.
It's
only
for
humans
and
I
have
no
idea
where
this
myths
came
from.
J
Carolyn
I
think
I
had
two
comments
when
I
came
up,
but
now
I've
got
four
or
five.
So
first
comment:
I
want
to
make.
Is
that
I
agree
that
not
all
resources
are
services,
but
certainly
something
that
looks
like
a
restful
api
endpoint.
You
know,
I
think
we.
If
we
squint,
we
can
probably
see
that
there's
some
rough
equivalence
between
that
and
what
DNS
SD
is
traditionally
called
the
service
and
later
today,
in
DNS
SD
I'm,
giving
a
brief
presentation
on
how
to
map
between
those
two
systems
between
those
two
naming
systems.
G
I
didn't
there's
plenty
of
places.
You
can
write
a
widget
in
there
and
I
talked
about
a
couple
of
them
in
the
draft.
Okay.
Great,
for
example.
Right
you
can
have
you
know,
underscore
service
name,
dot,
underscore
tcp
dot,
the
rest
of
the
host
name
in
the
authority
and
the
host
portion
of
something.
If
the
scheme
defines
it
that
way,
all
right,
that's
legal!
J
The
third
thing
is
I
think
one
thing
that
might
have
gotten
lost
in
a
comment
that
Stewart
made,
which
turned
into
the
selection
discussion,
is
that
I
think
the
dominant
paradigm
for
discovery
is
that
you
know
ahead
of
time
what
you're
looking
for,
whereas
maybe
in
a
very
small
percentage
of
cases,
you
would
want
to
go
to
a
device
and
say:
okay,
what
can
you
do
both
the
use
cases
in
core
absolutely
yeah,
but
the
latter
I
think
is.
Is
you
know
really?
You
know
in
the
the
minority.
G
J
About
the
one
case
where
I
can
imagine,
you
know
that
it's
useful
yeah
and
the
fourth
point
is
that
I
think
the
response
can
potentially
be
driven
by
information
that
comes
in
in
the
request.
So
there
was
a
draft
that
I
was
responsible
for
a
long
time
ago,
called
XM
DNS,
where
we
were
looking
at
expanding
it.
You
know
to
to
a
larger
scope,
the
larger
multicast
scope,
and
essentially
we
used
the
the
type
of
address
in
the
source
field
to
drive.
J
What
came
back
so
if
it's
a
global
address
of
the
sender,
then
you
respond
with
you.
You
don't
include
the
link
local
address.
You
know
in
the
response,
because
you
know,
obviously
they
can't
do
anything
with
if
they're,
if
they're
off
link
or
you
assume
that
they're
off
link
and
so
that
information
is
not
particularly
useful
and
just
waste
bandwidth,
so
that
could
also
help
in
the
selection
process.
F
So
Tim
Kerry
Nokia,
just
a
quick
comment
on
Stuart
stuff
I
will
say
that
for
some
other
stos
that
are
doing
IOT,
they
actually
use
DNS
D
for
for
discovery.
We
don't
necessarily
have
to
constrain
pieces
of
it.
But
it's
interesting
to
note
that
if
you
can
put
an
MD,
NS
and
900
bytes,
you
guys
might
want
to
consider
it.
Now.
F
F
G
G
G
F
Well,
cause
the
protocol
negotiation
draft
as
I
understand
the
draft
and
I
guess
we'll
have
a
presentation
on
that
soon.
So
someone
probably
might
understand
it
better
than
I
do.
But
it's
supposed
to
be
where
the
the
client
and
the
server
can
negotiate.
The
alternative
transport
sets,
and
so
part
of
that
is.
F
A
G
Think
I
can
answer
your
question
if
it's
equivalent
to
like
the
ulcer
document.
That's
in
may
she
be
Biss
okay,
which
is
if
you,
if
I,
understand,
right,
you
open
up
a
connection
across
one
protocol.
You
ask
your
Pretz
alternate
transport,
so
now
you
get
it
so
it's
a
discovery,
step
that
says:
I
contact,
the
Machine
and
I.
Ask
it
okay,
and
so
yes,
that
solved
at
the
disadvantage
of
being
an
extra
round
trip
that
slows
down.
G
Latency
increases
bandwidth
compared
to
let's
say:
I
got
this
from
a
directory,
whether
that
directory
is
a
resource
directory
or
whether
it's
a
DNS
server
or
whatever
else.
Okay,
if
the
stuff
came
back
from
the
directory
using
the
term
generically
right,
the
net
wouldn't
have
to
have
as
many
round
trips
to
do
the
negotiation
right.
So
does
it
solve
it?
Yes,
but
it's
got
some
downsides.
F
G
We're
what
we've
seen
going
back
outside
the
scope
of
gist
core
right
is
that
different,
stos
and
different
applications
have
a
variety
of
use
cases
and
it's
very
difficult
to
come
up
with
a
ones.
Everybody
should
do
it
the
same
way,
and
so,
whatever
way
we
agree
on,
there's
probably
gonna
be
some
SEO
out
there.
That's
gonna.
Do
it
some
other
way
anyway.
So
the
topic
of
this
is
to
figure
out
what
we
do
with
the
URI
schemes
right.
What
the
IETF
will
do
with
URI
schemes
right.
G
We
can't
necessarily
control
what
other
stos
or
other
proprietary
implementation
are
going
to
do,
but
we
can
control
what
we're
gonna
do
in
the
IETF
okay,
and
so,
as
the
IETF
gonna
have
URI
schemes,
is
it
gonna
have
URI
schemes
that
are
sort
of
locator
level?
It's
gonna
have
ie
URI
schemes
that
are
sort
of
ID
level
or
is
gonna.
Have
URI
schemes
are
kind
of
both
okay
yeah?
That's
a
decision
we
can
make
that
can
control
our
own
destiny.
We
can't
necessarily
control
what
other
people
write.
A
I
I
A
A
A
You
want
to
do
that.
That's
fine
final
thing,
so,
just
to
remind
people
the
the
of
seven
that
we
gave
to
is
she
had
three
your
eye
schemes.
I
mean
what
one
was
defined
in
75
already
for
UDP
and
it
added
the
TCP
and
WebSocket
version.
I'm
going
to
do
not
say
all
the
same
thing
again
happens
for
coil
s
every
time
so
always
think
we
have
another
set
for
cord
s,
so
in
total
of
seven
left
us
with
six
URI
schemes
that
can
be
used
to
talk
to
a
web
server.
A
Now
we
talk
about
those
is
three
concerns
and
what
the
authors
tried
in
online
was
to
simply
be
find
one
URI
scheme
that
maps
to
all
three
transports
and
I
think
we
have
heard
why
that
that
doesn't
work
so
well.
So
the
compromise
that
is
now
all
currently
on
the
table
is
to
revert
to
or
7,
but
also
to
add
a
fourth
pair
of
your
ice
Cream's.
That
does
have
some
some
form
of
transfer
discovery
in
it.
A
Now
that's
a
wonderful
way
to
solve
the
impasse,
but
it
also
leaves
us
with
a
little
job
to
do,
which
is
to
define
that
fourth
scheme.
We
have
to
define
the
rules
for
this
thing
with
which
I
called
coop
+80
after
the
suggestion
of
here
so
all
transport.
So
this
would
be
a
UI
scheme
that
is
equivalent.
A
You
guys
give
me
your
eyes
of
which
are
equivalent
to
the
correct
code
plus
disappear
and
car
plus
WS
false.
Now.
This
is
a
little
bit
weird
because
we
have
an
equivalence
between
in
the
80s
scheme
and
the
transporter
specific
schemes,
but
it's
not
quite
clear
that
we
can
simply
stipulate
an
equivalence
between
the
transport
specific
schemes.
Maybe
we
can
do
that,
but
I
think
a
little
bit
more
thinking
is
needed
here.
A
G
Dave
favor,
my
belief,
is
that
the
intent
would
be
to
be
the
same
as
OCFS
intent
of
the
ocf
code,
which
is
a
thing
that
applications
should
use
unless
you're
some
really
low-level
application,
or
something
like
that
that
most
applications
would
use
co-op
+80
and
be
completely
oblivious
to
which
transport
scheme
it
was
or
what
other
locators,
what
the
port
number,
what
the
IP
address
or
whatever
else.
Yes,.
A
Yeah,
so
that's
one
way
to
view
it.
Another
view
is
that
the
area
where
we
need
these
additional
transport
actually
is
a
niche
within
the
current
ecosystem.
So
we
will
still
see
a
lot
of
use
of
the
UDP
only
scheme,
because
that
that's
a
very
normal
way
for
a
very
constrained
device
to
operate,
but
the
fun
part
is,
we
could
define
multiple
of
these,
encompassing
your
ice-creams
I
mean
ocf
already
has
one
so
we're
just
adding
one,
and
then
the
third
organization
comes
there
and
adds
another
one.
G
So
take
sailor,
the
side,
nobody
asked
the
question
so
I
was
asking
myself
in
my
head.
If
couette
+80
were
defined
and
let's
pretend
that
it
was
even
draft
o7
what
ocf
use
it
and
I
suspect
the
answer,
as
depends
on
how
you
define
it
bordering
on
no,
but
not
necessarily
no,
and
the
reason
was
because
the
ocf
scheme
has
multiple
transports
right
now,
which
include
the
various
co-op
ones
and
the
various
HTTP
ones.
G
And
so,
if
you
have
a
resource,
it's
the
same
restful
resource,
that's
available
over,
say,
Co
app
with
one
or
more
transports
and
ACP,
then,
would
you
be
able
to
use
the
couette
+
80
scheme
or
not?
That
depends
on
how
you
define
it?
If
the
answer
is
yes,
then
in
theory
it
C
it's
it's
similar
to
what
ocf
did.
G
Okay
at
least
subject
to
this
there's
a
different
constraint
as
well
that
I
won't
go
into
right
now,
unless
you
ask
which
I'm
happy
to
I
wish
I
see
with
the
security
stuff
and
so
we'll
get
to
that,
and
that
probably
another
might
comment
or
two
probably
so.
I
may
come
back
to
talk
about
that,
but
here
the
question
is
as
couette
plus
I
T
is
inherently
kept
specific,
or
is
it
not
inherently
co-op
specific
kind
of
thinking
about
the
alt
service
discussion
here
that
says?
J
So
the
reason
I
said
that
Dave's
answer
previously
was
what
I
was
hoping
to
hear.
Was
that
I
look
at
this
as
we
painted
ourselves
into
a
corner
that
we
didn't
know
we
were
in
when
we
did
coop?
We
are
now
getting
ourselves
out
of
that
corner
with
coop
plus
80
and
I
would
like
to
see
us
move
toward
that,
and
now
Carsten
said
oh,
but
if
you
know
you
don't
need
the
new
features,
then
you
can
still
use
the
old
one.
J
I
would
really
prefer
to
see
us
move
rather
than
have
both
of
them
actively
in
use.
Although
the
other
side
of
it
is,
you
said
all
the
scheme
is
not
even
used,
because
you
know
what
you're
doing
and
you
do
you
don't
actually
pass
the
you
are
eyes
around,
which
is
different,
but
I.
Think
if
we
use
the
URIs-
and
we
do
this
strange
mechanism-
I'd
rather
see
us
move
to
it
rather
than
leave
the
old
one
as
recommended
still
and
obviously
it's
going
to
exist
and
people
can
use
it,
but
I'd.
G
My
current
belief
is
that
it's
gonna
take
a
while
to
do
the
details
to
be
worked
out
and
that
so
my
proposal
would
be
the
details
to
be
worked
out
being
a
separate
draft
than
the
current
draft
and
it
contained
a
sort
of
a
forward
reference
to
say
you
know
future
left
for
future
work
as
the
following
requirement.
That
needs
to
be
done.
G
Okay,
and
so
the
details
of
what
couette
+80
is,
is
in
a
different
document
such
that
you're,
defining
the
things
that
applications
aren't
supposed
to
use
here
and
then
the
things
that
people
are
supposed
to
using
a
different
document
and
that's
because
things
like
ocf
and
the
organisation's
already
have
protocol
implementations
of
the
coop
plus
tcp
protocol.
And
if
you
are
not
using
the
URI
scheme
as
your
syntax
for
the
locator,
then
you
don't
actually
care
about
this
discussion
right.
G
And
so
you
don't
want
to
slow
down
the
protocol
stuff
going
to
RFC
for
people
that
don't
happen
to
be
ocf
is
using
your
eyes
as
the
syntax,
but
other
people
don't
have
to
right,
and
so
that's
why
I
would
propose
that
we
could
be
coupled
and
put
into
a
different
document
and
saying
let
for
future.
Work
is
great.
G
G
C
A
A
C
A
A
That
looks
a
lot
like
the
alternative
service,
an
approach,
and
the
other
point
is
if
we
want
to
support
this
discovery,
we
have
to
provide
the
places
in
the
discovery
infrastructure
that
we
are
building
to
provide
that
information.
Now
DNS
already
has
service
records,
but
if
we
are
not
using
DNS,
then
we
have
to
find
a
place
to
put
that
the
link
attributes,
which
are
now
called
target
attributes
of
the
link
format
of
the
resource
directory,
provide
us
with
one
way,
and
we
probably
should
look
into
the
the
various
discussion
documents.
A
K
Got
this
bill
from
deity
yeah
the
times
take
about
IETF.
Is
that
usually
things
preceded
a
regular
reason
pace?
And
then
it
comes
the
idea
of
meeting.
Suddenly
everything
happens
so
that
these
slides
were
prepared
when,
when
we
before,
we
had
the
discussions
with
Carsten
and
a
few
others,
so
the
the
reason
why
there
are
two
drafts
instead
of
one
is
that,
while
the
alternative
transports
draft,
which
was
commissioned
or
charted
or
requested
for
trying
to
identify
the
transport,
a
co-op
resource
can
be
exposed
with,
can
be
done
with
a
URI.
K
We
also
noticed
a
similar
problem
about
how
to
discover
the
multimodal
transport
endpoints
and
and
that's
why
there
are
two
drops
and-
and
these
two
draft
to
color
have
their
own,
but
recent
discussions
for,
for
these
two
features
were
very
useful
for
alternative
transports.
What
I'd
like
to
say
is
that
the
current
draft
analyzes,
why
you
cannot
put
the
transport
information
anywhere
else,
then
the
URI
scheme.
K
It
does
not
say
why
we
need
a
URI,
so
that
is
something
that
drove
needs
to
do
and
just
before
Carsten
I
discussed
about
the
coop
80.
That
was
one
of
my
compromises
that
we
can
use
coop,
plus
80
for
doing
other
things
than
the
you
are
a
proliferation
and
for
protocol
negotiation
for
multiple
transports.
What
I'd
like
to
say
is
we're
going
to
try
to
work
on
ensuring
that
we
could
use
the
document
as
a
means
to
discover
the
multiple
transport
endpoints
and
the
origin
server
with
or
without
resource
directory.
Thanks.
A
L
So
let's
take
a
look
at
the
status
of
the
draft,
so
the
last
revision
is
still
zero,
one,
which
is
the
one
that
was
presented
in
Chicago
and
after
that
hi.
My
Center
heads
up
on
this
document
before
the
intended
working
group
last
call.
The
heads
up
was
sent
to
the
core
and
TCP
on
working
groups
and
also
to
the
ICC
research
group.
So
after
that
we
received
two
detailed
reviews,
one
by
Michael
Schaff,
another
one
by
Ingemar
Johansson.
L
So
let's
take
a
look
at
the
feedback
we
received
and
which
is
our
position
under
comments
received
and
our
plans
for
the
updates.
So
in
Cocoa,
as
we
may
recall,
we
are
defining
an
RTO
estimator
which
makes
use
of
strong
and
weak
our
titties
so
the
week
our
titties
are
those
that,
where
the
sender
has
run
into
retransmissions,
so
Michael
had
a
comment
that
we
would
be
possibly
violating
our
RFC
80-85,
which
contains
this
statement
that
latency
samples
must
not
be
derived
from
biggest
transactions.
L
However,
what
we
are
here
is
that
we
are
not
violating
that
statement,
because
we
don't
use
only
weaker
titties.
We
have
both
stronger
titties
and
also
we
gotta
DS
and
possibly
we
may
be-
might
need
to
make
it
clear
that
McCarty
teas
are
actually
needed
in
order
to
allow
updating
the
RTO
estimate
in
some
specific
conditions
where
otherwise,
it
would
be
very
difficult
or
even
impossible.
L
So
some
examples
are
links
where
there
is
high
bitter
rate.
Maybe
there
can
be
intervals
of
very
bad
in
quality,
with
lots
of
losses.
Therefore,
it
would
be
a
high
amount
of
weak
art.
It
is
there
then
another
example
is
a
network
where
congestion
suddenly
appears,
and
then
the
RTT
suddenly
increases
significantly.
In
that
case,
there
would
be
spurious
timeouts.
L
L
So
one
thing
we
are
considering
is
to
make
the
impact
of
strong
and
weak
art.
It
is
something
tunable
so
currently,
what
we
have
is
that
the
contribution
of
the
strong
estimator
and
the
weak
estimator
is
the
one
that
you
can
see
on
the
slide,
with
a
weight
of
0.5
for
the
strong
estimator,
a
weight
of
0.25
for
the
weak
estimator.
L
However,
we
are
considering
to
make
this
something
tunable,
for
example,
by
using
parameters,
configurable
parameters
like
the
ones
shown
in
red
on
the
slide,
and
we
would
use
default
as
the
fault
values
for
these
parameters,
the
ones
we
have
been
using
so
far,
0
25
and
0.5.
So
the
idea
here
is
to
be
able
to
tune
cocoa
and
to
tune
which
is
the
impact
of
each
one
of
these
2
estimators.
For
the
network.
Where
this
is
to
be
deployed,
then
we
received
a
number
of
editorial
suggestions.
First
of
all.
L
L
Then,
in
section
4
we
have
some
text
where
we
explain
that
in
coop,
there's
application
processing
time
that
is
relevant
here
for
RTO
calculations,
whereas
that
would
would
not
be
relevant
for
tcp.
However,
Michael
had
a
comment
that
we
might
want
to
discuss
the
impact
of
TCP
delayed
acknowledgments.
So
we
plan
to
incorporate
this
into
the
document
and
explain
the
TCP
delayed
acknowledgments.
We
had
typically
delays
of
200
milliseconds
even
more
in
principle
and,
on
the
other
hand,
in
coop.
We
have
separate
responses
where
delays
of
up
to
one
second
might
be
incurred.
L
Then
in
the
specific
part
of
subsection
for
the
two,
we
have
received
a
request
to
better
motivate
which
are
the
the
properties
and
the
reasons
for
the
week
estimator.
So
we
plan
to
incorporate
this
as
well.
This
is
reasonable,
because
actually
this
is
as
far
as
I
can
tell
possibly
the
first
time
that
something
like
this.
This
kind
of
week,
estimator,
is
being
used
in
the
IDF
and
also
we've
been
asked
to
add
a
few
more
examples
and
even
pseudocode
to
make
it
clear
how
the
different
steps
of
the
algorithm
need
to
be
applied.
L
Then
we
may
need
to
add
a
few
references
to
RFC
72-52,
mostly
for
readers
that
might
be
not
so
familiar
with
coop
with
the
terminology
and
also
with
details
on
its
behavior
and
then
my
had
a
comment
about
something
that
could
be
useful
for
the
security
considerations
that
maybe
an
attacker
might
want
to
drop
packets
in
order
to
increase
the
RTL
and
therefore
the
great
network
performance.
So
this
may
be
mitigated
by.
M
L
Access
control
and
if
the
attack
is
performed
by
means
of
radio
jamming,
then
we
are
that
the
network
may
recover
in
a
reasonable
time
if
cocoa
is
used
actually
in
a
smaller
time
than
that,
with
the
fault
coop
and
here
again,
the
weakest
team
in
the
weak
estimator
would
be
really
useful.
So
we
plan
to
incorporate
this
into
the
document.
Finally,
on
the
appendices
of
the
document,
the
first
one
is
Appendix
A,
which
describes
an
algorithm
for
aggregate
congestion
control.
L
So
this
is
an
algorithm
that
was
not
so
well
evaluated
as
the
core
of
the
document,
so
our
intention
was
to
actually
remove
this
part
from
the
draft
and
the
feedback
we
received
actually
confirms
this.
So
unless
there
are
objections,
we
will
remove
this
in
the
next
update
and
the
other
appendix
is
a
summary
of
results
and
pointers
to
detail
documents
with
detailed
evaluations,
and
the
comments
have
been
that
this
appears
to
be
a
useful
appendix,
because
it
supports
the
mechanisms
that
we
are
defining
here.
M
I
will
start
by
a
summary
of
where
we
had
for
about
the
kamae
framework.
We
have
four
drafts.
First,
one
is
the
yank
to
see
bore,
so
that's
the
mapping
between
the
yang
data
model
and
the
C
bore
encoding
that
is
stable
for
two
ietf.
We
don't
expect
to
do
anymore
changes,
so
we
believe
that
it's
ready
for
working
group
Glasgow
that
some
that's
the
question
that
will
be
had
by
Alexander
later
during
the
presentation.
M
Second
draft
is
the
it's
about.
The
identifier
used
by
comidas
said
that
that
draft
described
a
registration
process
so
right
now
we're
working
to
to
to
establish
a
website
for
registration.
So,
during
that
that
work,
we
we
might
need
to
adjust
the
draft
so
that
that
work
will
be
done
between
between
this
IDF
and
the
next
one,
so
that
that
one
not
ready
but
we're
working
on
it.
M
M
It's
not
ready
for
prime
time
but
I
think
all
the
technical
content
is
in
the
draft.
We
we
just
now
need
more
reviewer,
the
last
one.
It's
a
data
model
used
for
application
discovery,
the
yang
library
in
Chicago
there
was
discussion
about.
Is
it
the
right?
Is
it
in
scope
for
cores
at
the
right
forum?
So
that's
a
question
that
will
need
to
be
answered.
M
A
So
basically
I
think
we
we
have
tomorrow's
metal
meeting
to
find
out
what
a
good
division
of
work
would
be
here.
So,
of
course,
we
would
be
the
working
group
to
do
mids
for
coop.
So
yes,
fundamentally,
it
should
be
possible
to
do
the
kind
of
work
here,
but
maybe
there
is
another
group
that
has
the
better
experts
for
this.
So,
let's
find
out
now,
okay.
D
Yeah
this
is
st.
vocals
and
we
are
facing
a
similar
decision
problem.
We
wanted
to
start
at
a
coup,
my
yang
module
for
software
venturi
and
we're
also
considering
are
we
going
to
get
comfort
which
the
others
work
here
core
in
the
end,
because
I
think
we're
pretty
sure
that
we
know
how
to
do
the
concise
representation
stuff
and
that's
all
done?
D
M
A
So
the
the
hub
of
any
assembly,
you
need
three
groups
of
experts,
you
need
people
who
know
that
the
yang
word.
You
need
people
who
know
the
constraint
word
and
you
need
people
for
this
specific
subject
matter
like
your
software
identification
and
so
on.
So
that's
always
a
little
bit
hard
to
to
put
somewhere.
We
will
put
it
somewhere
and,
let's
figure
out.
M
M
A
M
M
M
M
M
Next,
one
is
the
selector
used
by
the
fetch.
It's
an
array
of
identifier
del
thank
coding
is
sibling
and
the
last
one
is
used
by
the
patch.
So
it's
an
order-
map
of
instance,
identifiers,
so
instance
in
identifiers
yang
data
type
used
to
point
on
it.
We
can't
stand
so
we
have
those
lists,
of
instance,
and
identifiers
and
new
value
when
the
new
value
is
a
null
means
deletion.
If
the
value
is
not
present
is
inserted.
If
it's
present
is
updated,.
M
So
that's
the
all
the
method
supported
by
kamae
and
the
associated
content
format.
So
for
access
to
data
note,
we
use
values,
access
to
data
store,
we
use
trees,
the
fetch
use
the
selector
and
values
and
the
patch
use
the
patch
so
that
that's
a
good
summary
of
what
kamae
is.
So
all
all
the
different
methods
ported
by
c'mon.
M
The
order
map
we
have
a
formal
description
of
that
semantics.
We
have
requested
a
tag
for
it
as
a
seaboard
tag.
We
don't
use
it,
but
it
will
be
available
for,
for
other
application
in
our
case
is
infer
when
we
do
the
content
format
define
me
if
it's
used
or
not,
so
we
don't
have
to
spend
by
to
to
put
the
tag.
M
Ok,
another
area
where
we
work
a
lot
is
the
earn
and
Lane
we
terrified,
there's
two
type
of
error.
We
have
the
coop
error,
we
know
we,
we
love
or
we
hate
what
other
those
error
already
defined
in
coop,
and
we
have
error
layer
related
to
to
yang
defining
yang
for
the
implementation
of
those
error.
We
use
restaurant
as
a
reference.
M
So,
on
the
left
side
we
have
the
the
payload
structure
of
restaurant.
On
the
right
side
is
the
proposed
payload
for
kamae.
One
modification
we
did
is
to
remove
the
ability
to
return
multiple
error
in
restaurants.
You
could
have
a
list
of
error,
so
income
I
will
return
just
the
first
or
more
important
error.
M
M
M
We
did
the
change
in
the
name
of
error
path.
We
don't
use
path
in
kamae,
so
new
name
is
data
node,
an
error,
not
sure
the
right
name,
everything
start
by
error
and
not
that
one.
So
we
might
revisit
that
name
and
error
info.
It's
it's
an
object
associated
to
the
error
that
can
be
returned
that
that
have
been
removed.
If
people
believe
it's
really
needed,
we
could
add
support
for
it.
But
at
this
point
we
don't
see
much
much
more
need
for
that.
M
Most
of
them
are
specifically
are
defining
yang
one
point:
one:
some
of
them
are
described
in
the
text,
but
there's
no
tag
defined
for,
for
example,
not
in
ranch
in
yang
they
say
invalid
values
return
if
the
ranch
doesn't
fit,
but
don't
define
any
application
tag
for
that.
So
we
just
define
those
tag
and
since
they're
optional
people
could
could
could
use
it
or
not
use
it.
They
could
just
return
invalid
value
or
could
return
invalid
value
because
of
the
ranch
of
because
of
the
pattern.
M
N
Thank
thanks
Michelle
for
this,
so,
as
you
see,
we've
done
a
huge
amount.
Cheryl
has
done
a
huge
amount
of
editorial
work
and
Peter
also
had
a
lot
on
this.
So
all
these
things
that
you
see
here,
we
are
great
upon
on
the
past
tight.
Yes,
so,
as
you
see,
it
is
simple
to
say:
okay,
introduce
one
content
format
so
that
we
can
introduce
content
formats
so
that
we
can
distinguish
between.
You
know
the
different
type
of
things
that
are
happening,
and
then
we
actually
get
down
to
the
dirty
work.
N
Doing
we
end
up
with
all
these
things,
but
right
now
it's
pretty
clean,
so
we
have
at
least
at
least.
We
know
that
we
have
two
independent
implementations
as
of
today,
because
there
were
some
last
minute
work.
They
are
slightly
incompatible
with
each
other.
There
are
really
very
small
differences,
so
we
have
one
implementation
in
go.
N
N
Yep,
so
that's
does
the
first
point
so
as
it
is
of
now.
We
would
like
to
go
over
this
inter
up
in
the
in
the
following
month,
so
that
we
are
pretty.
We
were
clear
that
you
know
if
there
are
any
minor
ambiguities
in
the
texts
that
they
are
clear
are
clear
out
and
we
can
go
into
working
with
a
group
last
call
for
this,
so
here
I
put
ITF
99,
but
I
think
it
would
be
wiser.
To
put
it
last
call
before
the
IGF
in
Singapore.
A
N
N
So
if
there
are
no
questions
on
this,
let's
move
to
the
shortest
presentation,
I
hope
I
will
be
making
today.
So
this
is
the
Seabourn
coding
of
data
model
yang,
which
we
consider
very
stable.
There
are
no
negative
commands,
no
bugs
no
nothing.
So
we
have
two
options:
either
we
do
a
working
group
last
call
now
or
if
you'd.
Rather,
we
can
wait
for
the
comma
interrupt
during
the
summer
and
do
the
last
call
later
the
for
this
one
and
the
comma
together.
But
they
are
not.
You
know
they
can
be
independent.
So.
A
A
Okay,
that's
about
four
weeks
from
now
so
I
think
that
sounds
like
a
reasonable
time
to
wait,
but
there
is
no
other
blocking
on
this
document
that
I
perceive
so
I
think
we
could
bring
Googlers
call
it
now,
but
without
implementation
feedback,
that's
not
so
bright.
So
I
think
it's
better
to
wait
for
that
round
of
implementation
feedback
and
then
go
for
work,
no
glass
core
right
there.
Okay.
A
Call
after
the
inter
up
in
August
right
well
is
assuming
we
don't
have
to
do
major
surgery
on
the
document.
As
a
result
of
that
feedback,
yeah
I
mean
we
probably
will
find
another
T
that
needs
to
be
stroked
and
another.
That
needs
to
be
dotted,
but
essentially
we
are
just
holding
the
document
we
have
Y
with
the
co.
My
document
I
would
expect
the
angel
actually
to
bring
up
a
little
bit
more
stuff.
So
we
spin
this
document.
It
will
be
a
little
bit
later
in
the
tag
line.
N
So
that
that's
that
sounds
good,
so
does
the
status
of
this
document,
and
just
to
recap
like
this,
gives
you?
Okay,
if
you
have
a
yang
model,
how
do
you
represent
it
in
Siebel
right?
There
is
a
equivalent
in
JSON
and
XML.
So
nothing
too
fancy
moving
on
to
the
door
yang
scheme
item
identifier,
so
this
is
also
a
draft
where
a
lot
of
the
things
that
are
out
there
are
pretty
clear.
N
So,
from
the
last
time,
we
had
four
main
topics
to
clear
out
the
definition
of
a
sip
that
it
is
a
64-bit
identifier
to
clear
out
the
receipt
file,
format,
the
city
lifecycle
and
the
allocation
policies.
So,
since
the
last
time
we've
cleared
out
most
of
these
of
these
points,
the
only
small
question
is
actually
I
mean.
We
were
pretty
clear
with
everything
the
way
it
worked.
N
So
I'm
going
to
be
talking
about
this
on
the
next
slide
and
just
to
give
you
an
update
on
the
action
points
that
we
had
since
the
last
time,
so
things
that
we
discussed
in
in
the
working
group
and
that
we
said,
okay,
we'll
do
the
changes
to
the
document
modify
the
draft
to
introduce
mega
ranges
organize
a
meeting
with
net
mod
in
a
tree
on
this
IGF
and
provide
a
registration
procedure.
So
the
first
two
are
done
tomorrow.
N
We
have
a
meeting
it's
a
side
meeting
and
that
there
is
so
an
on
working
group
mailing
list.
So
please
subscribe
to
it
the
yang
of
things
tomorrow
we
are
from
10
to
212
I'll,
be
talking
a
little
bit
more
about
this
later
and
I'll.
Try
to
be
really
brief
on
this
and
then
when
we
were
discussing
the
yang
registration
procedure,
we
actually
wanted
to
discuss
something
something
with
you
on
this,
and
this
is.
N
So
the
seeds
are
actually
where
you
allocate
the
numbers,
and
then
you
have
another
registry
that
you
keep
the
yang
files
so
that
whenever,
whenever
you
have
a
number,
you
can
actually
find
out.
Well
what
this
number
tells
you,
what
what
it
does
represent
and
the
way
it
works
today.
So
the
the
work
flow
is
as
an
end
user
or
developer
or
whatnot
yeah
yeah
more
the
developer.
N
What
they
will
typically
do
is
well,
they
request
a
seed
range,
they
get,
they
get
allocated
this
age
range
and
then
they
go
on
their
daily
lives
in
developing
young
modules
and
so
forth
within
the
CID
range.
That
was
allocated,
and
so
that's
really
cool
and
neat,
but
as
it
is
of
today,
there
is
no
really
implicit
way
of
actually
making
people
share
the
Yank
files
right
other
than
okay.
It's
really
good
for
the
system
for
the
community
for
the
society.
N
Well,
it
is
up
to
their
discretion
to
go
there
and
publish
the
the
yang
file
that
they
that
they
did
so
that
that's
one
thing
and
we
could
keep
it
as
it
is.
We
would
like
so
that
it's
really
good
for
private
module
registration
right.
This
is
a
must.
This
is
a
must,
because
people
they
would
like
to
be
able
to
register
private
yen
files
for
for
their
internal
consumption.
N
Now
the
things
that
we
would
like
to
investigate
without
slowing
down
the
documenting-
and
we
would
like
to
get
into
individual
authorities,
how
can
we
incentivize
public
yang
module
registration?
Well,
we
have
this
link
where
you
know
you
develop
your
yang
module.
There
is
an
experimental
range,
and
then
you
basically
push
it
to
the
to
some
public
registry.
It
can
be
yang
catalog,
it
can
be
something
else,
and
then
you
know
you
directly
get
the
city
file
with
the
allocated
directly
from
there,
and
so
then
you
know
the
public.
N
Can
you
know
anyone
can
just
go
there
and
look
up
from
the
sea
the
yang
file,
and
it
will
all
work
out
pretty
well.
So
this
is
like
an
slightly
open
question:
how
do
we?
How
do
we
do
it?
And
of
course
there
are,
you
know
things
to
discuss
what
we
would
like
to
do
and
the
way
we
are
actually
addressing
this
question
is
to
say:
well
today
we
have
an
implementation
of
this
registry
of
the
yang
registry.
N
We
have
a
git
repository
and
by
the
end
of
August,
so
this
will
be
for
in
the
Interop
will
have
a
running
CID
registry
that
you
can
go
and
you
can
you
know
you
can
request
your
seats,
and
so
we
can
we're
able
to
do
this
interrupt
interrupt
meeting
and
the
proposed
action
is
that
we
we
would
like
to
encourage
this
one
step.
Registration,
welcome
with
a
Yank
file
to
a
public
registry.
N
Actually
the
yang
file
maybe
add
some
hash
that
you
make
sure
that
this
is
the
yang
for
you're
talking
about
so
our
proposed
action
plan
of
action
is
just
slightly
modify
the
document
as
it
is
of
today,
so
that
we
don't
block
one
step
registration
which
could
be
added
in
a
second
document
in
the
future.
In
case
there
is
an
ATAR.
N
Okay,
so
if
I'm
trying
to
rephrase
to
see
how,
if
I
got
your
question
is,
if
you
have
some
given
type
of
something,
would
we
encourage
people
to
say?
Okay,
don't
reinvent
every
time
the
notion
of
mac-address
try
to
go
to
the
module
that
once
defined
it
and
then
just
inherit
from
it
and
and
reuse.
It
he's.
O
Already
done,
yeah
taking
the
fact
that
things
are
defined
mostly
multiple
times.
What
is
the
optimal
design
like,
since
these
IDs
are
not
really
allocated
there?
You
have
will
have
to
define
this
policy
if
you
want
to
do
flow
to
at
some
point,
there
will
be
some
magic
well,
which
will
go
from
the
repository
that
the
young,
catalog
and
fetch
as
IDs
and
people
will
build
some
ultimatum
for
doing
this.
That
much
is
wondering
if
we
just
let
them
pick
things
really.
O
N
Okay,
so
I
see
what
you
what
you're
saying-
and
this
is
actually
why
I
really
wanted
to
have
this
discussion
and
I
love.
Your
comment
and
I
think
that
we
should
take
it
into
account.
So
the
question
if
I
get
it
correctly,
is
okay.
You
here
you
have
a
developer
that
publishes
a
module.
Then
this
module
is
not
something
that
is
on
its
own.
It
inherits
from
other
types
that
have
already
sits
that
are
allocated
to
their
other
things.
N
So
this
young
registry,
instead
of
just
going
and
fetching
new
fresh
seats
for
things
that
are
already
half
allocated
seats,
so
this
thing
could
actually
go
to
the
sit
registry
in
the
Civil
District
and
do
some
introspection
and
can
see.
Oh
okay,
by
the
way
MAC
address
already
has
a
seat
that
has
been
allocated
so
I
think
that's
an
that's
an
excellent
question.
We
have
lots
of
seats,
so
that's
not
the
problem,
but
the
problem
is
that
we
make
sure
that
we
don't
redefines
like
we
don't
end
up
with
multiple
seats.
For
the
same
thing,.
N
I'm
I
I
think
that
it
is
possible
to
do
this
without
actually
the
best
practice
for
this.
So
in
theory,
it
could
be
both
could
be
done.
I
would
be
in
much
in
favor
of
what
you
are
saying
that
we
make
sure
that
it
always
the
same
set
issues.
So
if
you
are
using
a
mac
address,
it's
always
the
same
set
for
this
mac
address.
If
it
is
the
same
module.
O
Pascal,
it's
just
that
we
had
this
very,
very
cool
place
where
nothing
has
been
done
yet
to
do
this.
This
flow
that
you
represent
you
so
I
would
just
suggest
that,
instead
of
just
doing
it
blindly,
we
care
about
what
kind
of
result
want
to
achieve,
and
it's
already
a
case
that
MAC
address
is
defined
in
terms
of
of
models
and
so
depending
on
what
the
desired
effect
which
define
whether
an
S
ID.
O
L
M
The
yet
I'll
try
to
answer
that
question
said
are
assigned
to
fill
in.
Fill
in
yang
is
called
data
nodes,
so
not
to
data
type.
So
let's
say
you
have
a
data
type
that
defined
an
IP
address
and
use
for
setting
your
DNS
or
using
the
interface
the
SID
is
assigned
with
that
usage.
So
the
the
IP
address
of
it,
your
DNS
or
your
server,
your
interface
and
the
yang
defined
those
that
a
node
and
we
just
maps
it
to
each
of
them.
M
M
B
Well,
garcinia
sequence:
just
a
quick
question:
coming
back
a
little
bit
on
your
on
your
slide,
I
think
you
you
answered
it
I
just
want
to
make
sure
that
it's
clear
so
you're
not
saying
public
versus
private
you're,
saying,
let's
start
with
public,
and
then
we
go
for
the
private.
This,
like
a
toast
approach,
not
not
like
one
or
yeah.
N
It's
so
it
is
a
two-step
approach.
Let's
start
with
this
one,
because
we
it
is
already
there
and
who
know
that
it
is
not
blocking
because
in
this
trip,
so
we
got
input
from
industry
and
people
want
to
be
able
to
register
private
modules,
and
it
gives
you
the
option
to
actually
go
to
the
public
on
and
the
idea
is,
let's
maybe
add,
a
minor
thing
that
allows
introspection.
So
whenever
we
want
to
go
to
a
public
one,
then
we
we
are
not
blocked
with
it.
N
Okay,
those
and
move
on,
because
we
are
ready
now
to
do
the
implementation
of
this,
and
we
have
something
that
we
did
it
manually
for
the
moment.
So
we
now
we
want
to
build
actually
the
software
that
allows
you
to
automatically
do
the
registration.
So,
let's
move
with
this
one-
and
you
know
at
some
point-
we
decide.
Okay,
do
we.
You
know
we
close
this
document
and
maybe
say:
ok
set
public
registration,
BCP
or
something,
but
that
that
should
I
think
it.
We
can
split
the
to
the
to
process.
A
Right
so
I
think
that
that's
as
far
as
we
will
get
today,
yeah
we
have
tomorrow
to
go
into
more
detail.
So
I
would
actually
cut
like
to
cut
short
the
agenda
item
right
here.
So
we
just
go
to
the
next
one
I
think
on
Friday.
We
will
get
a
quick
report.
What
happened
tomorrow,
so
we
can
react
to
that
yeah.
Okay,
do.
A
That's
the
the
ad
that
that
we
already
had
so
there
will
be
a
young
of
rings
meeting
and
those
people
who
are
interested
in
managing
constrained
nodes
may
want
to
go
them
and
the
room
is
way
too
small,
so
commonly
okay.
So
we
have
three
more
items
on
the
agenda
which
hopefully
quick
items
but
I
just.
D
A
P
Name
is
Jericho
and
here
to
talk
about
device
you
are
ends.
This
is
draft,
has
been
recovered
or
resuit
after
years
of
sort
of
being
not
being
updated
or
discussed,
and
that
the
reason
for
the
update
first
of
all,
I
I,
was
busy
doing
some
other
things,
but
now
I'm
back
in
technical
works.
So
so
that
that's
one
reason.
P
The
other
reason
is
that
there
was
actually
people
who
were
we're
saying
that
they
are
using
these
things
in
products
and
systems
in
in
large-scale
systems
and
and
that
that
might
be
a
reason
for
for
us
to
actually
complete
this
process.
There's
also
reference
from
the
Sen
ml
document
to
this
document
and
some
examples
which
of
course
could
be
exchanged
or
replace
to
something
else,
but
that's
another
sort
of
editorial
reason.
P
That
sort
of
thing
there's
there's
an
update
of
the
draft
as
I
submitted
it
and
there's
another
update
queued
up,
not
completely
done
yet
they
would
have
to
deal
with
the
new
templates,
for
you
are
in
registrations,
among
other
things.
I
also
want
to
update
the
security
considerations
section.
So
it's
it's
fine
to
put
things
like
hardware,
identifiers
in
your
your
own
database
or
equipment
inventory
and
such
will
not
spread
them
all
around
the
internet.
You
know
without
thinking
about
that,
so
that's
that's
a
consideration
to
be
added
and
I
guess.
P
F
So
Tim
carry
no
key.
I
will
say
that
you
know
we
actually
use
this
in
three
different
sto
bodies
for
for
pointing
to
device
identifier.
So
if
there's
a
mechanism
to
make
this
in
RFC
I
think
would
fully
support
that,
because
we
use
them
is
the
intention
to
expand
it
to
two
additional
identifiers.
It.
P
P
D
Hi
this
is
Hank
again,
and
this
is
not
my
trusted
computing
group
head
on.
The
trusted
computing
group
is
watching
this
stuff
carefully
in
a
positive
or
negative
positive
way,
because
there's
a
lot
of
identifiers
most
of
suddenly
the
attestation
identification
key
and
so
yeah.
We
would
like
to
see
a
specific
yeah
integration
of
that
would
be
the
TCG
basically
because
I've
maybe
should
talk
some
more
about
this,
but
we're
going
and
cause
finding
identifiers
or
identities,
and
that's
slightly
different,
no
it's
kind
of
hard
and
they
have
a
complete
semantic
or
the
subset.
D
P
G
So
because,
if
you
know
some
hardware,
devices
have
more
than
one
MAC
address.
Okay,
and
so
we
had
the
discussion
before
about
URI
aliasing,
and
so
these
are
locators,
not
identifiers,
and
so
I
still
think.
This
is
a
good
idea,
but
I
think
if
you
actually
want
to
identify
her
for
a
device,
then
you
might
be
using
something
like
the
hash
of
your
private
key
or
public
key.
P
Yeah
so
I
I
guess
the
the
use
cases
that
I've
seen
for
this
involve
not
not
necessarily
identifying
exactly
where
you
are
in
terms
of
of
the
network,
but
rather
just
registering
a
particular
Poynter
that
that
indicates
that
this
is
it's
this
entity
we
have
other.
You
are
n
types
for
hash
or
public
key
based
identification
which
can
be
used
or,
and
then
we
have
you,
you
IDs,
the
these
are
a
little
bit
more
straightforward
identifier
of
hardware
identities,
which
I
think
is
useful.
P
D
G
Idea,
locator
is
a
set
of
terms
that
many
people
and
the
IETF
used
for
things
that
are
sort
of
unique
and
stable,
whereas
locators
are
things
that
may
change
or
that
you
may
have
multiple
of
them
or
both
of
the
registry
conditions
right.
So,
if
you
have
multiple
MAC
addresses
it's
a
locator.
In
that
sense,
if
you
have
multiple
identifiers,
okay,
like
multiple
MAC
addresses,
then
you
have
multiple.
You
are
ends
and
it's
the
URI
aliasing
problem
that
we
talked
about
before.
J
J
P
Well,
it's
a
it's
impractical
thing.
We
could
have
defined
a
Mac,
you
our
ends,
but
we
wanted
to
do
device
you
were
in
and
then
under
that
have
another
layer
where
we
can
sort
of
select
and
then
we
can
perhaps
later
extend
in
various
ways
but
there's
another
question
of
like
who's
responsible
for
the
actual
identifier
space
and
and
in
this
document
at
least
for
the
two
cases
that
we
have
here
we'd
be
very
clear
that
we're
not
responsible
for
that.
It's
those
other
guys
over
at
I,
Triple
E,
for
instance,
and
and
so
forth.
P
J
P
J
C
Alexei
Melnikov,
subject
to
more
confirmation
than
there
is
interest
in
this
and
I
think
they
seem
to
be,
but
I
just
want
to
have
a
bit
more
confirmation.
I
would
be
happy
with
a
the
working
group
document
or
edge
is
sponsored
by
me.
So
thank
you,
but
it
seems
to
have
a
little
bit
of
work
needed.
A
Okay,
so,
given
that
I'm
looking
to
ask
the
question
whether
the
working
was
ready
to
adopt
that
right
now,
but
I
sensed,
there
is
interest
in
the
room
and
I
sense.
It
measures
very
well
with
with
the
other
things
that
we're
doing
so
I
would
expect
us
to
pick
that
up
and
not
push
it
away
to
over
to
somewhere
else.
Thank
you.
Yes,.
Q
Q
This
document
has
a
history
of
being
published,
separate
documents.
There
has
been
John
and
gurans
co-op,
actuators
document
that
describes
some
attacks
and
an
option
that
mitigates
them.
Q
I've
submitted
a
co
requests,
tag
with
which
describes
another
set
of
attacks
and
the
solution
to
them
and
what
we've
been
doing
in
the
last
editing
stage
of
this
is
pivoting
this
to
have
a
problem
statements
document
which
is
not
updated
yet,
and
a
joint
utility
options
document
that
will
help
mitigate
those
attacks
of
the
first
issue
is
freshness
both
DTLS
and
oscar
up
provide
only
relative
freshness
in
the
sense
that
you
know
that
a
request
is
earlier
or
later,
but
you
don't
know
that
this
is
still
current
and
the
typical
example
is
unlocking
some
kind
of
lock
the
attacker
swallows.
Q
That
package
we
and
retransmissions
the
user
goes
away
and
the
attacker
later
replaced
that
package,
which
hasn't
been
seen
by
the
server.
So
it's
kind
of
fresh.
The
proposed
solution
is
to
have
an
option.
Q
However,
we
will
call
it
right
now-
it's
called
repeat,
but
we
are
open
for
that
says:
I'm
client,
your
request
was
noted,
but
I
won't
act
on
it
unless
you
say
I
am
the
client
and
I'm
now
ready
to
I'm
still
ready
to
do
this,
which
is
expressed
in
a
short
nonce
that
the
server
generates
at
random
and
when
the
client
can
repeat
that
the
server
will
know
that
the
client
has
between
the
first
and
the
second
submission
at
some
point
in
time
being
interested
in
changing
this.
Q
Q
Q
So
you
can
fetch
a
particular
block
and
just
get
that
back,
but
in
the
context
of
having
a
pail
of
having
a
body
that
is
sent
with
the
request,
this
means
that
the
server
can
never
be
sure
whether
those
blocks
are
actually
linked
together
and
I
will,
in
the
next
slide,
explain
a
slightly
convoluted,
but
example
of
of
how
this
can
be
used
in
an
attack.
This
is
a
situation
that
usually
won't
occur
naturally,
so
it
only
comes
up
in
security
context.
Q
The
solution
we're
proposing
is
to
have
a
tag
in
the
in
the
shape
similar
to
the
attack
that
is
generated
by
the
client
that
can
be
reduced
under
some
conditions
that
are
defined
in
the
document.
So
the
overhead
can
be
kept
low
because
the
tags
don't
have
to
become
large,
they
can
actually
stay
absent,
and
if
that
option
is
applied
correctly,
the
client,
the
server
can
be
sure
that
the
complete
and
body
it
has
assembled
from
several
block
requests
is
actually
a
body
that
the
client
intends
the
server
to
process.
Q
And
again
this
has
some
different
uses
as
well
in
when
it
is
implemented
in
proxies,
they
can
process
different
clients,
requests
to
the
same
resource
more
easily
without
having
to
complete
one.
Before
finishing
the
other
I
presented
or
actually
Gurgaon
has
presented
the
neotec
this.
That
outlines
the
situation
before.
Q
If
you
have
an
affirm,
say
a
firmware
update,
consisting
of
only
two
payload
blocks
and
the
first
of
the
first
upload
is
taken
by
a
stored
by
an
attacker
and
suppressed
a
later
update
could
have
that
block
injected
and
then
look
like
the
server
will
receive
request
body
that
has
all
its
parts
correctly
signed
by
the
or
correctly
I'm
macked
by
the
client.
It
still
would
assemble
something
that
will
fail
to
perform,
will
corrupt
the
device
whatsoever
and
the
request
tag
option
is
a
way
of
dealing
with
that.
Q
So
there
are
two
of
two
questions.
I
would
like
to
ask
them
two
more
that,
while
the
classic
questions
one
is,
this
describes
how
the
server
reassemble
resembles
the
packages
other
the
request
box,
and
it
may
be
a
good
idea
to
have
this
update
the
block
wise
document,
so
that
all
servers
need
to
process
that
otherwise
the
client
will
just
see
that
the
server
has
a
an
option.
It
can't
process
and
will
be
unable
to
do
that
secure
operation.
Q
The
other
question
is:
are
there
any
even
more
lightweight
alternatives
we
didn't
miss?
One
option
would
be
to
have
to
integrate
with
sequence
numbers
more
more
deeply.
The
tricky
part
about
that
is
to
be
sure
that
random
access
to
resources
still
works
when
the
server
supports
it
yeah.
The
remaining
questions
are
who
has
read
the
document
who
has
feedback
for
us
on
this,
and
how
can
we
proceed
with
that.
A
A
Okay,
this,
this
is
a
little
weak,
but
we
will
confirm
anon
the
willingness
anyway,
so
I
asked
it
anyway.
So
the
of
the
people
who
know
something
about
this
document
things.
This
is
the
solution.
Excuse
me,
this
is
the
basis
for
the
solution
that
the
working
group
should
work
on
to
solve
these
problems
skip
the
question:
should
we
solve
this
problems.
A
R
R
Just
to
give
some
quick
background.
We
went
through
that
any
other
times.
Of
course,
scope
is
used
at
the
application
level
to
provide
Anthon
security
between
a
cop,
client
and
server
referring
to
security
context,
some
bit
common,
the
other
party
center
and
recipients
plate.
It
was
banned
between
request
and
response
and
selective
protections
of
parts
of
the
code
messages.
So
this
draft
is
about
adapting
or
sought
to
be
used
in
integral
communication
context.
R
When
you
have
a
number
of
nodes
acting
as
multicast
Urso,
sending
my
multicast
IP
requests
to
the
listener
in
the
groups
that
can
in
turn,
reply
back
with
unicast
responses.
There's
a
game
binding
between
requests
and
responses.
Same
security
assurances,
including
source
authentication
mandated
in
the
draft
body
and
force
through
a
symmetric
signature.
And,
as
you
can
see
in
this
example
at
least
a
node
has,
in
general,
a
common
context
of
sender.
Context
to
protect
outgoing
messages,
doesn't
matter
if
they're
requests
or
responses
and
then
a
recipient
context.
R
R
Same
security,
requirements
of
Oscorp
fulfilled
as
I
say,
especially
source
identification
through
a
symmetric
signatures,
and
we
go
for
source
for
counter
signatures
embedded
in
the
CAHSEE
object--
in
the
countersign
field,
and
this
is
all
based
on
an
entity
named
group
manager
responsible
for
the
group,
especially
for
the
sake
of
the
actual
joint
process
of
new
members
of
the
group
and
for
handling
revoking.
Renewing
the
key
material
in
the
group.
And
it's
up
to
the
group
manager
also
to
are
sure
uniqueness
of
endpoint
IDs.
Within
the
same
group.
It
manages.
R
The
updates
from
the
previous
version
are
quite
mainly
based
on
many
reviews.
We
go
actually
thanks,
all
the
reviewers
for
that
this
is
aligned
with
the
latest
version
of
also
coop.
Of
course,
we
have
introduced
the
new
concept
of
pure
listener,
thanks
Jim
shot
about
that
my
way,
so
it's
a
special
listener.
Now
that
doesn't
reply
back
to
a
group
request,
but
simply
receive
them,
verifies
them
and
take
some
action.
I've
asked
for
such
you
note
is
especially,
of
course,
easier
to
initialize
and
managing
case.
R
So,
of
course,
we
we
revised
the
security
requirements
and
the
security
context,
especially
in
the
presence
of
this
new
kind
of
node,
some
additional
considerations.
What
detail
I
will
say
on
the
contest
ID,
and
we
indicated
as
monitoring
to
implement
EDT
255
19,
as
the
signature
algorithm
to
consider.
R
We
also
extend
it
called
what
the
security
considerations,
especially
for
the
sake
of
synchronization,
with
sequence
numbers
in
the
group,
and
that
applies
for
note
that
have
just
joined
the
group
or
for
note
that,
for
any
other
reason
can
los
lose
synchronization
with
sequence
numbers,
for
instance,
in
case
of
reboot
or
any
other
reason,
and
we
also
revised
with
the
mechanism
for
public
key
provisioning
denotes
that
join
the
group
for
a
synchronization
issue.
By
the
way
we
are
referring
of.
H
R
We
have
also,
finally,
a
first
proof
of
concept,
implementation
up
and
running
in
Contiki
tested
in
two
platforms
with
mote
and
smart
RF,
it's
available
on
github
and
as
related
next
steps.
We
want
to
keep
this
especially
harmonized
in
details
with
list
a
little
squab,
especially
as
the
compress
caused
the
object
check,
alternative
ways
to
computational
signatures
in
Hardware,
listen
to
smart
RF
platform
that
allows
that
as
an
alternative
to
software
computing
or
digital
signatures
and
started
to
use
some
preliminary
numbers
out
of
experimental
evaluation.
R
The
problem
is
covered
in
Appendix
A
of
this
draft
following
a
discussion
started
at
AI
ITF
97
its
about
the
specific
problem
of
joining
the
group,
essentially
interacting
in
a
secure
way
with
the
group
manager.
So
it's
briefly
discussed
in
appendix
here,
but
we
have
a
proper
draft
in
ace
describing
how
the
group
can
be
joined,
interacting
through
the
group
manager
having
in
a
nutshell,
the
joining
node,
acting
as
the
ACE
client
in
the
group
manager
as
the
resource
server
and
the
detail.
R
The
Vita's,
especially
as
to
the
secure
communication
with
the
group
manager,
are
actually
up
to
a
specific
age
profile
you
decide
to
use
for
that,
so
to
wrap
up
again.
This
is
the
result
version
two
already
of
many
comments.
We
we
got
and
integrated
from
many
reviewers,
especially
Jim
shouting
close
Hartke
among
others.
That's
against
again.
A
summary
of
updates.
I
gave
you
in
the
previous
slides.
We
have
a
first
proof
of
concept.
H
G
Have
one
follow-up
question
you,
but
you
talked
about
the
addition
of
the
pure
listener,
so
in
the
73
90
or
whatever
it
is.
Is
the
group
communication
for
coop
that
one
only
uses
the
ASM
model
now
that
you
have
the
concept
of
pure
listener,
I
wonder
if
this
is
also
now
potentially
applicable
even
to
the
SSM
model,
where
you
have
everybody
as
a
pure
listener,
except
for
one
knows,
my
question
is:
is
it
actually
potentially
applicable,
more
generally
applicable
even
than
73
90.
G
Certainly,
there
are
use
cases
in
IOT
for
things
that
you
have
one
privilege.
You
know
Beamer
of
information
and
a
bunch
of
subscribers
that
are
unprivileged
or
whatever
that's
an
interesting
IOT
use
case,
for
you
know,
advertise
our
market
in
caps
or
whatever
it
is
right,
and
so,
if
so,
you
know
even
better
yes,
so
thank.