►
From YouTube: IETF100-T2TRG-20171114-1550
Description
T2TRG meeting session at IETF100
2017/11/14 1550
https://datatracker.ietf.org/meeting/100/proceedings/
A
And
not,
we
will
be
using
the
ether
pad
for
that
collaborative
note-taking.
But
I
just
noticed
that
in
the
agenda
page
the
link
is
broken.
It
has
a
IETF
in
the
URL.
It
should
I
RTF,
but
I
sent
the
correct
linked
on
the
tingling
research
group
mailing
list
earlier
today.
So
you
can
find
it
in
the
in
the
emails,
the
etherpad
link
or
if
you
click
the
link
on
the
agenda,
but
just
change:
ie
tf2,
I
RTF
and
it's
fine
babe.
A
B
So
welcome
Thank
You
thing
reso
troop
recurring,
and
this
is
an
IETF
meeting,
so
the
the
IPR
guidelines
of
the
IP
ETF
apply.
You
can
find
more
about
them
and
I
RTF
dog
/
IP
on
who
sheets
are
going
around.
We
have
no
takers,
I
believe
a
few
pointers.
Here
we
have
a
mailing
list
and
in
particular
we
have
a
repository
that
will
collect
all
the
information
for
the
meeting
today.
B
So
on
the
agenda,
we
have
a
quick
introduction
and
and
research
room,
setters
short
reports
from
three
meetings
we
have
had
and
then
we
will
go
into
three
topics
that
will
be
described
by
four
talks
and
actually
the
we
are
not
probably
not
doing
any
big
wrap-up
in
the
end.
So
we
will
just
do
the
meeting
planning
part
upfront
so
to
remind
everyone
what
the
thing
to
think
research
group
is
again.
It's
a
research
group,
not
a
working
group
and
we
look
at
research
issues
interning
or
through
Internet
of
Things
into
reality.
B
So
Internet
of
Things
for
us
means
an
Internet
where
low
resource
nodes
can
communicate
among
themselves
and
with
the
wider
Internet
and
we've
within
this
really
big
subject.
We
look
at
issues
that
have
opportunities
for
IETF
standardization
and
we
do
this
full
stack.
So
we
are
not
bound
to
any
specific
IETF
area.
We
start
at
the
IP
allocation
layer
and
we
end
at
human
rights.
B
So,
looking
at
the
what
the
relative,
what
the
research
group
has
been
doing,
we
have
a
pretty
packed
meeting
schedule,
so
we
try
to
juggle
and
and
keep
a
few
balls
in
the
air,
and
one
of
this
is
the
Vichy
activity
where
we
look
at
semantic
interoperability.
There
are
about
10
Senate
development
organizations
that
do
work
in
the
area
of
defining
semantic
tags
for
things
that
happen
in
the
Internet
of
Things.
So
what
is
the
dialog?
What
is
the
temperature
sensor
and
what
does
the
temperature
that
comes
from?
B
B
We
have
one
interesting
opportunity
for
presenting
new
work
in
the
area
of
IOT
security.
We
have
a
workshop
at
end.
Ess,
the
the
submission
deadline
is
December
1st,
so
you
may
want
to
look
at
the
Alpha
papers
that
is
linked
on
the
agenda.
The
subject
is
decentralized,
IT
security
and
IC
IOT
security
standard
and
in
2018
we
plan
to
use
the
IETF
as
Unity's
to
get
things
done.
So
we
probably
are
going
to
use
the
hackathon
format
even
more,
and
we
are
also
looking
at
joining
hackathons
of
other
organizations.
B
B
So
this
is
now
really
getting
ready
to
publish,
and
if
you
haven't,
there's
no
link
here,
we
should
have
put
a
link
there.
If
you're
interested
in
security
that
sort
of
human,
you
may
want
to
look
at
and
maybe
provide
some
feedback
for.
We
also
recently
adopted
another
document,
restful
design
for
IOT,
and
this
document
collects
a
view
on
how
rest
the
rest
paradigm
can
be
used
in
the
Internet
of
Things,
and
this
recently
got
new
text
on
hyper
media
driven
applications
on
system
design
in
hyper
media
controls
and,
more
generally,
on
design
patterns.
B
B
So
these
are
two
documents
we're
not
going
to
discuss
today,
but
where
we
thought
it
would
be
good
to
provide
pointers
to
now.
I
would
like
to
quickly
report.
From
today.
Meeting
we
had
in
Berlin
in
conjunction
with
the
riot
summit
riot,
is
an
operating
system
for
the
Internet
of
Things.
That
has
a
lot
of
developers
out
there.
B
B
This
meeting
had
a
lot
of
topics.
I
cannot
really
do
justice
to
it
and
a
couple
of
minutes
but
I
want
to
provide
three
highlights.
One
is
we
had
not
planned
that,
but
for
some
reason
we
we
broke
into
a
discussion.
What
is
the
Internet
of
Things?
This
is
what
came
out
of
that,
and
maybe
we
can
take
that
as
a
draft
working
definition
for
our
own
use,
so
the
Internet
of
Things
is
obviously
composed
of
things
and
an
Internet
of
thing
thing
is
a
node
on
the
internet.
B
That
also
has
a
foot
in
the
physical
world.
So
if
it's
just
a
router
or
a
cloud
service
or
something
like
that,
it's
not
really
an
Internet
of
Things
device,
but
the
interesting
part
about
it
enough
things
device
is
they
they
have
a
physical
presence.
They
do
something
in
the
physical
world,
their
sense
they
actuate
and
often
with
a
narrow
purpose,
and
why
this
says
not
just
for
talking
to
humans
just
so,
we
don't
have
to
include
smartphones
or
similar
devices
as
IO
devices.
B
Of
course,
there
are
IOT
devices
that
are
being
operated
by
humans,
so
a
light
switch
of
course,
always
talks
to
a
human,
that's
its
purpose.
So
we're
not
excluding
that.
But
the
point
is
the
light.
Switch
is
situated
in
a
certain
physical
location,
and
that
makes
it
an
IOT
device.
So
the
physical
relationship,
that's
one
interesting
property
of
the
IOT.
B
B
We
already
had
a
short
segment
on
coexistence
in
the
Chicago
research
group
meeting,
where
we
had
a
number
of
ad
hoc
breakouts
to
to
certain
topics,
and
the
situation
right
now
is
that
all
of
us
that
are
designing
the
Internet
of
Things,
as
we
would
be
designing
a
car
that
has
the
road
all
for
itself
and,
of
course
that
doesn't
work
at
some
point.
You
need
direction
indicators
and
and
other
items
that
that
cars
for
themselves
certainly
don't
need,
but
they
need
it
in
a
situation
where
other
cars
are
they're
all
true.
B
So
we
are
trying
to
understand
what
are
the
the
interesting
properties
are
for
more
crowded
landscape.
Obviously,
spectrum
is
one
point
that
immediately
comes
to
mind,
but
there
are
also
other
aspects,
and
how
can
we
avoid
one
I?
Would
you
network
taking
out
the
next
IOT
network
by
using
the
network
or
the
spectrum
or
other
shared
resources
in
in
bed
ways,
and
can
we
establish
some
collaborative
usage
of
certain
shared
resources,
for
instance,
spectrum
management?
B
The
IETF
already
has
had
a
working
group
on
spectrum
management
in
the
right
space,
the
TV
white
space
world
and
the
the
discussion
is
heating
up
on
how
we
are
going
to
manage
new
bands
that
are
coming
up.
There
will
not
just
be
unlicensed
unmanaged
bands,
but
that
will
have
some
some
structure
and
finally,
I
would
like
to
point
to
a
draft
draft
Feeney
cheated
here,
G
inter
network.
This
collects
some
interesting
experiences
with
running
current
IOT
mags
in
the
vicinity
of
each
other.
B
There
are
some
surprising
results
there,
so
have
a
look
at
those
we
had
about
ten
other
topics,
so
I'm
not
going
through
all
of
them,
but
security,
of
course,
is
an
important
point,
but
there
are
also
issues
around
api's.
For
instance,
how
do
good
API
is
for
constraint?
Fermentations
look
like
how
are
we
going
to
crypto
in
this
space?
We
will
talk
about
crypto
and
in
a
short
while,
but
about
symmetric
crypto.
This
segment
in
Berlin
was
about
asymmetric
crypto
and
also
some
some
implementation
aspects
like.
How
do
you
actually
talk
to
a
development
system?
B
A
Okay
and
I'll
give
you
a
quick
update
on
the
OCF
Tingting
Archie
meeting
that
happened
on
the
Friday
before
the
ietf,
so
also
there
we
had
a
very
packed
agenda.
It's
roughly
16
different
topics
on
in
160
minutes,
so
these
are
the
key
items
that
we
had
on
the
agenda,
starting
with
the
use
of
status
updates,
what's
happening
in
ocf,
what's
happening
at
the
IETF
and
I
RTF
and
re,
making
sure
that
we
are
aligned
on
process
wise
and
specification.
A
Wise
and
I
see
the
same
direction
there
in
particular
we're
discussing
security
topics
or
score
the
object.
Security
work
done
in
the
core
working
group
also
marked
the
manufacturer
user
descriptions
and
and
how
the
ACE
framework
could
be
used
together
with
the
OCF.
Another
topic
area
was
the
restful
interaction,
so
ocf
is
heavily
using
links
and
collections
and
how
those
can
be
interacting
in
proper
restful
way
and
in
particle.
One
topic
was
these
atomic
measurements.
How
does
it
should
be
handled?
A
There
is
a
whole
topic
area,
ubiquitous
connectivity
and
discovery,
in
particular
how
mesh
networks
and
core
resource
directory
can
be
used
together.
How
you
can
span
across
multiple
segments
of
mesh
networks
and
still
be
able
to
use
the
kind
of
infrastructure
that
we're
building
here
at
the
IETF
also
discussed
quite
a
bit
on
the
cloud
aspects?
What
is
the
idea
uncle?
What
is
the
OSI
if
you
on
cloud
and
how
those
things
can
work
together
and
then
finally,
natural?
A
So
if
you
are
behind
on
that,
and
also
the
other
end
points
behind
that,
how
can
you
still
get
a
connectivity
in
between
and
then
there's
a
whole
bunch
of
our
dependent
IETF
work?
So
ocf
is
using
heavily
IETF
specifications,
for
example,
called
TCP
and
also
to
Bob
sub
broker,
so
those
were
discussed
how
we
can
best
progress
them,
and
in
that
context
we
were
also
discussing
the
yunkish
work
that
was
just
presented
also
in
this
IETF
and
finally,
the
protocol
negotiation
work
that
is
going
on
the
core
group.
So
how
can
you?
A
How
can
you
use
different
kind
of
protocols
under
the
co-op
protocol
and
then
ocf
has
their
data
model
repository
one
iota,
and
it
will
be
very
good
to
get
IETF
reviews
for
those
models.
So
we
discussed
how
we
can
have
a
pipeline
and
and
notifications
for
new
models
happening
in
that
area,
so
we
got
a
whole
bunch
of
action
items
there.
So
these
are
the
items
iedf
and
and
also
yet
we'll
be
working
together.
So
first
of
all,
as
customers
will
be,
having
monthly
calls
roughly
one
topic
per
call,
those
those
will
be
announced.
A
A
Okay,
this
microphone
seems
to
be
going
on
and
off
so
yeah.
Let
me
know
if
you
don't,
he
can't
hear
in
the
back,
but
then
we
should
do
something
about
this,
then
also
design
patterns
for
cloud
rendezvous
so
usually
use
cloud
for
finding
different
devices
and
and
what
is
the
their
different
ways
of
doing
that
and
what
are
the
design
patterns?
A
How
TCP
and
and
turns
would
work
together
and
then,
as
I
mentioned,
a
one-nighter
model
review,
so
have
some
notification
system
that
when
there's
the
new
models
that
we
could
be
reviewing,
have
those
who
are
interested
in
reviewing
them
easy
access
to
them
and
easy
notifications,
then,
on
particle
topics
for
the
monthly
code,
so
deep
dive
on
how
to
use
ace.
So
a
taste
was
discussed
in
at
the
meeting.
A
But
since
we
had
only
very
limited
time,
we
agreed
okay,
we
need
to
have
a
closer
look
at
this
and
and
go
down
to
the
details,
then
how
you
modify,
link
collection
so,
as
I
mentioned,
ocf
is
using
links
and
collections.
A
lot
and
up,
for
example,
is
their
patch
format
of
different
formats
needed
to
be
able
to
interact
with
a
link
collection
seen
in
a
restful
way.
A
Also,
one
topic
was
this
privacy
and
security
related,
so
in
in
or
score
you
are
exposing
some
of
the
headers
for
middle
boxes.
So,
if
you
want
to
prevent
things
like
traffic
analyzes,
you
maybe
want
to
accent
on
all
your
object
security
and
what
is
the
best
ways
of
doing
that
were
the
right
design
patterns
and
an
alignment.
A
Then
this
whole
one
topic
of
atomic
measurement
or
an
atomic
resources
and
how
you
can
perhaps
forbidden
by
definition
or
policy
access
to
certain
parts
of
a
resource
have
them
only
as
a
as
a
big
as
a
bigger
patch,
and
also
how,
for
example,
Quran
HSM
could
be
used
for
this,
how
you
bundle
our
set
of
resources
together.
So
we
didn't
have
conclusions
yet
on
this,
but
we'll
be
working
on
on
the
topic
to
figure
out
the
right
ways
and
and
guidelines
for
that,
and
one
also
particle
to
be
that
pop
up.
A
Then
the
other
meeting,
what
we
had
on
the
weekend
was
the
wiki
hackathon.
So
we
had
a
two-hour
session
on
Sunday
there.
The
topics
that
we
were
discussing
is
in
particle
IOT
schema
or
keep
so
smart
object
and
all
CF
models.
How
can
those
work
together,
how
again
in
real
enriched
with
semantics
these
models
that
we
can
make
translation
and
interworking
of
different
models
models
easier?
We
did
identify
a
set
of
relevant
resource
experience
that
the
QUT
ontology
salsa
SSN.
That
will
be
having
a
closer
look
on
this
activity.
A
Also,
we
did
discuss
that
there
are
a
lot
of
ontology
is
out
there,
but
do
we
need
something
more
to
glue
those
together?
Is
that
a
clue
on
the
lachchi
or
or
some
other
mechanism
bearers
it?
For
example,
the
Doubletree
see
web
of
things
think
this
description
work.
What
kind
of
roles
would
that
have
be
there
to
be
the
glue
in
between
different
kind
of
systems?
A
A
C
C
A
C
B
C
A
E
D
A
A
F
G
Afternoon,
for
those
who
don't
know
me,
I'm
Bob
Moskowitz
I've
been
around
here
for
a
while
one
of
the
original,
not
quite
original,
but
one,
the
graveyards
here
and
I'm,
going
to
be
talking
about
using
cat
check
for
small
cryptography
to
advance
security
and
small
things.
One
thing
I've
noticed
since
core
was
just
a
bought,
was
a
number
of
vendors
who
have
left
this
room.
Vendors,
whose
tutu's
devices
and
technology
were
too
small
to
do
what
this
IETF
has
been
talking
about.
They've
got
up
and
they
have
left.
G
B
B
G
So
what
is
ketchup
and
there's
any
belgium
hero
can
fix
my
pronunciation
and
even
though
I've
spoken
with
Johanna
Damon
a
couple
times
on
the
phone,
my
pronunciation
does
drift
a
little
bit
so
ketchikan,
totally
new
approach
to
symmetric
cryptography.
It's
called
a
sponge
function
is
a
total
break
from
how
we've
traditionally
have
done
symmetric
cryptography.
The
traditional
addition
rotation
XOR
that
we're
doing
since
since
when
since
Caesar
cipher,
so
it's
a
total
break
and
in
fact
it
is
such
a
monumental
break
that
all
the
compromise.
G
All
the
current
research
is
built
around
spun
function,
research.
This
is
really
important
change
in
cryptography
and
you
can
learn
more
about
it.
By
going
to
the
catch
excite
cat
check,
dot,
team,
I'm
gonna
be
referencing
a
number
of
things
from
that
site
as
I
proceed.
Importantly
ketchikan,
its
maximum
strength,
B
equals
1600.
Now,
if
we
define,
are
we
talking
later
what
the
variable
B
is
about?
What's
selected
for
sha-3,
this
is
what
sha-3
is
v
202
and
special
pub
800
185
is
cat
check
with
B
equals
1600.
G
At
this
strength,
ketchup
is
well
optimized
for
32-bit
and
64-bit
processors
for
multi-core
CPUs.
For
large
messages,
hash
tree
evaluation
of
messages,
some
really
need
high
performance
things,
which
is
why
ketchup
was
selected
for
sha-3.
It's
also
the
basis
of
the
kg
cipher
in
the
Caesar
crypto
competition,
the
Caesar
crypto
competition
is
looking
at
the
next
generation.
G
Authenticated,
cipher
and
and
kenji
is
one
of
the
participants
in
in
the
pretty
much
the
final
efforts
in
the
Caesar
cipher.
Now
we're
talking
about
can
see
as
I
go
along
as
well.
So
this
is
what
caching
very
generally
and
if
you
will
and
will
be
talk,
going
more
diving
now
into
this,
so
the
obligatory
picture.
G
What
is
a
sponge?
A
sponge
has
an
absorbing
and
a
squeezing
portion
to
it
and
that's
why
they
call
it
a
sponge.
There
is
an
hour
and
a
see
here
and
we'll
be
talking
about
R
and
C
is
and
notice
how
they're
joined
together
in
this
picture.
That's
an
important
one.
The
later
slides
discussions,
your
message
comes
in
to
the
pad.
It
goes
to
the
function
and
and
and
it's
absorbed
and
then
squeezed
and
out
comes
E,
and
this
picture
is
taken
from
the
URL
PDF.
G
You
see
here
which
goes
into
really
explaining
what
kg
is
about.
Caching
is
about
so
you
can
go
there
and
get
more
details.
This
is
one
of
my
two
obligatory
pictures
to
show
you
that
this
looks
really
a
lot
different
than
any
pictures,
you've
seen
for
AES
or
Shaw
or
anything
else.
It
is
really
presented
differently.
The
theory
and
the
math
behind
it
is
different
than
we've
dealt
with
before.
B
G
Of
the
most
important
aspects
of
kg
to
me
is
it's
a
complete
symmetric,
crypto,
graphic
solution.
It
supplies
the
cryptographic
hash,
it
supplies
the
keyed
hash.
It
supplies
your
pseudo-random
function.
Ana
supplies
your
authenticated,
cipher,
all
four
major
things.
We
need
for
our
symmetric
cryptography,
so
in
a
single
primitive
to
implement.
It
replaces
AES
H
Mac
sha
to
go
on
down
the
list.
One
hardware
component,
instead
of
multiple
components
you
may
have
to
put
in
a
hardware
to
improve
your
performance.
G
So
it
is
one
underlying
primitive
to
give
everything.
This
is
important
in
terms
of
code
size.
G
Now,
let's
get
a
little
bit
into
catch
ik,
it's
highly
parameterised
and
it
comes
in
all
sizes.
So
B
is
the
width
and
B
comes
in
sizes
from
25
times
2
to
the
N.
So
you
can
see
25,
50
and
so
forth
to
1600,
where
the
25
and
50
are
toy
sizes
that
you
can
sit
down
with
a
piece
of
paper
and
pencil
and
come
to
an
understanding
how
Quecha
quirks
it's
really
gets.
109
up
that
you
start
getting
to
some
meaningful
crypto
ketchup
defines
a
bit
rate
are
rather
than
a
block
size.
G
You
know
crank,
try
to
explain
this
without
getting
to
depth
and
what
we
have
is
we
have
three
variables
are
B
and
C
I
just
before
so,
B
is
the
width,
and
so
what
is
our
and
C?
C
is
the
capacity
where,
if
you
want
a
strength
of
n
bits,
the
capacity
is
2
times
n.
Remember
that
picture
before
we
had
our
and
seed
together,
which
shows
them
that's
be
added
together.
So
if
our
equals
B
minus
C,
then
B
equals
our
plus
C.
G
Thus,
if
I
take
B
equals
400-
and
this
is
really
important-
I
can
deliver
128
bits
of
proven
strength
with
C
equal
to
56,
and
this
R
equals
144,
and
what
this
basically
means
is
we're
operating
144
bits
at
a
time.
That's
what
the
bit
rate
means
it's
kind
of
like
a
block,
but
it's
not
a
byte
block.
It's
a
bit
block,
and
this
is
really
good
for
small
messages,
kind
of
multiple
grounds
for
for
a
big
message.
But
it's
more
that's!
It's
really
nice
for
small
messages
to
have
a
small
R
value.
G
The
cat.
Another
important
parameter
is
the
number
of
rounds
in
catching
catch.
It
defines
24
rounds,
there's
currently
published
attack
against
routes
because
it's
parameterization.
If
the
attacks
start
getting
better,
you
can
increase
your
number
of
rounds
with
the
according
performance
hit
to
increase
the
significant
increases
strength
of
ketchup,
so
it
is
future-proof.
Consider
future
proof
against
unknown
attacks
by
the
fact
that
the
rounds
itself
is
one
of
the
many
parameters
in
ketchup.
G
G
So
again,
cat
check
with
beat
with
the
block
size
of
400
is
very
well
tuned
for
truly
constrained
IOT,
as
I
said,
R
equals
144
well
suited
for
small
messages,
you're
processing,
144
bits
at
a
time.
Your
messages
are
small.
You
have
very
little
padding
to
do
to
get
them
to
work
into
that
block
size
and
in
terms
of
how
you
had
to
feed
things
into
the
sponge,
etc.
In
most
cases,
120
bits
drink
is
more
than
adequate.
I
know
people
are
saying:
well
what
does
quantum
computing
going
to
do
and
what
is
mr.
G
rector
recommending
for
2030
and
some
of
the
rest
of
this?
We
can
get
into
all
sorts
of
fun
discussions
in
terms
of
crypto
strength.
We
can
also
talk
about
how
much
electricity
it
takes
to
break
a
single
key
by
brute
strength,
and
so
right
now,
I'm
feel
quite
comfortable,
say.
125Th
strength
is
more
than
enough
shake
128
shake
is
defining
pips
202,
so
shake
128
is
kind
of
thing
derived
from
it
is.
If
you
basis
on
B
equals
400
in
in
202,
it's
B
equals
16
average.
G
We
said
we're
dakota
for
it
for
400
it
it's
just
like
sha-2,
but
a
magnitude
faster,
there's,
a
magnitude
faster
than
running
sha-256
on
straight
forward
considerations
and
I've,
seen
numbers
even
better
than
that,
and
some
of
this
some
of
the
discussion
kmac,
which
is
the
keyed
Mac
version.
Also
in
I
think
that's
in
special
problem:
885
I'll
performs
H
Mac
with
smaller
code
size.
It's
a
single
pass
instead
of
a
dual
pass
and
it's
using
shake
128
instead
of
sha
256,
you
can
do
the
math.
G
It
comes
out
much
much
faster
than
doing
than
what
you
do
for
H
Mac
today
and
finally,
kg
senior
hour
performs
a
sec
M
again
of
in
at
least
a
magnitude
better
performance,
and
it
is
a
four
byte
block
and
it
produces
an
8
byte
tag
again
very
well
suited
for
a
small
message.
Yes,
you
can
have
larger
blocks
in
your
in
your
output,
but
it's
working
on
a
four
byte
block.
Orientation
kg
has
a
whole
class
of
sizes
from
kg
jr.
G
G
You
have
what's
called
the
duplex
construct,
I'm
construction,
which
is
how
we
can
now
take
this
hash
and
turn
it
into
a
romaso,
a
stream
cipher
that
we
can
now
take
in
a
block
and
put
out
a
crypto
block
and
proceed
along
so
and
actually
it's
reversible.
The
the
the
duplex
construction
goes
in
both
ways.
Not
only
is
it
one
direction
for
our
cipher,
it's
the
other
direction
for
our
for
our
perf.
So
again,
it's
almost
like
one
block
of
code.
Doing
the
two
different
things.
G
G
So
my
next
step
is
to
vance
this
draft
and
now
then
to
specify
catchy
with
catch
a
quit
because
400
in
it
for
IPSec
hip
TLS.
The
see
more
concise
identity,
work
that
we
have
coming
along
and
then
develop
the
into
the
IOT
devices.
One
thing
I'll
say
here
also
that
I
didn't
mention
is
that
if
you've
looked
at
movement
on
asymmetric
cryptography
and
if
you
looked
at
8080
DSA
and
you
get
into
looking
at
the
EDD,
SARC
and
8255
19
specifies
saw
512
so
kind.
G
Well,
that's
kind
of
hurts
for
doing
that
in
small
devices
and
historically
was
because
that
it
should
probably
shake
128
except
that
80
to
519,
when
it
was
done
prior
to
the
publication
of
pips
OH,
whereas
84
88
was
worked
out
after
that.
So
it
does
specify
shake
250
wonder
why
that
our
seats
got
the
two
different
things.
It's
a
bit
of
history.
So
one
of
the
things
that
I'm
also
gonna
be
doing
is
working
on
an
addendum
to
IDI
DSA,
to
you
shake
128
and
to
allow
to
using
shake
128
with
B
equals
400.
G
So
we'll
have
a
digital
certificate
well
as
well-tuned
as
possible
for
highly
constrained
devices
that
the
hash
will
use
is
one
which
runs
very
efficiently
in
these
small
devices,
along
with
the
the
ec2
55:19.
So
these
are
all
areas
where
that
is
on
my
docket
to
do
I'm
looking
for
partners
who
want
to
work
with
me
on
this
and
in
terms
of
of
standardization.
G
This
looks
to
what
the
community
wants,
that
the
community
says
that
you
know
this.
Other
stuff,
which
is
out
there
and
well
studied,
is
what
we
need
in
our
product.
This
does
listen,
but
if
nobody
comes
up
and
says,
we
really
need
something:
they're
really
busy
on
on
doing
reports
to
Congress
on
things
like
on
botnets
stuff
like
that.
G
So
if
we
want
to
get
the
resource
and
attention,
we
need
to
come
forward
with
the
documents
with
the
products
that
show
that
this
is
where
why
we
need
this
in
our
industry
and
don't
listen,
they
will
listen
to
us
so
that
does
complete.
My
slides
and
presentation
may
be
gone
a
little
bit
fast
and
maybe
not
as
deep
in
as
you
want
to,
but
then
I,
don't
consider
you
as
a
bunch
of
cryptographers
are
gonna
beat
me
up.
I
do
got
my
Kevlar
suit
on
here
and
I
I'm
ready
to
take
comments
about.
H
H
Hopefully
if
it's
really
good,
it's
useful
in
other
scenarios
as
well
for
other
types
of
devices,
so
one
thing
I
would
encourage,
is
for
CF
RG
to
have
just
to
to
state
what
how
they
see
catch
act
and,
and
then
did
model
is
in
the
idea
for
the
groups
and
take
the
information
and
the
guidance
from
CFR
G
and
then
apply
that
in
standards
tracked
documents
they
just
you
know,
form
doing
formational
stuff,
but
would
that
model
not
apply
here?
I'm.
G
Going
to
be
taking
this
EF
RG,
okay,
that's
going
to
be
happening.
I
want
to
get
a
little
bit
of
of
interest
saying
this
they're
people
who
do
want
lightweight,
faster
ciphers
and
so
that
when
I
take,
you
see
FRG
I'm,
not
just
saying
well,
here's
yet
another
cipher,
but
I
want
a
that.
I'm
saying
that
here
is
where
the
interest
lies
for
this.
G
That's
there
and
yes,
it's
we
kind
of
missed
it
with
all
the
tension
on
the
bigger
use
of
ketchup,
which
was
Shaw
three
and
miss
its
its
viability
for
this,
and
as
far
as
in
other
areas,
well
consider
the
router
vendors
I
can't
possibly
encrypt
my
IP
fixed
flow,
because
I
don't
have
the
resources
to
do
a
s
GCM
on
it
and
now
listen
here
is
a
way
that
you
can
do.
You
can't
protect
your
IP
excess
flow
and
another
sort
of
thing.
So
I
think
this
is.
C
Karimi,
what
is
your
vision?
Is
it
your
vision?
Is
centralization
or
decentralization,
because
then,
when
I
look
at
this
I'll,
look
at
the
big
data
and
big
data
is
not
the
enterprise
anymore,
and
where
are
we
going
as
far
as
catchy?
Is
it
centralization
or
decentralization?
Because
if
you
get
look
at
the
use
case
of
the
healthcare
healthcare
comes
in
as
a
patient,
I
can
direct.
Who
can
get
my
file?
You
cannot
at
any
moment.
Where
do
you
take
this
as
far
as
the
topology
and
since
centralization
or
decentralization
the.
G
Sensors
start
in
collecting
that
data,
you
have
a
heart,
a
pacemaker
which
is
sending
data
back
to
the
hospital
which
ends
up
getting
into
the
big
data,
but
for
HIPAA
compliance.
You
had
to
protect
that
pacemaker
communication
from
the
pacemaker
over
a
non
I,
potentially
not
an
IP
network
because
of
embody
requirements
all
the
way
to
the
hospital,
and
you
have
to
do
it
in
such
a
way
that
you're
not
having
to
replace
the
battery
on
the
pacemaker,
which
means
surgery
more
often
so
having
something
like
this.
G
For
that
that
end
of
it,
don't
yes,
big
data,
how
you
protect
big
data,
how
you
do
feel
protection
resident,
that's
a
whole
other
discussion.
What
I'm
focused
here
is
that
what
is
the
security
we
use
in
our
communications?
Not
in
how
we
necessarily
encrypt
the
data
at
rest?
I
understand,
but
you
used.
C
C
Now
it
is
security
comes
in
first,
that's
why
I
ask
you
you're,
looking
at
the
centralization
or
decentralization
based
on
the
Health
Care's
today,
even
in
your
US
or
Europe,
it
doesn't
go
into
one
locations
anymore.
I
can
choose
to
go
in
my
information
to
multiple
sites,
multiple
countries
and
multiple
physicians
and
nurse
practitioners
or
nurses
or
anybody
else's.
Then
it's
not
gonna
be
in
one
hospital.
If.
G
I
want
to
look
at
protecting
data
at
rest
and
using
symmetric
cipher
for
doing
it
and
having
performance,
though
I
can
pull
that
data
out
quickly
with
all
the
restaurant
process
want
to
do.
I
would
want
to
have
the
lightest
fastest
cipher
that
I
can
find
that
delivers
the
security
unless
I
have
to
do
form
of
preserving
encryption,
which
is
another
case
of
class
of
discussions
and
doing
column
base
I.
C
G
E
You
know
there
we're
talking
about
small
messages
by
default
right
on
the
radio
side,
so
I
think
that
this
work
could
be
pretty
interesting.
You
know
if
you
can
continue
pushing
it
on
and
maybe
at
some
point
come
there
and
also
present
it
so
I
think
that
that
that
could
be
a
good
place
to
also
get
some
eyeballs
on
it.
Okay,
there.
G
F
Mohit
can
we
have
the
slides
back
I
just
wanted
to
ask
where
you
compare
Mohit
M
Oh,
a
chai
tea,
so
before
this
yeah
it
outperforms,
H
Mac
with
smaller
code
size
and
the
same
for
char
two
would
be
the
factor
of
ten,
but
at
least
from
what
I
have
seen
IOT
devices
are
the
code
size
is
not
always
the
most
limiting
factor.
However.
How
does
it
compare
with
ramen
like
the
the
memory
usage
and
not
not
the
flash,
and
how
does
it
compare
in
in
time
like
execution
time,
X.
G
I've
seen
those
numbers
in
the
in
their
documentation,
everything
lower
low
across
the
board
and
and
it's
like
manures
are
gonna-
have
to
sit
down
and
we're
those
tables
and
what
I'm
gonna
pull
out
and
actually
put
into
my
draft
so
you've
just
kind
of
stepped
forward.
I
read
step
back
around
you
I'm
doing
that,
so
it
is,
it
does
take
less
power
using
simpler
operations,
a
number
a
number
of
items
on
that
from
what
I
have
seen
from
their
documents
and
you'll
help
me
understand
that
make
sure
I
pull
the
right
pieces
out.
G
B
B
I
J
I
I
K
I
Seeing
today's
dominant
data
flow
and
solutions
involve
edge
computing,
either
at
small
scale,
data
centers
or
further
towards
the
edge
so
in
this
presentation
will
cover
some
motivations
for
IOT
edge
computing,
an
overview
of
major
industry
and
research
projects
and
the
potential
areas
for
future
work.
And
our
goal
is
to
gather
input
from
the
community
and
in
particular,
to
identify
edges
that
are
relevant
to
IRT
F
into
t2.
Trg.
F
I
Thank
you,
so
the
motivations
for
IOT
edge
computing,
you
know
that's
basically
to
support
high
data
volume
at
the
edge
to
support
highly
time-sensitive
and
trust,
sensitive
applications
to
exploit
opportunities
for
energy
efficiency
and
cost
reduction,
and
to
adapt
through
intermittent
connectivity
and
also
somewhat
to
open
the
edge.
So
that
can
be
expressed
in
multiple
ways.
So
we
we
have
three
here
and
they
are
kind
of
interrelated.
I
You
can
open
the
edge
by
enabling
multiple
providers
to
offer
competing
edge
computing
services.
You
can
open
the
edge
by
enabling
open
and
secure
access
to
data
so
that
are
collected
at
the
edge
could
be
consumed
by
multiple
services
at
the
edge
and
also
you
can
open
the
edge
by
enabling
open
and
secure
access
to
computing
resources.
So,
for
example,
you
can
have
multi-tenancy
for
third
party
applications,
so
we
we
start
the
very
quick
server
here.
I
You
know
with
the
telecom
industry
related
initiatives,
so
IOT
is
not
the
main
or
the
only
use
cases
there,
but
it's
one
of
the
major
one.
So
we
start
with
SC
Mac
that
see.
Mag
defines
an
architecture
for
an
mobile
edge
platform
and
defined
services
provide
provided
to
mobile
mobile
edge
applications.
You
know
hosted
applications
here
we
have
the
architecture
from
Etsy
Mac,
with
an
nav
mano
based
control,
plane.
We
know
the
mobile
edge
host
and
containing
the
platform
providing
the
services
in
phase
one.
I
So
as
you
defined
some
major
interfaces
and
basic
services
in
Phase
two,
which
was
which
started
in
January
this
year,
let's
see
Mac,
you
know
basically
planned
to
become
multi
access,
multi
domain,
multi
operator
and
basically
also
more
distributed
and
more
lightweight,
so
I
mean
more
lightweight.
It's
not
going
very
far
down
is
just
having
containers
in
addition
to
VMs
but
more
distributed,
because
applications
hosted
on
the
polished
edge.
Your
hosts
will
be
able
to
talk
to
each
other
or
be
linked
to
each
other
in
some
way.
I
So
quickly.
Now
we
can
go
through
the
the
other
ones.
You
have
open
edge
computing,
which
is
offers
a
cloud-based
architecture
for
offloading
computations.
The
telecom
infra
red
computing
project
but
tip
focuses
on
use
cases
and
implementations
and
not
not
architecture,
and
then
3gpp
builds
in
some
support
for
edge
computing.
In
5g,
so
basically,
you
will
have
the
possibility
to
redirect
flows
towards
local
data
networks,
and
third-party
application
function
will
have
the
possibility
to
influence
this
in
an
indirect
way.
M
called.
I
I'm
sorry
McChord
is
basically
aims
to
integrate
these
5g
into
architecture
into
the
central
office,
and
that
includes
edge
computing
as
well
and,
basically,
to
conclude
this,
this
group,
you
have
a
research
project,
5g
coral,
which
is
a
European
research
project
which
combines
telecom
edge,
computing
and
fog.
So
here
on
this
architectural
diagram,
you
can
see
you
have
on
the
top
left.
You
have
an
NIV
manual
based
control,
plane
again
and
underneath
you
have
this
agent
for
computing
system.
I
So
this
is
basically
a
federation
of
nodes
of
computing
devices
which
can
host
apps
applications,
functions
and
services
when
different
types
of
programs-
and
these
this
Federation
is
formed
with
very
different
types
of
devices.
You
have
edge
data
center
servers
for
I,
mean
computing
devices,
co-located
with
base
stations
and
other
access
nodes
and
focusing
computing
devices
co-located
with
IOT
devices,
mobile
phones
and
so
on.
So
to
conclude,
you
know
these
projects.
They
are
typically
driven
by
the
telecom
industry,
the
integrates
with
telcos
network.
I
So
now
we
we
look
at
the
fog
model
or
the
intelligent,
IOT
gateway
model
we
have
here.
We
have
products
on
this
page,
so
you
have
gateways
from
bargeman's,
Microsoft
Amazon
and
the
edge
X
foundry,
which
is
an
open
source
project
initiated
by
Dell.
These
are
software
projects
except
a
few
like
cements
and
snowball
edge.
The
Siemens
gateway
and
the
snowball
edge
are
hardware
product,
but
basically
they
all
start
from
a
simple
model.
I
I
The
devices
on
the
other
and
the
field
gateway
is
used
in
one
of
the
deployment
scenarios
and
it
is
used
for
protocol
translation
but
or
other
types
of
computing
like
analytics
and
also
this
diagram
illustrates
the
use
of
protocols
such
as
HTTP
mqp
MQTT.
You
know
to
communicate
with
the
cloud
and
you
have
a
range
of
other
protocols
used
between
the
device
and
the
Gateway,
and
some
are
listed
here:
Amazon
green
grass
and
stubble
edge.
I
I
So
this
group,
you
have
the
open
folk
architecture
from
the
open
fog
consortium,
it
integrates
computation,
networking,
including
time
sensitive,
networking,
storage
control
and
acceleration,
and
it
is
linked
to
a
new,
a
Triple
E
working
group,
the
fog
computing
and
networking
architecture
framework.
So
it's
quite
recent,
but
I
believe
the
the
goal.
Current
goal
is
to
standardize
the
reference
architecture
from
open
fog
and
then
to
go
on
from
that
point.
I
I
So
now
we
look
at
emerging
trends,
especially
light
weight
in
network
computing,
so
we
can
start
with
products.
Several
s.
Computing
products
include
CloudFlare
worker,
which
is
a
CDN
edge
product
which
can
run
JavaScript
programs
and
Amazon
green
grass
and
snowball
edge,
so
they
exploit
statelessness
to
de
correlate
service
from
several
location
and
named
a
function.
Networking
goes
you
know
forward
by
leveraging
ICN
to
provide
a
more
granular
approach.
I
Finally,
we
have
the
flame,
which
is
another
European
research
project
which
transports
IT
over
ICN
and
basically
performs
service
routing
in
IC
n
layer
to
optimize
traffic,
especially
at
the
edge
stateless
functions
are
easier
to
dispatch
to
any
server,
and
so
these
enables
advanced
data
service
data
and
service
routing
to
be
developed
and
also
ICN.
Technology,
support,
intermittent
connectivity
and
dissemination
of
local
data
in
a
manner
less
tied
to
applications.
So
we'll
have
an
example
of
this
in
the
last
survey
slide
here.
This
is
a
rigidly
zooming
in
an
FM.
I
Nfn
enables
accessing
static
data
and
dynamic
computation
results
in
one
single
data
oriented
framework,
then
you
can
benefit
from
ICN
features.
You
know
that
authenticity,
caching
and
so
on,
and
also
you
can
enable
the
network
to
perform
various
optimizations
and
the
the
network
has
some
tools
to
do
that.
The
network,
when
an
n
FN
node
receives
a
computation
request,
the
n
FN
node
can
either
return.
Cached
result.
It
can
fetch
that
I
encode
and
sends
back
the
computation
result
and
you
it
can
also
forward.
I
So
I
don't
know
in
terms
of
time
to
have
enough
yeah.
Ok,
so
maybe
I
will
pass
over
this
one.
That's
just
basically
a
summary
of
the
various
the
the
various
characteristics
of
the
project
we
have
seen
and
we
can
move
through
the
gaps.
So
in
terms
of
our
uth
computing,
we
see
an
evolution
towards
a
more
distributed
computing
model
and
also
we
are
in
a
context
where
the
network
is
a
dynamic
and
constraint.
I
So
I
you
th
computing,
also
evolves
towards
a
more
open
model,
and
so
you
get
a
new
set
of
challenges
that
could
derive
from
this.
So
challenges
related
to
open
access
to
compute
and
storage
resources.
So
you,
for
example,
you
may
need
to
have
generic
api's
for
the
repairs
to
ask
for
resources,
meeting
specific
requirements.
Also,
you
have
potential
challenges
related
to
open
access
to
data,
to
liberate
data
from
silos.
So
again
you
could
have
some
form
of
API.
I
Finally,
I
edge
computing
also
evolves
towards
some
lower
end
devices,
that's
kind
of
related
to
mr.
computing,
as
defined
by
NIST
here,
and
that
may
require
dynamic
and
lightweight
cooperation
of
things,
edge
devices
and
compute
platform.
So
this
this
evolution
can
also
increase
the
challenge
of
QoS
at
the
edge
and
may
require
some
form
of
dynamic
network
slicing
as
well.
I
So
to
conclude,
we
have
reviewed
technologies
related
to
a
uth
computing
and
looked
at
potential
gaps.
So
now
we
are
seeking
help
from
the
community
to
gather
more
input
and
to
brainstorm
on
what
the
irt
are
should
do.
So
is
this
a
right
result
group
to
work
on
these
topics
and
what
changes
would
be
most
relevant
to
to
that
group?
L
I
L
De
cochon
so
quota
of
this,
so
this
ranarium
from
edge
computing
discussions
in
this
group
like
in
the
previous
two
meetings,
I
think,
and
so
the
general
idea
was
that
so
there
are
all
these
existing
tech
or
motivated
edge
computing
approaches
that
Salim
presented,
but
they
are
normally.
You
know
operating
away
where
you
extend
sake,
cloud
based
or
Delia
center
based
edge
computing
to
some
point
in
the
edge,
and
so
they
say
we
see
this
for
that
world.
This
worked
was
that
so
in
a
say,
thing
to
think
environment,
but
also.
L
A
thinking
environment
with
constraint,
nodes
and
a
say,
distributed,
communication
and
computation
model
you,
you
would
have
a
different
requirements,
and
so
so,
if
you
are
interested
in
discussing
this
more
so
we
booked
the
Butterworth's
breakout
room
tomorrow
at
3:30.
So
please
come
to
me
after
this.
If
you
hunt
Justin.
B
L
M
Eric
not
like
exactly
quite
useful
to
have
this
sort
of
overview,
but
one
thing
that
might
not
be
research,
but
it's
I
think
a
practical
consideration.
As
you
start
doing.
This
is
our
good
old
friend
NAT
traversal,
right
that,
once
you
want
to
enable
east-west
communication
at
the
edge,
you
don't
have
to
go
that
far
before
you'll
find
that
there's
a
nap
between
between
the
different
devices
at
the
edge
and
that
might
just
be
an
engineering
question.
M
I
mean
in
the
IDF,
we'll
probably
have
half
a
dozen
different
ways
of
doing
that
reversal,
but
but
I
think
it's
one
that
we
shouldn't
lose
track
of
and
the
bigger
picture,
no,
the
other
ones.
That
I
think
that
so
there's
this
other
proposed
research
group
with
dark
wood,
wind
energy,
you
know
basically
looking
at
how
can
they
add
to
actually
be
more
independent,
more
autonomous
from
the
rest
of
the
Internet
and
to
what
extent
can
in
the
naming
and
security
and
whatever
in
that
context
and
I.
A
So
yeah
quick
comment
on
Eric,
so
Ari
without
the
hat
on
so
a
net
rehearsal.
Certainly
we
have
that
Tina
ice
activity
or
already
on
that.
It
would
be
something
interesting
to
explore
whether
that's
the
kind
of
solution.
What
we
want.
We
want
something
else
and
how
to
resolve
this
issue
so
also
very
much
interested
in
the
whole
problem.
Space.
A
N
B
B
N
N
liang,
are
very
involved
in
industrial
internet
forums,
particularly
the
IIC
industrial
internet
consortium
and
others
as
well,
including
ECC,
and
so
our
focus
is
very
industrial
focused
and
it
goes
beyond
the
traditional
access
network
portion
of
edge
computing
and
pushes
it
a
little
bit
further
or
a
lot
further,
depending
upon
your
perspective,
to
on-premises,
particularly
in
factory
settings
directly
connected
to
factory
equipment,
whether
it
be
elevators
or
windmills
or
whatever
it
may
happen
to
be.
So
we
have
this.
We
have
this
problem
statement
that
we've
created.
So
that's
a
little
bit
of
the
background.
N
We
held
a
side
meeting
last
ITF
to
discuss
these
potential
use
cases.
We
created
a
problem
statement
and
since
the
last
ITF
and
this
F,
we
have
created
this
problem
statement
draft
and,
like
the
previous
presentation
we
did
look.
We
did
mention
other
work
going
on
in
other
forums,
because
the
edge
computing
is
kind
of
like
cloud
where
it's
it's
spawning
everywhere.
N
A
lot
of
people
are
talking
about
a
lot
of
debate
about
what
edge
computing,
the
definition
of
it
and
all
that
so
we're
not
really
getting
into
that
we're
trying
to
keep
it
focused
and
what
some
of
the
things
that
have
come
up
with
the
discussions
we
had
inside
meeting
and
that
we've
put
in
this
draft
is
things
which
was
mentioned
in
the
previous
question.
Is
that
you
know
maybe
there's
a
existing
or
a
need
for
a
new
protocol
for
east-west
communication
between
multiple,
far
edge
or
be
on
edge
computing
or
beyond
access
computing
gateways?
N
We
don't
want
to
duplicate
effort
that
may
be
happening,
for
instance
in
Etsy's
NEC
we're
a
group,
so
we
would
need
to
evaluate
whether
that's
necessary
or
not,
maybe
in
a
ton
of
us
vehicle
setting
or
maybe
virtualization
of
VMs
or
containers
from
one
edge
device
to
another
edge
device.
Configuration
and
management
lightweight
virtualization
technologies.
N
Security
is
huge
as
well.
That's
one
of
the
main
concerns
in
industrial
settings
as
on
security,
which
is
one
of
the
main
reasons
that
they
haven't,
wanted
to
open
it
up
to
the
Internet
and
here's
the
here's,
the
draft,
so
just
I,
think
well.
I
think
you
probably
get
it
at
this
point.
The
focus
of
our
draft
just
to
kind
of
visually,
depict
it
on
the
upper
part
of
this
diagram.
You
in
the
yellow
part.
N
You
have
you
know
your
core
data
center
regional
data,
center
access
network
and
again
typically
edge
computing
topics,
whether
it
be
you
know,
court
or
other
types
of
proposals
are
typically
focused
on
the
access
network
side
and
what
our
focus
is
is
again
is
more
on
the
on-premises
side
of
a
factory.
The
component
of
edge
computing
could
be
actually
placed
on
top
of
an
elevator,
for
instance,
or
directly
connected
to
a
robot
in
a
factory.
It's
that
proximity
to
the
edge.
N
Okay,
thank
you
all
right.
So
there's
a
variety
of
verticals
within
the
industrial
sector.
We
focus
on
some
of
these
use
cases.
Some
use
cases
specifically
and
again.
It's
it's
tempting
at
times
when
we
meet
together
to
you
know,
have
feature
creep,
but
we're
really
trying
to
keep
it
focused,
which
will
be
more
successful.
If,
eventually
it
does
go
towards
becoming
an
idea
of
working
group,
then
we
need
to
be
focused,
so
some
of
the
capabilities
of
be
on
edge
computing
or
whatever
you
may
want
to
call.
N
The
topic
that
we're
discussing
here
is
a
heterogeneous
IOT
device
capability.
There's
a
variety
of
interfaces
on
the
IOT
side,
ZigBee
Wi-Fi,
lots
of
different
industrial
fieldbus
technologies,
frameworks
and
protocols
that
are
being
used,
needs
to
have
low
and
deterministic
service.
Latency
data,
pre-processing
and
traffic,
offloading
system,
resource
isolation
being
able
to
support
multi-tenancy
situations
and
offline
processing
as
well
for
robustness
and
then
security
again
is
paramount.
Maybe
even
potential
topics
would
be
distributed.
N
So
there
may
be
some
API
work
needed
to
be
done
there,
and
perhaps
some
service
isolation
for
network
slicing
mapping,
services
to
specific
Network
slices
and
again
with
even
all
those
again
we're
trying
to
you
know
pinpoint
maybe
a
particular
just
one
of
those
that
we'll
focus
on
as
part
of
this
effort.
Please
look
at
the
draft.
This
is,
can
give
us
a
high-level
look
at
the
overall
architecture
where
you've
got
the
be
on
edge
computing
management
platform,
with
application
management,
device
management,
resource
management
and
even
an
SDN
platform.
N
As
part
of
that
you've
got
your
separate
IOT
cloud
services,
so
you
get
our
management
channel
and
your
data
channel
going
into
the
VEC
node
that
data
channel
needs
to
be
able
to
support
industrial
frameworks
and
protocols.
That's
what's
mentioned
in
the
previous
application,
including
frameworks
like
DDS
and
OPC
UA
and
and
things
like
that.
That's
important
and
we
need
to
be
able
to
provide
a
distributed
PC
platform
and
a
unified
API.
N
N
So
just
inclusion
last
slide,
so
our
methodology
has
been
that
you
know
distribute
as
much
as
you
can
and
centralize.
Only
if
you
must.
This
is
a
very
popular
topic.
We're
trying
to
keep
the
topic
narrow
in
our
particular
draft.
There's
some
interesting
things
that
are
happening
in
the
industry,
some
of
the
ones
that
I'm
just
being
aware
of
just
being
made
aware
recently
is
like
open
industrial
linux,
open
IL,
which
is
interesting
and
there's
security
efforts
going
on
here
in
the
ITF,
including
the
suit
off,
which
is
could
be
very
useful.
N
Maybe
we'll
find
that
some
of
the
things
that
we
develop
security
wise
may
be
contributions
into
that
into
that
effort,
which
you
are
having
a
BA
first,
not
above
a
side
meeting
or
bar
buff.
If
you
will
this
Thursday,
if
you
have
something
specific
that
you'd
like
to
contribute,
please
feel
free
to
attend.
C
Ali
karimi:
are
you
talking
about
industrial
area
like
any
industrial
in
the
area?
Are
you
thinking
about
how
they're
gonna
migrate
from
their
existing
protocol
back
nets
because,
most
of
them,
if
you
go
to
the
elevators,
you
go
into
the
electrical
grades,
all
of
them
they
do
have
bad
back
net
and
it's
very
tough
to
migrate
from
back
net
to
IP,
it's
being
challenged
for
past
five
years
and
I
know
a
couple
of
guys
from
the
ITF
engine
and
we
tried.
N
The
baby
some
comments
are
there
that's
kind
of
a
broader
question,
but
my
answer
that
would
be
through
partnerships.
You
know
vendors
of
networking
equipment
like
I
mentioned
working
with
industrial
players
like
that's
the
only
way
that
we've
been
able
to
make
it
work,
and
we
do
have
as
a
vendor
partnerships
with
elevator
companies
and
star
able
to
take
sensor
data,
put
it
into
a
edge
compute
device
kind
of
out
at
the
hand
actually
which
won't
affect
their
existing
industrial
equipment
there
and.
L
So
I
mean
this
is
currently
happening,
so
there
is
a
huge
migration
but
conversion
towards
IP
technologies
in
industry,
IOT,
and
so
why
this
is
so
relevant.
Is
that
so
they
say
all
the
automation,
companies
and
so
on,
so
they
are
currently
using
their
own,
say:
homegrown,
proprietary
computing
frameworks
who
to
distribute
data
and
to
do
and
others
and
so
on,
and
so
this
is
going
to
be
a
security
potentially
performance
and
into
a
problem
in
the
future.
So
this
is
why
this
is
so
important.
M
N
I
believe
mr.
Leong
in
this
case,
was
in
this
the
way
that
I
would
interpret
it
would
be,
there's
different,
there's
a
niche
and
there's
different
verticals
within
industrial,
whether
that
be
oil
and
gas
or
whatever
it
happens
to
be,
and
for
within
those
industrial
settings.
There's
certain
apps
that
only
work
in
those
industrial
they
aren't,
they
don't
work
in
any
other
industry.
So
the
the
goal
would
be
eventually
to
virtualize
some
of
those
applications,
and
maybe
there
would
be
a
certain
interface
model
necessary
for
those
particular
verticals
applications.
M
O
Hi,
this
is
Eve
Schuler
from
Intel
and
so
I've
been
part
of
the
dialogue.
The
last
couple
of
IT
apps
about
edge
computing
and
was
part
of
the
discussions
that
led
to
the
previous
come
presentation.
But
what
I
wanted
to
emphasize
I
love
these
gap.
Analysis
I,
love
that
we're
looking
across
all
of
these
different
groups.
O
Where
are
the
places
that
we
can
design
communication
protocols
between
those
components,
that'll
sort
of
push
the
architecture
to
be
real,
and
so
the
gap
analysis
I'd
love
to
move
that
conversation
towards
what
are
the
things
that
the
ITF
does
really
well,
whether
it's
service
discovery
or
Federation
of
things
or
you
know,
or
routing
protocols
that
are
data
centric
for
caching
in
the
network?
So
that's,
that's
one
point
is
you
know
this
is
really
a
question
for
the
community:
can
you
identify
and
prioritize
what
are
those
gaps
that
relate
to
the
communication
protocols?
O
The
second
issue
to
point
out-
and
this
is
in
contrast
to
the
previous
kinds
of
presentations
that
were
and
discussion
around
constrained
IOT-
is
that
what's
quite
interesting
about
edge
computing
or
edge
and
fog
computing
is
that
it
shifts
the
discussion
of
the
IOT
away
from
exclusively
about
constrained
devices,
because
now
you're
moving
baggage
functionality
to
the
edges
of
the
network.
Those
are
not
necessarily
constrained
devices
that
might
help
with
that
sort
of
functionality,
and
so
I
would
also
challenge
this
group
to
think
about
the
kinds
of
functionality
to
be
supported
in
the
IOT.
O
B
P
Q
It's
in
the
w3c,
it's
called
the
Epiphanes
activity.
We
have
an
interest
group
that
does
exploration
work
and
we
having
a
chartered
working
group
that
already
standardizes
the
first
building
blocks
that
we're
using
to
kind
of
do
exactly
this
kind
of
really
complex,
big
ecosystem
to
enable
application
facing
solutions
over
different
platforms
in
the
IOT
awesome.
B
D
D
We
can
still
hear
me
so
that
group
met
and
we
had
a
plug
fest,
and
we
also
had,
of
course,
standards
meeting
and
what
I
wanted
to
show.
You
here
was
basically
a
report
out
of
the
various
topics
we've
worked
on
and
so
the
the
plugfest
we
actually
looked
at
interesting
topics.
I
myself
actually
looked
at
the
problem
of
semantic
interoperability
and
we
actually
had
some
pretty
successful
approaches
where
we
combined
some
web
technologies
for
semantic
ability
with
some
IOT
technologies.
D
Yes,
right,
slides,
let's
proceed
the
first
one,
so
this
slide
deck
is
a
little
long
for
this
context,
so
I'm
a
little
pretty
fast.
But
of
course
you
look
at
the
slides
later
on
and
there's
hyperlinks
and
such
in
the
slides
as
well.
You
can
follow,
but
basically
want
to
talk
about.
You
know
what
is
interoperability
and
particular.
What
is
semantics
internally
I
want
to
talk
about.
You
know,
you
know
some
motivation
for
this
and
then
talk
about
how
we
actually
implement
it
and
I
also
want
to
walk
through.
D
You
know
the
the
test
case
that
we
did
as
part
of
the
plug
fast
apple
pie.
Okay,
so
the
next
slide.
Please-
and
this
is
in
the
context-
by
the
way
of
a
concept
we've
been
calling
ambient
game,
which
is
you
know
right
now
we
have
devices
that
are
kind
of
you
know
relatively
limited
in
their
connectivity.
You
know
either
vertically
or
horizontally,
and
we
have
a
lot
of
problems.
You
know
going
east-west,
and
this
is
a
thing
eventually.
D
You
know
constrained
to
services
running
on
fixed
nodes
at
night,
not
a
little
moving
with
this
I
think
the
long
run
you
look
at
mobile
services
services,
they
can
be
in
the
cloud
or
in
the
fog,
I
can
migrate,
around
I
can
come
and
go
and
we'll
have
to
worry
about,
discovering
them
in
managing
them,
and
so
in
the
long
run,
will
give
me
a
lot
of
stuff
to
make
this
all
happen
and
we're
just
looking
at
small
pieces
of
us
next
slide.
Okay,
what
is
it
from
Italy?
D
There's
quick
definitions
here,
so
basically
it
means
you
can
plug
things
together
and
they
work
right.
So
that's
a
simple
definition
and
but
there's
lots
of
examples
listing
standards.
You
know
good
examples:
I
can
replace
the
light
bulbs
in
my
apartment
and
you
know
I
can
go
out
and
buy
a
bowl
and
plug
it
in
that
works,
and
you
know
this
just
works
is
actually
just
a
lot
of
work
behind
the
scenes
in
standard
setting
and
so
for
the
IOT.
D
You
want
competency
thing,
it
would
take
a
device
and
have
advisors
from
different
manufacturers
and
we
just
plug
them.
In
the
same
system-
and
they
just
work,
so
how
do
we
do
that?
Next,
like
so
there's
different
levels
in
our
mobility?
A
lot
of
the
work
at
ITF
is
down
at
the
Lieven
lower
level
than
the
three
mentioned
here
at
global
protocols
or
communication,
but
level
above
that
is
once
you
have
the
data
you
know
in
the
payload.
You
have
to
decode
it
and
there's
kind
of
three
levels.
D
Now
it
turns
out
that
structural
and
syntactic,
if
we
use
things
like
XML
and
JSON,
they're,
sort
of
self
/
same,
and
so
the
structure
should
embedded
directly
in
the
standard
and
so
that
we
have
pretty
good
handle
on
that
now.
So
now
we
got
a
deal
really
with
the
how
we
handle
Mena
next
slide.
Okay
and
finally,
this
motivation
is
why
you
want
from
inability
any
ask
this
and
kind
of
the
whole
points
with
standards.
Let
me
just
address
this.
Basically,
it's
the
money.
D
D
It
turns
out
that
actually
home
is
not
the
place
enough
ability
matters,
the
most
it's
actually
the
factory,
but
it
matters
the
most
so
the
home
20
worth
17%,
but
in
the
factory
it's
worth
next
60,
so
bility
is
very
important
and
especially
in
more
industrial
use,
cases
and
institutional
use
cases,
and
this
is
basically
the
cost
of
the
integrator
put
systems
together
grows
dramatically.
If
things
are
not
a
drummer
and
next
slide
just
shows
you,
you
know
the
scale
factor
and
also
the
changes
in
the
various
areas
with
fast
little
scales.
D
D
First,
it
it
turns,
and
so
there's
been
a
project
called
Isle
schema.org
that
so
people
want
to
know
in
the
room
were
involved
in,
and
this
is
a
basically
an
attempt
to
define
a
simple
common
vocabulary
for
coyote
and
that
she
associated
with
several
other
projects
I
in
clean
RF
and
SS
an
but
it's
it's
a
nice,
straightforward
project
and
I
think
it
needs
more
attention.
But
we
attempted
to
use
it
in
in
a
test
case
during
t
pack
next
slide,
and
this
is
just
a
basic
idea
of
what
it
looks
like.
D
As
sets
or
bundles
of
these
capabilities
and
that's
the
approach
kind
of
taken
with
IOT
speed
network-
and
this
allows
you
to
actually
model
new
kinds
of
devices
as
long
as
there's
combining
existing
capabilities
so
reduces
the
need
to
introduce
new
devices
all
the
time
you
can
sort
of.
If
you
can,
you
can
model
them
as
a
collection
of
existing
capabilities,
then
you
can
proceed
alright
next
slide.
D
Now
the
web
of
Things
is
a
project
which
is
currently
been
chartered.
There's
a
working
group
we're
looking
for
a
camera
condition
by
the
end
of
2018.
There's,
currently
a
drafts
back
out.
You
can
take
a
look
at
it,
but
the
web
of
things
working
group
actually
has
three
literals
the
most
important
one
for
this
discussion
is
the
thing
description,
so
the
basic
idea
of
the
love
of
things
is
rather
than
having
a
prescriptive
standard
that
says,
to
give
to
get
an
ability.
Your
device
must
do
things
this
way.
D
If
everyone
does
things
this
way,
they'll
interoperate,
which
is
the
approach
of
no
standards,
the
well
of
things
approach,
says:
okay,
give
me
your
device
and
I
will
describe
it
with
metadata
and
then
other
devices
can
consume
that
metadata
and
they
can
interoperate
with
it.
So
the
advantage
of
the
descriptive
approach
is
you
can
do
it
after
the
fact
the
device
can
be
shipped,
it
can
be
out
there,
it
can
be
working
and
then
you
can
go
and
write
the
thing
scription
for
it
and
then
interoperate
with
it.
D
This
is
very,
very
important
in
the
handled
brownfield
problem
in
IOT,
there's
re
devices
out
there
no-one's,
gonna,
tear
them
out
to
replace
with
new
devices,
just
get
your
op
ability.
So
the
sort
of
you
know
test
in
advance
and
then
make
insure
works
before
installed
is
fine
for
new
devices
for
Greenfield,
but
it's
doesn't
really
handle
the
ground
field
problem.
So
the
descriptive
approach
handles
a
brownfield
problem
without
requiring
additional
gateways.
Basically
you
can
add
gateways,
you
know,
do
the
translation,
but
if
you
have
a
powerful
enough
description,
you
don't
necessarily
ok
next
light.
D
This
is
a
simple
example
of
a
thing
description
and
basically
it's
an
LD
file
and
JSON
you're
well
familiar
with
json-ld
is
a
serialization
of
resource
description,
which
is
a
Semantic
Web
triple
store,
and
so
it
takes
semantic
information
and
it's
been
serialized,
but
it
can
also
be
interpreted
as
a
simple
JSON
file.
So
the
stuff
and
highlighted
colors
here
actually
relates
the
semantic
capabilities
of
this
file.
D
So
the
green
cards
on
top
point
at
the
Cabul
aries
that
are
being
used
and
you
can
actually
define
prefixes
or
name
spaces
like
IOT
and
HTTP
here
and
then
within
the
file.
You
can
use
terms
from
those
vocabularies
with
the
appropriate
prefix,
so
in
the
case
of
IOT
prefix
we're
actually
using
terms
from
the
IOC
schema.org
vocabulary,
and
so,
for
example,
we
can
indicate
that
you
know
there's
a
certain
property
in
this
device,
which
is
the
IOT
switch
status
which
actually
represents
from
the
on
off
state
of
this
light.
D
D
The
thing
description
also
includes
similar
concepts
to
JSON
schema,
so
it
also
describes
the
structure
of
the
payload.
Now
payloads
may
not
be
necessarily
JSON,
but
we
can
still
describe
the
structure
of
them
with
a
JSON
equivalence,
with
the
assumption
that
we
can
convert
to
and
from
jason
next
life.
Does
that
give
you
an
example,
though?
D
The
last
thing
I
want
to
do
was
talk
about
some
proofs
of
concepts
that
we
built
at
the
whim
of
things
bloodfest
and
the
the
goals
of
proof
of
concepts.
Are
we
to
understand
what
the
heck
we're
doing,
and
so
we
kind
of
want
to
you,
know
mash
together
various
technologies
and
see
how
they
work
together
and
find
the
gaps
and
then
iterate
and
try
and
fill
in
the
gaps
for
time?
We
also.
These
are
also
very
useful
to
demonstrate
the
business
people
you
know.
D
What's
the
value
it
was
certain
challenges
or
standards,
so
I'm
going
to
walk
you
through
POC
plan
I'm
working
on
within
the
w3c
work
next
slide,
so
actually
I'm
about
halfway
through
this
plan,
and
these
are
the
four
steps
I'm
aiming
for
eventually
I'm
gonna
look
at
have
an
ambient
computing
tank
program
model,
but
right
now,
I'm
still
on
steps
one
to
working
through
midday,
bridging
and
semantics
semantics
use
case.
It's
only
going
to
talk
about
two
steps,
but
the
next
step
after
this
is
doing
integration.
D
So
this
is,
like
you
know,
all
the
bits
and
pieces
for
the
little
thing,
and
so
you
can
see
there's
also
a
natural
versatile
issue
going
on,
but
the
metadata
bridge
basically
was
using
introspection
across
ability
of
devices
now,
in
addition
to
the
ocf
metadata,
there's
also
exhilarate
metadata.
So
basically
there
may
not
be
information
in
the
ocf
metadata,
but
you
maybe
can
associate
information
with
declare
ocf
metadata,
like
users,
types
or
even
manufacturer
ids.
Then
you
can
attach
that
to
the
things
questions
as
you
generate
them.
D
So
one
of
the
ideas
here
is
that
we
can
harvest
information
from
multiple
sources
and
integrated
together
into
a
single
semantic
model
for
IOT
devices,
and
then
we
register
that
with
a
searchable
thing
directory,
then
support
semantic
queries
next
slide,
and
this
is
kind
of
a
test
set
up
and
actually
is
a
whole
room.
Full
devices
here,
I'm
just
showing
you
one
desk,
but
basically
we
have
a
bunch
of
devices
in
different
vendors
and
there's
a
gateway
in
here
too,
and
edge
devices
and
they're
all
registering
themselves
with
this.
This
gateway
next
slide
so
anyways.
D
D
Ok,
so
the
thing
directories
other
piece,
that's
interesting.
This
is
actually
an
open
source
project
associated
with
a
little
things,
but
basically
you
can
take
a
thing
description
and
you
can
is
a
web
service
interface.
You
can
register
the
things
person
with
the
thing
thing
directory,
and
then
you
can
do
another
service
entry
point
in
the
web
api
of
the
thing
directory
lets.
You
do
semantic
searches
and
you
can
basically
do
sparkle
queries
which,
let
you
do,
searches
for
semantic
terms
and
the
important
thing
about
the
semantic
terms
is
they
can
be
associated
each
other.
D
You
have
to
search
for
the
exact
same
term.
You
can
search
for
a
term,
it's
related
through
some
semantic
relationship
with
the
term
and
the
thing
directory,
which
gives
a
lot
of
flexibility
in
in
the
system.
You
know,
sir,
what
are
different
kind
of
terms
like
locations,
or
you
know,
energy
consumption
or
whatever
you
want
with
the
thing
with
the
inscription.
D
The
other
thing
that's
interesting
about
Sparkle
is
that
you
can
federates,
so
multiple
Sparkle
endpoints
can
actually
pull
data
from
each
other.
So
a
thing
directory
isn't
just
a
standalone
thing.
It
can
be
part
of
a
network
of
federated
databases
that
then
poping
together,
so
you
actually
get
a
distributed
system
for
doing
search.
D
D
I
we're
also
discovered
various
limitation
in
alteast
about
org.
It's
actually
a
pretty
limited
oncology
right
now.
It's
got
a
lot
of
inconsistencies
I'm
in
terminology.
Some
of
these
are
this
black
issues
that
some
are
you
know,
there's
no
a
community
sensor,
there's
no
like
this
and
there's
no
that
there's
a
lot
of
issues.
These
are
just
I,
think
maturity,
problems,
I,
think
the
basic
structure
is
pretty
good
and
just
a
matter
of
filling
in
a
lot
of
links
and
cleaning
up
some
of
these
issues.
D
One
of
the
nice
things,
though,
about
the
whole
structure.
If
you
don't
have
to
use
lt's,
cannot
work.
This
was
selected.
We
use
other
intelligence.
In
fact,
we
can
have
multiple
thing
description
with
different
ontology
z'
and
just
relate
them
to
each
other
with
a
third
ontology.
So
that's
a
little
messy,
but
it
is
possible,
and
so
it's
feasible
to
do
bridging
between
different
and
semantics.
So
I
think
the
strategy
here
is
just
plow
ahead:
user
ontology.
D
D
Okay
and
I'm,
going
to
have
hat
I
know
we're
running
late
today,
woman
I,
didn't
quite
get
done,
but
I
wanted
to
do
was
semantic
voice
control.
So
the
idea
here
is
that
things
like
Amazon
voice
services
have
their
own
set
of
semantics.
Their
own
set
of
intense
associated
with
voice
control
and
I
want
to
correlate
that
with
the
semantics
of
IOT
schema.org,
and
so
so
now
that
I
have
a
web
service.
The
thing
directory
that
allows
me
to
do
semantic
queries
and
to
find
things
and
to
talk
to
things
in
their
interfaces.
D
I
also
can
access
that
from
a
abs
service.
I
can
use
those
searches
to
find
any
pointers.
There's
certain
things
like
turn
lights,
on
the
lock
or
whatever,
and
so
the
next
step
here
is
to
write
an
Alexa
adapter.
That
does
semantic
queries
to
find
useful
things
to
do
given
a
certain
voice
intent
now,
I
actually
did
a
little
look
at
I.
Didn't
I
didn't
correlate
all
these
semantic
information
from
ABS
next
slide,
actually
a
let's
escape.
This
is
the
architecture
next
slide
yeah.
D
So
actually
it's
go
back
one
so
abs
itself,
of
course
the
cloud
service,
but
it
also
makes
an
assumption,
there's
a
device
cloud
that
has
to
have
a
global
URL.
So
you
need
an
entry
point
into
the
system
which
is
globally
visible,
so
basically
I'd
your
nap,
and
so
you
have
to
deal
with
all
the
issues
of
natural
vs.
all
then
you
have
to
write
this
adapter
to
be
able
to
take
intense
from
ABS
and
translate
them
into
commands
here
to
your
device
cloud.
D
Now,
there
is
also
a
couple
of
things
that
abs
does
so
there's
the
idea
of
bundling
so
getting
state
while
doing
an
action,
there's
both
absolute
and
relative
mechanisms
to
adjust
properties
which
isn't
really
something
that
isn't
generally
available.
These
are
all
things
that
can
be
dealt
with
by
having
digital
twins
or
device
shadows.
So,
for
example,
to
do
relative
adjustments.
You
can
have
a
device
Shadow
that
gets
the
current
value
updates
and
writes
it
back
on.
These
kind
of
adapters
can
can
be
part
of
the
whole
entire
system.
D
Next
Oh.
Actually
one
thing
to
mention
is
that
devices
can
also
self-report
the
capabilities.
There
is
an
introspection
mechanism
also
available
that
you
want
to
report
capabilities
back
to
Amazon,
about
what
a
device
can
do
another
place
where
the
thing
description
is
useful,
because
you
can
read
a
thing,
description
and
report
back
to
the
ABS
system.
What
a
device
can
do.
D
Anyways
ABS
has
a
set
of
capabilities.
Here's
some
examples.
You
know
power,
control
or
turning
things
on
and
off.
Obviously
that
Maps
delay.
It
shows
you
a
power,
on/off
state
temperatures
and
brightness
and
so
forth.
So
actually
ABS
home
skills
are
still
pretty
limited
to
the
set
of
devices
are
typically
shipping
right
now,
but
and
also
as
you'll
note,
it's
very
home
oriented,
which
is
probably
typical,
like
voice
control.
I
think
one
thing
we
need
to
do
is
look
beyond
home,
obviously,
but
it's
a
reasonable
place
to
start,
but
we
shouldn't
stop
there.
D
Anyways,
just
given
your
idea,
you
could
look
at
this
later
on,
but
there's
a
lot
of
predefined
capabilities,
and
these
do
map
relatively
nicely,
but
not
exactly
one
to
one
I'm
on
to
IOT.
So
our
next
slide,
yeah,
there's
also
things
with
thermostats
one
additional
things
worth
noting
is
that
abs
is
very
picky
about
the
time
it
takes
to
take
something
to
respond.
So
if
you
respond
in
less
than
eight
seconds,
it
will
assume
that
it
failed
and
will
cancel
it.
D
So
if
you
have
a
longer
running
States,
we
have
to
deal
with
it
a
multi-step
process,
and
that
requires
as
also
inventing
mechanism
and
you
have
to
deal
with
for
updating
state
asynchronously.
So
a
lot
of
these
things
are
necessarily
supported
by
the
device,
in
which
case
you
would
also
need
a
device
shadow
to
deal
with
those
things
next
step
next
slide.
Okay,.
D
Finally,
there's
just
a
bunch
of
management
stuff
that
you
know
it
raises
budgeting
questions
is
where
some
generic
management
capabilities
you
want
to
have
in
devices
and
even
if
it
fog
systems.
So,
for
example,
there's
a
message
to
check
is
the
application,
your
retail
mint
powder.
This
is
actually
a
pre
general
statement
for
any
entity
device.
D
Next
light:
okay,
since
to
wrap
up
interrupts,
bility
is
very
important.
There's
some
interesting
stuff.
We
can
do
with
semantic
search,
which
is
already
a
well-defined
technology
in
supported
by
w3c
standards.
So
how
can
we
leverage
that
we
built
a
little
test
system
that
was
actually
pretty
cool,
that
let
us
do
semantic
search
across
alti
devices,
and
this
leverages
a
scanner
working
on
three
3c4
describing
the
metadata
of
things
and
this
descriptor
approach.
The
standard
standards
is
actually
very
useful
for
brown
field
systems.
D
We
have
a
lot
of
work
to
do
and
I
think
the
way
to
to
deal
with
that
and
understand,
what's
needed
in
the
gaps
is
to
work
through
some
concrete
scenarios.
Right
now,
we've
only
done
very
simple
home
based
scenarios.
We
do
industrial
scenarios
as
well.
Finally,
in
the
long
run,
we
need
to
include
all
computing
I,
don't
consider
IT
to
be
just
end
devices
or
small
constrained
devices.
I
can
say
it
to
be
everything
that
provides
services
that
include
these
small
edge
devices.
D
B
So,
thank
you.
Michael
I
think
that
that
was
pretty
impressive
friend
and
lays
out
a
number
of
paths.
We
can
go
forward
so
by
now
that
the
session
times
over
so
I,
don't
think
we
have
time
for
questions
the
buses
here
are
leaving
in
ten
minutes
for
photos.
So
thank
you
for
the
presentation
and
enjoy
the
day
over
there
in
the
USA.
A
Okay,
thank
you,
Michael
and
thank
you
everyone
for
joining
session
today
for
more
information
about
the
future
meetings.
Please
follow
the
attending
Archie
list
and
its
best
in
the
wiki
activity
we
have
on.
We
she
touch
base
on
in
the
github
wiki.
We
have
more
information
about
the
future
cause,
so
please
do
attend
those
on
the
topics
that
you
are
interested
of
and
if
you
haven't
signed
yet
the
blue
seats,
please
do
before
you
leave.
Thank
you.