►
From YouTube: IETF100-LPWAN-20171113-0930
Description
LPWAN meeting session at IETF100
2017/11/13 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
So
good
morning,
everyone
it
seems
that
your
church
today
don't
have
a
mic.
So
that
could
be.
That
would
be
an
interesting
thing
to
to
handle.
So
we
will
need
to
do
with
our
with
one
mic
or
maybe
steal
one
of
the
mics
over
there.
Yes
thanks,
so
we
get
started
just
in
a
minute
and
by
the
time
we're
that
we
get
started.
I
would
just
like
you
to
show
you
how
you
are
going
to
be
able
to
flow
you're
able
to
find
all
the
meeting
materials
for
today.
A
So
here
we
have,
you
know,
ordered
working
groups
and
issues
scroll
down,
unto
it
to
the
int
area,
and
you
have
40
different
working
groups
that
are
in
the
interior.
You
have
LPN,
and
here
you
have
the
materials,
so
you
can
see.
You
know
the
word
start
with
the
first
presentation
that
is
introduction
a
and
then
we
move
on
down
with
the
other
with
the
with
the
other
presentations.
A
So
if
you
here,
you
go
directly
and
you
have
the
PDF
file,
that
is
the
that
is
the
source
of
this
presentation.
So
normally
we
like
going
every
time
and
you
know
opening
each
of
and
every
of
the
presentations
through
here
and
that,
as
you
see,
there
is
a
little
bit
of
effort
delay.
So
what
we
are
going
to
do
is
we
are
just
going
to
use
the
files
that
we
already
have
on
our
computer,
but
it's
exactly
the
same
material.
A
So
I
think
that,
with
this
thing
we
are
ready
to
get
started,
it's
932
and
so
hello.
Everyone
welcome
to
the
to
this
session.
So
this
is
the
LPN
working
group
and
as
any
IGF
meeting
as
any
IGF
working
group.
So
this
is.
You
should,
of
course,
read
the
note
well,
if
you
have
not
done
so.
Of
course
here
you
have
just
the
main
points,
but
please
do
go
and
read
the
document.
A
A
As
a
reminder,
this,
as
we
said
so
minutes,
are
taken
the
minute
the
meeting
is
recorded
and
your
presence
is
locked,
so
we
would
like
to
ask
you
to
go
and
to
contribute
to
the
to
the
collaborative
meeting
tool,
which
is
the
witty
etherpad.
You
have
the
link
just
here
on
the
screen,
so
it
about
the
tools
that
I
achieved
at
work,
and
so
you
can
find
this
also
on
the
on
the
link
of
the
of
the
date,
the
data
tracker
of
the
working
group.
A
A
Hole
is
who
is
here
and
you
J
holy.
That's
good
and
Julia
I
think
he
I
saw
him
yesterday.
He
will
be
coming
later
at.
We
have
at
least
two
for
the
moment
and
tomorrow
we're
coming
also
so
for
the
remote
participation
you
have
the
meet
echo
link.
That
is,
that
is
there.
So
just
we
have
already
a
couple
dozen
visitors
here.
So
that's
that's
good
and
we
also
have
a
jabber
so
for
jabber,
scribe
volunteers.
A
Okay,
so
who
do
you
burn?
Thank
you
very
much,
horror,
whoo.
So
as
a
as
a
reminder,
you
know
the
things
that
are
happening
on
Java
Rahu
can
go
on
and
say
to
the
mic
in
case
you
have
questions
or
things
like
this,
so
the
mailing
this
is
LP
man
and
the
meeting
materials
are
at
the
following
link.
We
already
saw
that
the
way
they
are
the
way
we
you
can
find
them.
A
A
So
one
of
the
points
is
that
we
would
like
to
talk
a
little
bit
more
on
the
rich
chartering
on
the
rich
are
showing
process
and
they're
charging
items
here,
so
probably
will
take
a
little
bit
more
than
20
minutes
in
the
first
slot,
and
this
is
so
we
allow
ourselves
to
in
order
to
do
this
and
at
the
ends
that
will
see
the
time
that
is
remaining.
Maybe
we
will
cut
down
on
the
last
presentation.
A
C
D
Krishnan
so
I
just
got
the
inner
LP
runs
back
last
week
for
public,
so
I'm
waiting
on
the
in
Directorate
and
the
IOT
Directorate
reviews
on
it
and
I
hope
like
I,
can
start
the
ITF
last
colonized
by
the
end
of
the
year.
So
like
let's
say,
like
the
reviews
coming
about
but
beginning
of
December,
so
I'll
go
do
more
ad
well
as
well.
At
the
same
time,
so,
hopefully
by
under
the
Year,
we
should
have
a
ITF
last
fall
on
this.
A
A
Okay,
yeah,
but
we're
using
one
of
the
one
of
the
the
the
mics
in
the
in
the
room.
So
normally
you
should
hear
us
so
maybe
a
brief
okay,
so
taking
over.
Just
to
give
you
a
super
brief
overview
of
what
has
been
happening
in
the
past
couple
of
months,
so
we
were
chartered
a
little
bit
more
than
a
year
ago,
so
we
had
after
the
documents,
were
working
really
really
hard.
A
You
know
and
with
our
initial
deadlines
in
in
gray
here,
so
we
had
six
interim
meetings
between
the
ITF
99,
98,
98
and
99,
and
then
we
had
the
first
hackathon
over
there
at
that
point
and
since
then
we
had
five
internal
meetings
and
another
hackathon
during
the
last
weekend.
So
pretty
interesting
results
there
and
I
really
do
hope.
That
will
continue
this
tradition
and
I'm,
confident
that
will
continue
and
we'll
have
a
very,
very
good
implemented
open-source
implementation
from
the
next
IGF.
A
So
continuing
this
rhythm,
with
the
inter
meetings
and
with
the
hackathon,
and
with
this
going
on
we're
actually
pretty
close
to
fulfilling.
You
know
that
and
we're
very
advanced
on
our
current
chartering
charter
and
we
discussed
already
a
couple
of
times
the
new
items
which
will
be
working
in
the
in
the
following
in
the
following
months
and
in
the
following
year,
and
this
boils
down
to
four
major
points
and
basically,
of
course
there
are.
There
were
some
others,
but
we
would
like
to
focus
today
on
these
on
these
four.
C
Okay,
so
it's
not
one
chic
of
a
free
document,
but
as
many
Chicago
foods
Escondida
technologies,
because
each
one
has
specific
requirements
and
Sheik
is
a
very
generic
architecture,
level
thing
and
when
you
want
to
go
down
to
one
particular
in
technology
which
has
these
particular
requirements,
for
instance,
frame
size
and
stream
versus
downstream
etcetera.
That's
when
you
have
to
have
how?
How
do
I
implement
the
shake
in
that
particular
use
case,
and-
and
we
already
have
two
documents
and
that
family
and
we
have
four
technologies
that
we
support.
C
A
So
exactly
in
this
line
of
thought
today
we
have
two
presentations
that
are
coming
later,
so
we
have
a
violin
Alper
that
we
are
going
to
be
presenting
remotely
this
one
doesn't
go
through
the
internet
now
at
all,
so
I
think
it's
better.
So
we
will
we'll
have
our
token
of
speech
here
so
yeah
we
have
available
now
per
that
are
going
to
be
presenting
the
first
draft
and
Juan
Carlos.
That
is
going
to
be
presenting
the
second
draft
of
the
of
the
two
technologies
and
that's
a
really
great
start,
I.
Think
on
this
point.
A
We
were
good
to
go.
We
also
have
chic
for
icmpv6
and
there
is
another
graph
that
is
out
there,
and
we
are
really
happy
about
this-
that
we
were
talking
about
real
documents
that
are
out
there
and
people
that
are
identified
in
companies
behind
this,
so
that
that's
really
really
good
on
the
data
model
for
chic
context.
So
during
this
hackathon
we
had
the
opportunity
to
actually
improve
the
yang
models,
that's
a
module
that
we
had
since
the
last
hackathon.
So
there
is
no
draft
yet
about
this,
but
the
yang
model
is
there.
A
So
there
were
a
little
bit
of
that.
There
were
several
changes
that
had
that
minor
changes,
but
there
were
that
happened
to
the
context
definition
since
the
last
ITF
and
right
now
they
are
applied
into
the
yang
model,
so
pretty
soon
will
be
actually
for
publishing
the
yang
model
and
and
will
be
able
to
be
using
it
to
sterilize
their
the
contexts.
So
that's
a
really
good
start
and
I
think
that
we'll
be
able
to
go
on
from
there.
A
A
How
is
this
perfect
architecture
going
to
be
looking
at
like
we
want
a
very
minimal
protocol
that
is
able
to?
We
are
able
to
do
the
bootstrapping.
I
mean
sorry.
I,
don't
want
to
use
the
bootstrap,
because
that's
a
very
loaded
word
here,
so
that
we
are
able
to
have
something
that
interoperate,
which
we
can
share
the
context
and
we
and
this
works,
and
from
that
on,
we
can.
You
know
we
can
see
where
it
goes.
C
So
there
are
two
questions
to
the
room.
The
first
question
will
be
for
each
of
these
items.
If
we
have
a
critical
mass
of
people
who
would
be
interested
in
working
on
it
so
for
Chicago
fewer,
we
already
have
to
document
so
I'm
kind
of
positive,
so
other
people
in
this
room
who
are
interested
in
participating
as
a
reviewer
or
as
an
author,
etc
to
work
on
Chicago
foo.
Please
rise
hands,
so
I'm,
saying
okay,
so
I'm,
seeing
a
good
number
of
hands
already
so
I
see
that
this.
C
Okay,
you're
representing
the
online
people-
okay,
that's
good,
so
icmpv6
do
people
think
that
there
is
interest
in
doing
ICMP.
We
already
have
a
draft,
so
people
in
this
room
would
be
interested
in
participating
to
the
work
or
to
the
review
of
this
document.
Of
this
work,
I
see
one
hand
two
hands
three
hands
icmpv6
more.
C
Yet
this
looks
like
an
interesting
topic
and
me
too
obviously,
data
models
for
chic
contacts.
So,
as
you
understand
this
is
to
populate
for
each
device
which
has
a
different
set
of
rules.
How
do
we
populate
the
rules?
Are
the
the
important
places
in
the
network?
So
what's
data
model
for
this
interest,
people
want
to
work
on
young
or
something
like
that
in
this
room.
C
B
A
B
Haven't
we
don't
have
a
draft
and
we
have
not
had
much
presentations
about
soil,
so
we
have
had
offline
discussion,
so
I
recognize
the
people
that
are
raising
hands
because
we
pretty
much
know
what
we
are
talking
about,
but
I'm
not
surprised
to
see
all
the
rest
of
the
people,
not
knowing
exactly
what
we're
talking
about.
So
it.
E
B
Be
a
good
idea
to
at
least
plan
to
explain
and
do
like.
We
did
last
time
at
the
yin-yang
of
things
presentation
which
was
specific
to
this
topic,
some
sort
of
intro.
You
know
to
the
brach
lp1
community,
explaining
what
are
the
benefits
of
this
data
modeling
for
a
chick
context,
and
how
can
they
be
achieved?
Talk
about
young
and
then
I'm
sure
we
will
see
more
hands
getting
raises
so.
C
B
C
F
C
Okay,
let's
see
this
document
and
let's
schedule
time
in
the
next
interim
meetings
to
elaborate
on
this,
but
basically
for
those
who
don't
know
what
we
are
talking
about.
The
chic
compression
needs
a
state
in
the
compressor
somewhere
in
the
network,
to
talk
to
a
particular
device
and
each
device
will
have
its
own
set
of
compression
rules,
meaning
that
there
is
a
need
to
express
those
rules
so
as
to
publish
them
where
it's
needed
in
the
network.
C
A
B
A
So
I
I
think
that
we
don't
want
to
spend
too
much
time
discussing
all
the
possible
architectures
out
there
that
that
could
solve
this
problem.
So
I
think
that
we
should
aim
for
something
super
minimal,
but
maybe
the
one
of
the
use
cases
to
have
okay,
like
n
device
like
a
DDD,
the
end
device
and
the
compressor
in
the
network,
and
they
talk
to
each
other,
and
maybe
the
n
device
sense
all
this.
Even
if
it's
like
one
time,
one
is
in
its
lifetime
or
something
like
this,
so
it
sends
the
context
that
is
provisioned.
A
B
C
What
I
wanted
to
say?
So
so,
yes
for
those
who
did
not
go
through
the
overview,
the
of
you
as
effectively
a
good
section
on
a
generic
architecture.
So
so,
if
you
want
to
find
the
names
of
things
for
instance
and
stuff
like
that,
we
it
took
us
a
long
time
to
just
enumerate
how
the
different
network
elements
were
called
in
various
technologies
and
give
them
a
name.
Generic
name
for
this
group
etc.
And
we
are
using
the
the
LP
one
overview
as
the
reference
for
all
this
terminology
and
for
the
function,
placement,
etc.
C
So
all
the
documents-
and
they
still
afford
to
be
made,
for
instance,
in
the
club
document,
to
realign
to
that.
But
that's
our
reference.
We
could
have
tried
to
make
a
real
generic
architecture,
etc,
but,
but
that's
a
hot,
oh
I
mean
and-
and
we
would
have
spent
too
much
time
in
doing
something
to
generate
that
nobody
would
ever
have
implemented.
So
we
just
did
the
overview,
which
has
this
simple
positioning
of
things
and
naming
of
things
and
and
we
have
to
live
with
this.
A
F
So
we
we
have
now
document
about
coop,
but
it's
very
generic
and
in
fact,
when
we
do
the
compression,
we
move
all
the
item
that
were
specific
to
co-op
to
the
ipv6.
So
maybe
we
can
use
a
rich
authoring
phase
to
to
have
something
specific
about
different
co-op
flow.
We
can
have
coming
from
different
platform
and
say
how
we
can
compress
lightweight
m2m
of
our
co-op
or
we
can
compress
kamae
of
a
co-op
and
so
after
specific
study
for
different
platform
and
put
it
in
the
Charter.
A
F
A
Okay,
so
that
that's
really
Thank
You
Hana,
that's
really
excellent
point
I,
think
that,
given
that
also
we
have
Wyson
in
in
the
Charter
that
is
IP
enabled,
and
it's
really
interesting
to
be
able
to
compress
the
co-op
part
to
run
on
over
Wyson.
So
that's
a
good
reasoning
about
this
about
the
technology
that
are
not
using
IP.
A
D
Suresh
krisshnan,
so
one
of
the
things
like
where
we
are
doing
all
this
like
co-op
stuff,
is
to
kind
of
improve
the
efficiency
of
compression
by
nailing
down
the
stack
right
like
so.
If
you
know
like
what
are
the
things
underneath
you,
you
can
do
a
better
job
than
not
knowing
it
so
I,
don't
mind
if,
like
you
know,
we
do
something
with
coop
that
kind
of
works
with
other
link
layers,
the
lower
efficiency,
but
I
don't
want
to
spend
time
like
specifically
working
on
it.
So
like
I,
I'm,
fine
with
like
what
Hana
said.
D
A
Yeah
I
think
I
I
think
I
understand
the
point
is
we
should
not
if
I
try
to
refresh-
and
you
tell
me
if
this
is-
we
should
not
remove
things
from
consideration
if
they
bring
more
optimization,
but
they
do
require
to
go
down
to
the
IP
layer.
We
should
not
say
well,
you
know
this
is
only
co-op
stuff
and
this
only
co-op
stuff.
You
know
says
that
we
cannot
use
this
optimization
so.
B
No
just
to
support
I,
guess
the
the
previous
speakers
Juan
Carlos,
and
it's
worth
having
an
topic.
We
can
bring
some
exactly
how
what's
the
best
way
to
do
it
and
if
it's
over
one
draft
or
the
others,
but
it's
definitely
worth
capturing
that
there
is
interest
in
in
doing
this
in
the
area.
Chartering.
C
And
we
will
come
true
after
mean.
If
somebody
wants
to
start
a
draft
I,
don't
know
lightweight
m2m
or
whatever
else
over
co-op.
For
you
know
she
compresses
that
or
whatever.
Yes,
we
would
welcome
these
draft
in
the
working
group.
I
would
like
to
see
activity
like
interested
people
etc
before
making
it
a
charter
item.
I
want
to
make
sure
somebody
is
working
on
it,
but
she
curfew,
we
know
is
ICMP.
We
know
data
model,
we
know.
So
that's
why
I
wrote
them.
C
C
A
Think
Charlie
should
also
go
into
the
list
of
contributors
and
I
think
that
this
is
something
that
we
had
not
put
there.
So
pretty
sorry
Charlie
for
about
this.
So
this
is
really
an
amazing
work
from
my
perspective,
and
is
it?
Can
you
go
to
the
next
slide?
Please
so
about
the
document,
so
a
very,
very
short
refresher
of
what
this
document
is
about,
but
because
of
course
you
already
know
a
lot
about
it,
so
it
has
like
four
main
sections:
the
baseline
technologies.
So
it
there's
an
overview
of
four
basil
and
technologies.
A
It
introduces
some
generic
terminology
and
some
generic
architecture,
and
then
it
provides
gap,
analysis
and
some
common
security
considerations.
So
for
me
this
is
a
really
really
really
excellent
document
to
go
on
for
a
person
that
knows
nothing
about
LPNs
and
go
down
and
learn
about
the
main
technology
that
held
out
there
and
some
of
the
really
important
properties
that
helped
us
develop
our
our
standards.
So
the
big
picture,
like
a
very,
very
far
away,
provide
enough
background
information
so
that
the
workgroup
can
make
sufficiently
informed
decisions
while
doing
standard
track
work.
A
So
this
is
the
background,
and
so,
while
I'm
presenting
also
I
did
the
shepherding
review
of
this
document
and
I
must
say
that
it
really
it's
a
very
interesting
process
is
the
first
time
I
was
doing
shepherding
and
I
actually
looked
back
at
the
whole
process.
The
way
the
document
was
was
developed
and
I
really
really
find
a
very,
very
rich
document.
So
it
is
lots
of
constructive
discussions
on
the
mailing
list
on
a
topic.
That
is
not
particularly
it's
not
simple.
A
If
you
look
at
it
from
from
far
away
right,
but
a
lot
of
discussions,
many
people
were
doing
this.
It
eat
it.
It
represents
a
big
investment
in
time
in
in
efforts
in
yeah
and
any
discussions
for
many
many
people
it
has.
Actually,
it
is
the
basis
of
for
at
least
four
big
drafts
that
are
on
the
different
baseline
technologies,
plus
several
more
on
the
gap,
analysis
and
city
and
all
this
so
I
think
that
it's
a
really
really
great
process.
A
When
you
look
from
where
we
are
today,
we
have
the
opulent
overview
document
and
when
we
look
back,
there
were
many
many
individual
drafts,
many
many
drafts
that
are
actually
supported
and
provided
by
alliances,
companies,
individuals
that
actually
were
then
combined,
and
there
were
all
the
discussion
of
how
do
we
make
this
thing
then?
So
I
really
love
the
process.
A
We
did
the
IPR
review
and
there
is
no
RP
on
this
document
in
this
particular
document.
So
it
was
far
and
really
happy
about
this
I.
Don't
remember
if
there
is
any
more
slides
on
this.
Yes,
so
we
managed
to
do
all
the
things
that
are
necessary
by
this
IGF
and,
as
server
said,
we
fired
up,
for
which
we
sent.
We
send
the
d2
submitted
to
our
G
for
publication,
so
that
was
done
the
last
week
and
we
have
the
reviews
that
were
requested
by
the
IOT
tier
and
Inter
Directorate.
A
So
we'll
have
the
reviews
of
the
documents-
and
you
know
with
hopefully
we'll
be
able
to
get
it
for
our
last
color
ITF
last
call
by
the
end
of
the
year,
as
Suresh
just
announced
us
so
about
the
new
work,
and
this
actually
comes
back
to
Han,
Carla's
comment
from
and
so
to
the
other
commands.
During
the
discussion
we
have
new
work
coming
and
we'll
really
suggest
that
the
authors
and
the
Deo
in
the
writers
of
the
new
documents
take
a
look
at
this
LP
on
overview.
A
That
has,
it
is
really
a
very
rich
source
of
information.
It
has
already
been
cited
and
used
in
many
many
external
reviewers
and
external
resources
outside
the
ITF,
because
the
ITF
is
viewed.
As
you
know,
this
authority
that
is
out
there-
and
there
are
very,
very
few-
if
not
to
say
none
of
authority
meant
that
actually
describes
in
such
detail.
This
variety
of
lp1
technologies
that
boils
down
this
common
architecture
that
boils
down
this
common
terminology.
There
is
nothing
out
there
that
is
at
the
same
level
of
quality,
similar
of
investment
same
level
of
endorsement.
A
So
this,
even
though,
for
us
it's
like
we
say,
okay,
let's
do
this
information
that
will
help
help
us
do
the
real
work.
It
is
actually
out
there
already
serving
people
serving
the
industry.
So
I
would
like
just
to
thank
very
much
all
the
authors,
all
the
contributors,
everyone
that
was
participating
in
the
mailing
list
around
that
contributed
and
that
got
over
this
long
process.
So
thank
you
very
much
and
really
congrats
on
the
amazing
work
that
you
have
all
done.
Thank
you
very
much.
C
F
Okay,
so
I
will
present
you
one
part
about
compression
and
fragmentation
and
Juan
Carlos
will
count.
Callis
story
will
continue
with
the
fragmentation,
so
here
is
a
delta
between
the
previous
version
and
version
seven.
That
is
the
current
version
of
the
draft.
So
what
we
we
have
done
so
in
in
the
compression
phase.
There
is
not
a
lot
of
changes.
The
main
change
is
that
we
introduced
in
the
context
the
length
of
the
field.
So
what
can
be
useful
for
in
certain
scenario?
F
We
also
agree
on
the
names
that
we
are
using
for
fragmentation,
and
we
have
also
now
a
state
machine
that
is
quite
impressive
about
the
fragmentation
in
a
different
mode,
and
what
we
have
to
do
right
now
is
to
make
a
little
change
in
the
text
to
make
it
clearer,
but
we
have
now
all
the
topics
we
have
a
very
stable
document,
so
what
we
have
changed
here
is
not
very
nice
for
them.
Second
one,
but
here
we
have
so
we
have
introduced
this
field.
Arafat
is
a
Finland.
F
So
now,
in
the
context,
we
have
the
Phil
idea.
That
said,
tell
you
what
what
is
the
nature
of
the
field?
Then
we
have
the
position
etc
extra
and
we
had
the
Finland.
So
what
is
interest
of
this
when
you
have
ipv6
of
UDP
is
not
very
useful
because
you
know
the
length,
but
when
you
have
coop
you
have
some
feel
that
I
variable
like
you
are
a
path
for
this
kind
of.
Are
you
a
gray
you
require?
And
so
for
this
we
have
to
situation.
F
For
example,
you
have
a
protocol,
but
user
always
the
same
length.
Four
fields
or
let's
say
that
you
are
a
path,
is
four
bytes
long.
So
if
we
use
this
field,
we
can
say
it's
four
on
this
way.
We
don't
have
to
send
the
length
every
time
we
send
this
URI
path
on
for
over
protocol
URL
path.
We
have
will
have
a
variable
length
and
therefore,
when
we
do
the
series
ation,
we
resent
the
length
before
the
value.
F
F
So
the
other
thing
is
that
we
make
a
consensus
on
the
name
for
fragmentation.
So
before
we
in
the
document,
we
have
the
window
mod
on
the
packet
mod,
and
now
we
just
focus
on
the
window
mode.
It
means
that
we
send
an
acknowledgment
from
time
to
time
on
not
only
at
the
end
of
the
all
the
fragmentation
process.
So
we
do
this
right
now,
because
it's
we
will
have
trouble
if
the
packet
is
very
long,
then
the
bitmap
by
technology
packet
can
be
also
very
wrong
and
cannot
enter
in
the
acknowledgement
part.
F
So
we
have
to
define
another
protocol
and
it
makes
things
more
and
more
complex.
That's
why
we
want
something
that
is
very
simple
but
works
for
a
lot
of
situation
where
we
we
keep
the
window
mod.
So
now,
in
the
window
mod
we
have
three
behavior
one
is
for
nowak,
so
you
send
the
information
and,
at
the
end
of
Mick,
to
guarantee
that
everything
has
been
well
received.
F
We
have
a
con
error,
so
we
do
the
same
thing,
but
when
we
detect
an
error
during
the
window,
the
receiver
will
send
a
bitmap
but
say
which
bit
which
fragment
are
missing
and
we
have
a
cool
ways
that
is
more
formal.
Where
every
at
every
end
of
the
window,
then
we
send
an
acknowledgment
to
tell
if
it's,
okay
or
not,
so
we
introduced
new
vocabulary
mainly,
and
so
we
introduce
all
the
windows
notion
of
all
0
on
of
all
1.
So
it's
a
fragment
compressed
number.
F
F
All
the
time
in
the
hallways
on,
if
there
is
error
on
a
corner,
are
all
one
is
the
one
that
says
that
this
is
the
end
of
the
frag
fragmentation,
so
the
end
of
the
packet
and
all
one
will
carry
a
Mick.
So
this
way
we
we
can
check
the
integrity
of
what
we
we
have
received
so
with
all
zero
under
one.
We
can
also
have
some
way
to
do
to
send
some
abort
message
to
start
the
fragmentation.
For
example,
if
we
have
some.
F
If
the
sender
of
the
receiver,
they
said
that
is
not
interested
to
continues
the
process,
so
I
will
go
into
some
detail
to
explain
all
these
all
these
things.
So
here
is
an
example
of
a
fragmentation
process.
So
we,
the
sender,
is
sending
a
window
here
so
6
to
0
is
the
fragment
compressed
number.
So
we
take
an
example
where
the
FCN
ant
is
on
3
bits.
So
here
we
send
this.
So
it's
what
you
read
here,
the
rule
on
the
right
is
what
you
receive.
F
So
you
have
already
is
a
d'
tag,
but
can
be
optional.
The
windows
FC
end
and
then
the
pillow
pillow
de
éxito
Xterra
until
FCN
reached
zero
zeros,
which
means
that
is.
This
is
the
end
of
the
window
on
FC
and
0.
0
triggers
an
acknowledgment
which
contain
a
bitmap
and
that's
a
little
bit
confusing
at
the
beginning,
which
you
are
not
used
to
that,
because
the
acknowledgement
is
a
bitmap.
So
when
you
look
at
the
numbers
is
not
a
number
at
at
the
end,
so
it
needs
some
training
to
to
be
used
to
that.
F
But
here
you
have
an
example
of
the
bitmap
everything
has
been
received,
so
all
the
bits
are
set
to
1,
so
we
define
the
order
and
the
last
one
is
all
0
or
all
1.
So
all
0
or
1
takes
the
same
position
on
the
bitmap,
because
in
a
window
you
can
have
only
all
0
or
only
all
1,
but
not
that
two
at
the
same
time.
So
here
we
have
this
this
thing,
so
we
trigger
the
bit
nap
on
at
the
end.
F
So
for
the
last
window,
the
last
window,
maybe
not
full,
because
you
don't
have
enough
packet
to
complete
it.
So
what
we
recommend
in
the
document
a
in
the
draft
is
that
you
use
the
lowest
number
to
have
the
last
packet
that
will
be
1
and
then
all
1.
To
say
this
is
the
end
of
of
the
fragmentation
and
in
the
all
one
fragment
as
I
say,
we
introduce
a
Mick
but
allow
us
to
detect.
F
If
we
have
some
some
trouble
in
the
transmission,
so
era
is
what
we
propose
also
to
to
add
is
an
optimization
when
we
send
a
bitmap.
It
means
that
if
all
the
bits
of
the
bitmap
are
set
to
1,
so
we
don't
have
to
send
them
on
the
length
will
help
us
help
the
receiver
to
know
that
all
these
bits
that
we
are
not
sending
us
are
equal
to
1,
so
that
lead
to
an
optimization
here,
for
example,
in
this
first
phase
in
the
first
window,
all
the
bit
aside
to
one.
F
So
we
will
send
only
a
complete
byte
here
with
maybe
a
part
of
the
window.
So,
but
something
also
that
is
very
important,
and
we
have
studied
this
in
detail
in
fragmentation.
Is
that
the
either
if
it
was
a
compress
either
or
the
fragmentation
either,
is
not
a
line
and
a
byte
boundary?
So
we
have
to
take
care
of
this,
and
when
we
are
sending
information,
maybe
with
this
information
we
are
padding
and
of
course
the
receiver
is
not,
cannot
make
the
difference
between
fields
and
only
padding.
F
So
that
can
be
a
problem,
and
we
study
this
in
in
detail
to
avoid
problem.
So
as
I
say,
for
example,
where
you
have
one
bit
here
but
is
a
bit
mad
on
with
suppress
the
rest
to
have
an
optimization
and
to
set
bandwidth
for
if
you
have
an
error,
for
example,
here
we
are
losing
the
fragment
FC
n
3.
So
we
have
a
bit
equal
to
0
here,
so
we
have
to
send
the
full
sequence-
and
maybe
here
you
have
some
padding
bits
that
are
here.
So
this
is
a
optimization
of
the
bitmap.
F
Another
thing
that
we
can
use
is
here
if
I'm
not
wrong,
so
here
is
a
sense
in
IO,
so
the
sense
in
IO.
The
only
difference
is,
for
example,
we
are
losing
the
first
fragment
here
of
the
second
window,
and
so
we
have
a
bit
equal
to
0,
and
it
just
show
you
that
we
can
continue
to
have.
This
optimization
is
only
when
a
bit
set
to
0
in
the
rest
that
you
have
to
send
more
more
bite.
F
So
what
we
can
do
also
with
this
optimization,
is
that
playing.
We
know
that
now
we
have
the
reduce
when
we
send
a
bitmap,
it's
always
the
smallest
one,
and
so
we
we
can
play
with
some.
If
we
have
bigger
value,
then
we
can
use
them
to
send
exceptions,
for
example,
and
abroad.
Here
is
defined
as
an
optimized,
bitmap
plus
bits
equal
to
1.
So
normally
it's
impossible,
because
if
we
do
the
optimization
we
will
not
have
this
bit
equal
to
1.
F
So
if
the
sender
is
sending
them
its
mean
that
the
length
is
not
correct,
so
we
can
say
this
is
an
about
message,
and
so
we
can
stop
the
transmission.
So
we
have
this
example
that
is
given
here
and
on
the
other
way
we
have
an
abort
that
will
be
to
send
all
one
message
without
the
Mik,
so
normally
all
the
old
one
message
contain
a
make
and
if
it's
shorter,
when
it's
we
can
use,
it
too
send
to
show
a
problem.
F
So
this
way
we
play
with
the
lengths,
and
so
we
set
the
bandwidth
and
we
don't
have
to
create
new
rule,
ID
or
new
things.
That
could
be
a
problem
because
normally
we
want
to
restrict
the
size
of
the
righty.
So
if
we
create
new
ones
and
we
can
lose
some
some
space
in
the
frame,
so
we
play
a
lot
with
the
length
which
is
a
kind
of
meta
information
we
we
set.
F
So
the
last
thing
we
add
in
in
the
draft
is
a
notion
of
empty
l1
or
empty
old
zero,
which
used
to
trigger
to
set
to
ask
the
receiver
to
send
again
the
bitmap.
So,
for
example,
in
the
second
phase
here
in
the
window
1,
we
have
an
example
where
we
are
sending
the
last
window,
so
2
1,
&
7,
so
7
is
old
one.
So
here
it's
trigger
an
acknowledgment
and
the
acknowledgement
is
lost.
So
in
that
case
the
the
sender
can
send
an
empty
one.
F
So
without
information-
and
this
way
it
will,
the
receiver
will
send
again
its
bitmap
so
on
in
the
bitmap.
It
will
notice
what
information
is
lost
or
or
not,
and
then
resend
it
again.
So,
for
example,
in
the
window
0
we
have
another
behavior.
Where
is
the
old
one
that
is
lost?
So
the
sender
start?
A
time
out
because
you
don't
receive
a
bitmap
and
here
is
its
fragment
zero
that
is
lost
so
in
the
bitmap.
We
know
that
is
fragment
zero,
that
is
lost
and
after
is
not
represent
in
this
drawing.
F
But
after
that
we
will
have
to
send
again
fragment
zero,
of
course
here
with
the
data.
So
that's
the
things
we've
introduced
as
optimization
to
save
the
done
with
when
we
are
doing
fragmentation.
So
that's
what
we
have
done
right
now,
so
tomorrow
we
will
walk
more
on
the
state
machine
on
the
different
phase,
but
to
finish
the
document,
what
we
have
to
to
do
is
to
finalize
the
description
of
abroad
on
the
optimization
of
the
bitmap.
F
We
have
to
rewrite
the
example
to
take
into
account
visit
emulation,
and
we
are
also
to
introduce
some
text,
because
it's
something
that
is
quite
complex
and
is
not
Rea
you
command
is
that
we
have
either,
but
you
are
not
aligned
on
bit
byte
boundary.
So
we
have
to
explain
how
the
padding
is
done,
how
you
remove
the
padding
when
the
receiver
and
all
that
stuff
and
when
we
have
done
that,
we
we
hope
that
the
document
will
be
finished
and
that
we
can
publish
it
okay.
So
if
you
have
questions.
B
Thanks
phone
conversation,
you
get
one
quick
question:
there
were
a
few
changes
between
the
last
versions:
I
think
5,
5,
6
7,
where
the
the
state
machine
was
moved
back
and
forth
between
the
annexes
and
and
and
and
back
to
the
main
body.
Was
there
like,
besides
editorial,
where
there
like
a
major
changes
currently.
C
H
So
since
prac
Rohan
has
introduced,
we
have
published
two
revisions
of
the
document
either
six
and
zero.
Seven
and
Rohan
has
already
provided
many
details
on
zero
seven.
So
then
I
will
focus
on
some
of
your
dates
in
0-6
and
also
we'll
talk
about
things
that
are
on
the
table
for
the
upcoming
new
version
of
the
document,
which
will
be
zero
eight,
so
that
the
plan
for
zero
eight
is
actually
to
complete
the
work
in
zero.
Seven,
as
was
discussed
recently,
and
we
plan
to
review
carefully
the
document.
H
We
need
to
consider
all
possible
corner
cases
and
try
to
solve
them
and
by
the
way,
there's
this
specific
side
meeting
that
has
been
scheduled
for
tomorrow
in
butterworth
room
from
9:30
to
12:00.
So
please
be
aware
of
this,
and
after
that,
when
we
publish
zero
eight
well,
this
should
hopefully
be
the
version
that
would
possibly
be
intended
for
working
group
muscala.
H
So
let's
go
through
the
updating
in
through
six.
So,
first
of
all,
there
was
an
a
dating
always
we
clarified
the
behavior
of
the
receiver
on
when
it
needs
to
check
the
the
NIC
after
they
have
been
retries
in
the
last
window
of
fragments.
So
it
is
after
the
oh
one
fragment
the
last
one
of
the
packet
is
received.
H
However,
based
on
implementation
experience,
it
found
that
actually
only
the
last
one
was
used
in
practice,
so
the
first
one
was
actually
removed
and
in
addition,
still
in
aqueous,
we
added
some
text
recommending
the
echo
is
timer
to
be
reasonably
short
in
order
to
avoid
potentially
long
fragmented
packet
transmission
latency.
So
then
about
a
chimera
mode.
H
We
added
the
parameter
max
track
retrace,
which
was
not
defined
for
this
mode
previously,
and
the
intent
here
is
to
mitigate
a
potential
attack
that
can
be
performed
whereby
malicious
node
may
repeatedly
transmit
an
acknowledgment
reporting
that
there
are
some
fragments
missing
and
forcing
the
fragment
sender
to
transmit
and
retransmit
those
apparently
missing
fragments.
So
this
would
consume
valuable
resources
such
as
energy
bandwidth
and
so
on,
and
the
intent
here
is
to
apply
a
maximum
to
the
number
of
fragment
retrace
to
have
some
limitation
to
the
extent
of
this
attack.
H
So
by
the
way,
this
is
also
now
discussed
in
the
security
considerations
section
and
well.
There
were
also
a
few
editorial
updates
in
0-6
few
minor
forms
in
the
abstract.
Also,
we
merged
former
sections
5.2
and
5.3,
which
provided
the
definition
of
the
different
reliability
modes
and
the
discussion
of
those
modes
respectively.
So
we've
merged
them
into
a
single
section
which
is
possibly
more
efficient
and
better
for
the
the.
H
So,
oh
well,
there
has
been
the
last
version
published,
which
is
0:07
soul.
Ohon
has
provided
many
details
on
that.
However,
we
have
continued
analyzing
the
document
and
we
have
found
some
additional
problems
and
thought
about
possible
oceans.
So
the
the
main
currently
problem
on
the
table
is
on
darling
fragmentation
and,
like
always
so
we
have
that
in
some
lt1
technologies
and
a
blink
message
is
needed
in
order
to
enable
the
transmission
of
a
number
of
downlink
messages.
H
This
number
currently
and
typically,
is
one
so
because
of
this,
we
may
find
an
issue
when
we
have
darling
fragment
transmission
in
eco
ways,
so
we
have
this
figure
on
the
slide.
The
tries
to
illustrate
the
problem
that
may
happen
so
in
the
figure
by
the
way,
a
transmission
from
the
right
to
the
left
means
a
downlink
transmission.
H
So
what
we
have
here
is
the
N
device
that
sends
a
first
uplink
message
which
serves
as
a
trigger
to
enable
downlink
transmission
and
then
the
network
side
with
a
FEMEN
sender,
starts
with
the
first
fragment
of
a
larger
packet.
Then
there's
an
acknowledgment
in
response,
then
there's
the
second
fragment
transmitted.
All
of
these
that
the
sim
are
successfully
received,
but
then
the
second
acknowledgment,
let's
assume,
gets
lost.
So
the
problem
here
is
that
the
the
fragment
sender
has
the
echo
is
timer.
H
Will
try
upon
expression
of
the
timer
will
try
to
transmit
the
at
request.
However,
it
will
not
be
possible
to
transmit
such
downlink
requests,
because
there
is
not
an
oblique
message
that
enables
that
transmission.
So
the
problem
is
that
at
this
point,
communication
stalls
so
there's
a
solution
we've
been
discussing
in
the
interims,
which
is
the
following
one.
H
A
H
The
assumption
is
that
the
oh
one
fragment
and/or
the
whole
last
window
if
the
window
is
larger
than
single
fragment,
all
that
was
successfully
received,
and
also
the
last
acknowledgment
which
confirms
correct
reception
of
the
last
fragment
or
fragments
reporting
that
everything
has
been
successfully
received.
That
acknowledgment
has
also
been
lost,
so
it
is.
This
is
the
most
likely
situation,
and
this
is
what
the
fragment
sender
assumes
an
alternative.
H
The
other
possible
situation
is
that,
for
example,
the
old
one
fragment
might
have
been
lost
and
there
could
have
been
several
at
retrace,
but
all
of
those
being
lost
as
well
is
something
that's
quite
unlikely,
so
because
that's
not
unlikely
that
is
not
what's
being
assumed
here.
So
this
is
efficient
in
the
sense
that
we
we
avoid
to
do
something
strange,
like
the
fragments
entered,
transmitting
a
confirmation
that
we
have
received.
H
The
final
acknowledgment,
and
also
this
is
configurable
in
a
way
because
we
can
increase
the
reliability
of
this
last
part
by
setting
high
enough
akka
ways
timer,
so
they
have
been
also
some
other
corner
cases
we've
been
collecting
so
by
the
way
it
is,
for
example,
we
have
this
discussion
tomorrow
and
to
continue
looking
at
these
corner
pieces
in
the
next
days.
So
a
first
one
is
okay.
What
happens
if
the
NIC
check
fails,
but
the
sequence
of
FC
ends
is
apparently
correct.
First
of
all,
the
idea
is:
okay.
H
Is
this
possible
at
all
and
if,
yes,
which
should
be
the
reaction
of
the
receiver,
especially
in
the
act
modes,
so
this
is
one
thing
to
possibly
consider
another.
One
is
a
potential
issue
in
a
chimera,
so
we
may
have
a
situation
where
the
sender
may
transmit
all
the
fragments
and
all
of
them
could
be
lost
so
because
of
the
nak
oriented
behavior
of
this
mechanism,
the
receiver
cannot
generate
feedback
by
default
and,
however,
the
the
sender
would
assume
that
transmission
was
successful.
H
So
this
is
a
false
positive
and
we
might
want
to
discuss
or
consider
whether
it
would
be
good
to
what
possibly
as
an
option
the
option
to
have
a
final
acknowledgment
which
would
be
transmitted
by
the
receiver
unconditionally
at
the
end
of
the
packet,
and
it
is
that
by
doing
this,
we
would
allow
the
fragment
sender
to
know,
at
least
in
some
cases,
that
there
has
not
been
a
false,
positive.
So
well.
These
are
other
issues
or
possible
corner
cases
are
the
ones
that
we
will
consider
in
the
next
upcoming
days.
B
Thanks
Curtis
just
want
to
make
sure
I
understand
that
and
clarification
I
guess
when
the
the
me
check
you
mentioned
I
think
on
slide
three:
it's
not
exactly
the
same
issue
right
that
we
are
about
that
the
very
end,
because
you
are
talking
about
what
is
the
condition
to
send
the
ACK
and
if
it's
based
on
FCN
make
and/or,
and
that
is
the
issue
right
like
what
exactly
is
it
the
trigger
of
the
arc?
Yes,.
H
So
it's
actually
two
different
situations
here.
Initially
this
problem,
the
problem
was
that
it
was
not
so
clearly
specified
what
was
the
task
of
the
receiver
and
they
were
retries
in
the
last
window.
However,
what
is
indicated
here
is
something
that
might
be
different,
which
is
oh,
we
receive,
apparently
all
fragments
all
fcns
have
the
correct
sequence.
Apparently,
there's
no
gap
in
the
sequence
numbers.
However,
the
mick
check
fails
what
happens
in
that
case.
How
do
we
react
to
that
if
that's
possible
at
all?
Okay?
So
that's
two
different
situations
so.
I
B
B
H
A
H
C
Understand,
CRC
undetected,
error
all
right,
so
you
have
many
bits
which
are
lost
and
you
have
a
chance
out
of
two
of
the
power
16
or
something
that
that
the
wrong
frame
gives
you
the
right
zeros
that
unit
and
they're
rare.
We
must
detect
it
and
I
bought
our
drop.
The
thing
you
can't
know
which
one
of
all
the
packets
at
the
wrong
source
you
need
to
drop
the
frame,
but
you
need
to
know,
don't
stay
home
there.
Just.
J
C
F
Agree
with
this,
but
one
thing
that
we
didn't
specify
in
the
document
is
Mickey
algorithm.
So
one
question
is:
do
we
define
a
generic
one
that
we
can
apply
a
default
one?
Even
if
it's
not
a
good
one?
We
are
very
lucky
in
in
shape
because
we
have
context
and
to
end
so
we
can
change
a
Mick
without
any
problem
if
we
find
something
better,
but
we
have
to
start
with
something.
So
like
a
crc32
or
something
like
that.
F
H
My
my
own
opinion-
and
this,
if
I
may,
is
that
possibly
I'd
say
that
the
best
place
would
be
to
to
define
specific
mix
for
Chicago
food,
because
we
might
optimize
that
the
kind
of
meat
we
are
using
or
the
selection
of
meek
to
the
specific
characteristics
of
the
underlying
technology.
However,
that
noise,
that's
I,.
F
A
So,
just
a
last
point
after
these
presentations
has
send
it
I
feel
really
very
happy
with
all
the
things
that
been
happening
on
the
mailing
list
and
during
the
last
interims
and
all
the
advancement
that
have
been
made
to
the
to
the
document.
Because,
right
now
we
have
the
FSM.
We
have
the
state
machine
we
have.
We
are
right
now
that
they
do
the
way
I
see.
A
The
work
is
like
really
narrowing
down
the
final
bits
of
some
corner
cases
that
might
arrive
in
some
very
specific
scenarios
in
a
type
of
technologies
that
we
have
never
seen
before
and
type
of
behavior.
That
is
super
rare
until
now
and
will
become
more
and
more
and
more
and
more
Oba
coitus
in
in
the
world
of
IOT.
A
Hopefully,
I
hope
that
tomorrow
morning,
during
the
meeting,
the
fragmentation
will
be
really
working
on
a
very
close
formation
to
to
clear
out
all
the
other,
the
the
the
the
details
that
are
there
to
be
cleared,
I
I
think
that
we
will
have
something
really
really
really
great
and
that
is
simple
to
implement.
That
is
really
efficient.
So
I'd,
like
also
to
thank
you
and
to
invite
everyone
else
here
that
will
be
interested
in
in
to
coming
and
participating
in
to
this
meeting.
Please
do
so
it
is
in
in
which
room
is
it.
A
F
Coop
over
Shakya,
so
it
is
a
very
short
presentation
because
we
don't
have
done
a
lot
of
work
and
on
these
things
last
time,
for
a
reason-
and
we
explained
before
we
focus-
we
spend
a
lot
of
time
on
fragmentation
and
all
the
good
stuff
that
we
are
designed
for.
Coop
has
been
put
in
ipv6
draft,
so
there
is
no
specific
things
for
for
coop.
F
A
So
relate
this
question
and
also
to
the
I
think
you
until
to
this
question
and
also
to
the
questions
that
were
we
had
during
the
first
part
of
the
meeting.
This
would
mean
that
we
might
need
some
kind
of
informational
document
or
something
at
least
for
specifying
other
the
types
of
traffic
that
we
would
like
to
compress
with
co-op.
A
A
So
we
have
around
six
people
there
in
in
the
room,
so
I
think
that
we
will
need
a
little
bit
more
of
this.
So
six
is
not
bad,
which
it's
it's
good,
very,
very
good,
but
I
think
that
it
would
be
good
if
we
have
more
input,
also,
maybe
from
the
core
working
group
Carsten
to
to
see
the
type
of
traffic
that
we
might
be
willing.
We
might
be
interested
in
compressing
so
that
we
goes
into
this
document.
F
Custom
moment
yeah,
it
would
be
a
good
thing
to
make
us
play
again
at
the
core
meeting
in
on
the
core
mailing
list
and
and
ask
appear
to
buy,
contribute
for
six
open
at
the
time.
I
had
a
repository
where
we
collected
traces,
and
that
was
really
useful
when
we
did
the
generic
header
compression
okay.
So
maybe
we
should
actually
set
something
up
for
that
for
court
as
well.
Okay,.
A
J
J
Echo
request,
I
think
they
had
the
proposal
as
well,
so
which
is
in
four
four
four
three.
It
defines,
as
I
said,
the
basic
icmpv6
message
format,
so
it
has
a
format
and
then
it
defined
six
messages.
Four
of
the
error
class
and
two
of
the
informational
class.
The
error
messages
are
destination
unreachable,
which
you
expect
to
get
when
your
IP
packet
didn't
go
through
the
packet
too
big
error
message.
J
If
it
couldn't
be
transmitted
on
the
link
and
the
the
time
exceeded
message
which
could
return
either
a
code
number
indicating
that
it's
a
time
actually
a
time
problem
or
a
hop
limit
problem,
which
is
apparently
more
frequently
used
on
time,
so
the
it's
kind
of
a
misnomer.
But
it's
called
time
it's
idiot,
even
if
it's
used
for
hop
limit,
and
this.
A
J
By
trace
rot,
so
if
you
do
a
trace
route,
you
will
increment
the
hop
limit
and
you
expect
to
get
a
an
error
message
of
this
type
at
each
successive
hub,
and
this
is
how
you
see
that
the
route
that's
been
followed
by
your
own
packet
and
the
parameter
problem,
which
could
be
any
other
field.
That
was
incorrect
for
delivery
of
your
IP
packet
and
then
the
informational
message
is
a
famous
echo
request
and
echo
reply,
which
is
used
by
ping,
and
so
this
draft
this
RFC
mandates.
J
That
host
listens
to
the
equal
request
and
response
with
an
equal
reply.
So
this
is
the
general
behavior,
that's
expected
from
an
IP
network,
and
so
the
question
is:
what
do
we
do
here
and
at
this
point
in
time
we
are
just
opening
the
discussion
and
that's
where
we
want
feedback
on
all
this
expected
behavior
from
an
IP
network.
Do
we
want
this
to
happen
on
the
IP,
enabled
LP
ones,
or
is
it
a
bad
idea,
but
I
think
we
should
describe
what
happens.
J
If
we
decide
we
don't
do
something,
then
we
want
to
write
that
we
don't
do
it
for
a
reason.
So
people
don't
ask
for
it
again
and
again
or
don't
expect
it,
and
so
here
is
a
list
of
situations
that
we
consider
in
this
draft
and
a
few
potential
answers.
So
the
first
question
is
at
the
first
scenario,
is
a
IP
source
on
the
Internet
sense
to
a
destination
that
is
a
device
or
the
lp1
and
the.
J
J
Well,
should
this
message
originated
from
well
as
much
as
possible,
not
from
the
device
itself,
if,
if
the
network,
if
the
IP
e
shake
core
compressor
detects
issues,
and
it
should
send
the
icmpv6
message
back
from
there
and
not
go
all
the
way
to
the
device
as
much
as
possible,
so
this
is
a
kind
of
situations
we
described
in
the
draft
now.
The
second
situation
we're
looking
at
is
the
device
sending
an
ipv6
packet
to
some
destinations
over
the
Internet,
and
if
there
is
a
problem
delivering
this
pilot,
for
example,
destination
is
no
longer
reachable.
J
J
And
so
my
feeling
is
that,
yes,
we
do
expect
the
ICMP
v6
message
to
be
sent
back,
and
so
we
should
be
able
to,
and
it's
likely
to
be
general
somewhere
on
the
internet
on
the
intermediate
routers
close
to
the
destination,
and
we
will
have
an
icmpv6
message
going
back
through
the
internet
to
the
Chicot
and
then
we
should
be
able
to
compress
it
and
send
it
back
to
the
device.
So
we
probably
need
to
address
that
and
provide
explanations
on
how
this
happens
and
how
efficiently
can
do
that.
J
Another
situation
is
a
user
on
the
internet,
maybe
not
aware
that
the
device
is
over
lp1,
it's
just
an
ordinary
IP
device,
and
so
the
user
wanders.
What
happens
and
how
this
this
IP
host
gets
reached
and
does
a
trace
rat
so
do
we
expect
this
to
work
and
will
the
user
aren't
get
a
response
from
his
traceroute
command
and
what
should
it
look
like?
J
So,
of
course,
as
we
increase
the
number
of
hops
and
go
through
the
the
IP
network,
we
should
get
a
regular
trace
route
answer,
but
now
for
the
last
hop
which
is
supposed
to
reach
the
IP
host,
what
will
happen
so?
Do
we
want
that
last
message
to
go
to
the
device-
maybe
not
maybe
by
default,
we're
on
the
shakur
to
respond
back
to
the
user
on
the
behalf
of
the
device,
so
we
provided
suggestions
on
that.
J
Ok,
ok
situation:
does
the
device
want
to
do
a
traceroute?
Well,
probably
not
traceroute
are
usually
done
by
human
beings
and
device
is
not
handled
by
human
beings.
So
I
don't
think
we
should
care
about
that.
So
we
should
just
say
we
will
not
expect
the
device
to
do
a
traceroute
now
the
ping
user
doing
a
ping
to
the
device.
Yes,
we
expect
this
to
happen
and
we
want
to
respond
correctly
and
accurately
to
that
and
then
does
the
device
want
to
do
a
ping
I
we're
not
sure
so
we're
looking
for
opinions
on
that?
F
And
maybe
we
will
have
also
to
generate
a
new
type
of
of
message
for
ICMP
or
a
message.
For
example,
we
may
have
something
that
saying
not
in
a
rule.
So
when
you
send
a
message
to
ship
compressor,
you
you
receive
unreachable
message
and
say
not
in
rule
on
this
way.
You
may
know
other.
The
guy
on
the
internet
may
know
that
it's
reaching
lp1
network
by
this
specific
type
right.
J
So
there
are
several
levels
of
questions
that
we
address
in
this
draft.
The
first
thing
is
this
scenarios:
do
we
want
to
consider
those
and
provide
meaningful
answers,
and
then,
if
we
do,
then
how
do
we
do
it?
And
yes,
as
long
said,
there
are
suggestion
in
some
items
that
we
think
we
want
to
address.
We
have
suggestions
to
add
new
codes
and
and
be
able
to
be
specific
on
the
fact
that
it's
a
LP
one.
C
Sketchy
well
actually
an
uncertain
oho.
It's
it's
not
really
your
problem,
it's
his
problem.
We
we
need
to
go
to
ICMP
and
be
able
to
respond
with
a
new
ICMP
that
she
cannot
compress
this
message
and
therefore
she
can
not.
This
message
cannot
be
sound
to
the
device
there's
nothing
to
do
with.
Well,
it
is
a
new
ICMP
message,
but
it's
not
it's
not
your
document.
It's
it's
really!
It's
it's
a
separate
thing.
We
need
it,
but
it's
not
you.
J
C
How
far
they
go
and
you
have
a
default
of
where
they
go
etcetera.
This
is
really
something
I
want
to
discuss
on
the
meaningless.
We
not
have
much
time
today,
but
I
would
like
the
meaning
is
to
look
at
this
piece,
because
it's
really
what
the
endpoints
expects.
What
kind
of
attacks
can
be
done?
What
happens
not
only
if
the
back
eight
years
for
this
and
ping
with
a
lot
of
data
in
it,
that
would
be
fine
to
ping.
A
PC
is
not
fine
to
bring
this
device,
it
could
be
a
dust
attack
very
rapidly.
B
Just
to
close
it
that
the
discussion
you
were
asking
for
for
interest
support
in
yes,
I
would
say
that
this
is
definitely
relevant
for
the
for
this
working
group
and
just
to
add
to
pascals
are
concerned,
maybe
more
than
putting
the
head
of
interior
working
group.
Sure
I
think.
Definitely.
This
is
an
issue
that,
once
we
mature
a
little
bit
more
that
the
discussion
here,
we
should
bring
it
up
to
interior
to
see
what
they
think
about
this
possible
change
is
2mv.
J
Right
definitely,
thank
you
so
again.
The
first
thing
I
want
to
get
from
the
audience
from
from
the
working
group
is
what
situations
watson
are
you
interested
in
and
then
will
craft
the
technical
solutions
to
those.
So
Pascal
already
mentioned
a
few
things
like
we
suggesting
we
could
introduce
new
codes
for
eco
request
and
reply
which,
frankly
of
the
code
field,
always
zero.
So
that's
one
technical
solution.
J
So
not
only
do
we
need
to
compress
its
header
which
we
can
do
recruit,
but
we
also
need
to
compress
the
the
payload
of
that
packet,
which
is
the
header
of
the
ipv6
packet
that
created
there.
So
now
we're
trying
to
compress
UDP
ipv6
header
carried
over
icmpv6,
UDP
IP,
and
so
it's
you
know
all
these
stuffs
that
needs
to
be
compressed.
So
how
do
we
do
that?
Can
we
call
shake
within
shake
or
something?
So
that's
an
interesting
question,
and
also
we
had
a
discussion
about
trace
route,
which
is
usually
used.
J
This
way,
you
send
an
ipv6
packet
to
you,
supposedly
unused
UDP
port
to
generate
an
error
at
the
destination,
and
so
now
we
sent
that
message
to
a
device
over
the
lp1
and
we
reach
a
shake
compressor
on
the
way
to
the
device
and
the
ship.
There's
no
check
rule
to
match
that
UDP
port
because
you
intentionally
used
an
unused
port,
and
so
what
happens
you
know
originally
the
ship
draft
said
if
you
find,
if
you
receive
a
packet
which
has
no
rule
for
it,
you
drop
the
packet.
J
So
you
won't
get
the
answer
on
the
trace
route.
Now,
I
think
the
new
oceans
is,
if
it
doesn't
Arul,
then
you
send
it
uncompressed
to
the
device.
So
do
we
want
that
to
happens
and
an
uncompressed
a
packet
for
an
a
new
sport
just
to
get
the
error
message
back
from
the
device?
Probably
not
so
we
need
to
find
a
solution
for
that
as
well.
There's.
K
J
They,
there
is
a
little
overlap
in
the
eco
reply
and
echo
request
message
that
you
also
described
in
your
draft
but
I
think
we
provided.
You
know
much
more
generic
way
and
again.
The
first
thing
I
want
to
do
is
enumerate
the
situations
we
want
to
cover
and
maybe
later
provide
technical
solutions.
So
if
you
want
to
join
on,
especially
if
on
the
ACO
Rico,
we
pry
an
ACO
request
messages,
you're
welcome,
but
I'm
not
interested
in
a
nd
right
now.
That
is.
B
That
foreign
enter
what
Carlos
swinging
I
just
want
to
I
guess
support
the
response
from
Dominique
I
think
that
we
had
that
discussion
in
the
past
that
we
wanted
to
focus
on
on
start
apologies,
and
we
wanted
to
have
as
little
chatty
issues
and
protocols
as
possible.
So
we
wouldn't
not.
We
would
not
like
to
bring
Andy
into
the,
especially
on
the
device
side
that
would
be
a
killer
for
this
type
of
networks.
So,
okay,.
C
So
a
call
for
interest
I
really
see
that
in
this
presentation
we
had
two
things
right:
what
is
the
behavior
for
an
ICMP
packet
not
only
on
the
device,
but
also
on
the
network
elements
which
are
wrongly
named
in
your
document?
You
have
to
follow
the
LP
one
over
of
you
in
your
flight,
something
was
called
in
an
S.
There
is
no
one
else
in
the
LP
one
overview.
It's
called
a
rotting
gateway.
C
Okay,
so,
but
we
see
we
see,
we
have
two
things
right,
so
it's
good
that
initially,
we
understand
all
the
kind
of
case
that
can
happen
in
the
radio
gateway
in
the
network
gateway
they
may
have
to
generate
new
ICMP
errors.
I
cannot
compress
this
thing
or
whatever
or
I'm,
overflowed
with
this.
Oh,
so
maybe
that
was
done
so
there's
work
that
we
need
to
figure
out
looking
at
Sheikh
et
cetera,
what
does
Sheikh
generate?
What
kind
of
new
arrows
we
have
there
and
then
turn
that
into
a
document
for
an
interior?
C
That's
one
thing
and
the
other
thing
is
really
your
draft,
which
is
what
behaviors
we
have.
How
do
we
end
all
those
messages?
Lagos
was
really
some
compression
already,
but
first
you
are
asking
the
right
question.
Architecture
is
picking.
What
do
we
do
with
these
messages?
Do
we
want
to
support
them
and
I?
Think
it's
a
it's
a
great
document
and
yes,
I
really
wish
that
we
reach
out
offer
it.
A
E
E
E
E
Chic
I
hope
that
everyone
already
knows
what
it
is.
It's
a
generic
compression
and
fragmentation
mechanism
for
targeting
caravan
networks
and
as
it
was
already
setting
the
presentations,
there
are
some
parameters
and
some
additional
information
that
needs
to
be
provided
for
each
technology
for
actually
being
able
to
use
Sheik
over
any
specific
technology
and
its
factories.
E
E
We
are
providing
information,
for
example,
about
timers.
What
are
the
appropriate
values
for
max
or
try
Scouts
and
information
for
avoid
this
world
can
be
put.
What
is
what
are
their
appropriate
sizes,
some
additional
information
for
fragmentation
and,
for
example,
the
Macau
written
a
sell,
an
asset?
E
Maybe
there
could
be
a
generic
algorithm
that
is
provided
for
all
the
technologies
and
there
might
be
some
more
appropriate
in
the
world
on
networks
that
already
have,
and
that
already
need
a
weak
algorithm
for
their
there
operations
and
I'm
sure
there
will
be
much
other
much
more
questions
to
answer
so
next
slide.
Please,
the.
E
Structure
of
the
draft
is
I
would
say
quite
traditional.
We
have
in
the
introduction
where
we
specify
the
cost
of
the
draft.
We
have
terminology
and
how
it
maps
to
the
terminology
in
the
world
one
world,
and
then
we
provide
short
overviews
of
ship
and
the
war
one
having
pointers
for
the
documents
that
describe
them
in
more
details.
E
E
Interesting
part
of
this
draft
is
actually
the
information
regarding
the
royalty
and
computational
half
IID
that
are
for
the
compression
part
of
the
ship
draft
and
for
the
fragmentation.
There
are
a
little
bit
more
things
to
be
defined
like
different
reliability,
options
that
needs
and
that
could
be
used
and.
E
How,
for
example,
what
are
the
appropriate
window
sizes
that
could
be
used
for
toplink
and
darling?
How
testing
to
work,
especially
for
the
different
device
classes,
because
in
some
of
them
we
can
receive
multiple
downlink
messages
without
an
uplink
message.
So
this
will
maybe
slightly
change
the
behavior
and
extract
risks.
E
Another
important
point
is
that
the
payload
size
could
change
independently
during
the
transmission
of
a
fragmented
packet.
So
this
is
something
we
need
to
consider
here.
Hopefully,
some
of
the
authors
of
the
draft
could
bring
some
of
their
insights.
How
whether
this
is
a
problem
and
how
to
solve
any
particular
situation
that
could
be
that
could
arise,
and
then
we
have.
E
E
Fortunately,
we
have
so
far.
A
couple
of
implementations
that
are
targeting
specifically
were
one
not.
We
know
that
for
other
technologies
there
are
also
implementations,
but
we
will
be
able
to
use
the
information
from
those
implementations
and
some
real
field
tests
to
actually
guide
us
for
good
values
of
the
different
parameters
that
we
need
to
define.
One
of
the
implementations
is
a
proprietary
one
from
a
Clio
and
there
is
an
open-source
implementation
from
Auntie
Atlantic.
E
C
Yeah
I
mean
we,
we
discussed
in
the
earlier
recharter
discussion
that
a
chick
over
foo
is
a
major
item
for
our
recharter.
So
even
if
we
cannot
really
do
that
with
our
current
charter,
or
certainly
with
the
new
charter,
that
would
be
a
core
item
value.
So,
yes,
please
stay
with
us.
Okay,
yeah!
Thank
you.
E
I
A
If
I
can
add
a
short
thing
delay
tomorrow,
so
the
context
and
stuff-
and
you
have
the
data
model
that
can
describe
this,
for
you
so
I
mean
that
that's
just
a
short
intermission
to
the
chattering
items
that
were
that
we
were
saying.
So
that's
an
excellent
question.
That's
like
a
generic
one
is:
how
does
anyone
know
about
like
a
generic
generic
properties
of
a
device
or
generic
things
that
could
happen
to
the
device?
So
this
is
like
the
big
picture
view
and
sorry
value
for
lower
one.
I
Basically,
the
the
thing
is
that
there
are
some,
let's
say,
radio
related
parameters
which
are
only
know
by
the
radio
network
and
they
signaling
that
you
have
with
a
ready
network
data.
I,
don't
see
very
easily
to
be
mapped
to
something
outside
the
radio
network.
But
then,
maybe
that's
part
of
the
discussion
in
general,
not
only
for
for
Laura
yeah.
M
Yeah
hello,
Ashley
I'm
from
coming,
so
you
have
to
be
sure
for
Laura
one
specifically
that
the
Gateway
does
not
know
the
device.
Information
is
the
Laura.
One
is
not
aware
of
the
Laura
WA,
the
Gateway
itself.
The
right.you
gateway
is
just
the
bridge.
It's
stupid.
If
it
doesn't
know
the
about
the
Laura
one
specifically.
A
So
we
should
try
to
to
use
radio
Gator
and
network
gateway.
So
I
think
that
in
this
sense
it's
more
about
the
network
gateway.
That
knows
more
about
the
radio
parameters
that
are
happening
out
there
and
and
actually
Edgar.
Thank
you
very
much
for
this
question
because
that's
actually
an
excellent
question
from
data
modeling
point
of
view
about
the
context
and
all
these
things
because
there
might
be
so
here
we
are
doing
a
course.
A
So
we
have
also
some
kind
of
architectural,
a
fish,
optimization
and,
and
the
goal
is
to
be
efficient
and
to
ease
the
life
of
integrating
these
networks
like
to
of
people
that
are
actually
managing
these
networks,
running
these
networks
and
and
and
developing
and
building
applications.
So
there
that's
actually
an
excellent
point
and.
C
There's
also
this
short
window
of
time
in
some
technology,
because
we
are
taking
Aloha
here
between
message
coming
in
and
the
nectar
arrangement
going
back
and
if
those
exchanges
are
done
from
too
far
remote,
maybe
we'll
miss
the
window
so
sometimes
of
our
satellites.
For
instance,
we've
observed
this
kind
of
behavior,
so
a
placing
and
the
ideal
thing
is
maybe
the
fragment
fragmentation
and
the
rest
of
the
compression
do
not
necessarily
need
to
be
in
the
same
box,
so
function.
Placement
is
something
that
should
really
be
addressed
in
this
document.
A
B
So
this
is
an
early
draft
that
we're
presenting
it's
mainly
an
intention
to
to
work
on
the
on
the
issue
after
they
reach
our
drink
right.
Now
that
the
draft
is
quite
early
because
we've
had
a
lot
of
discussions,
but
they
are
mainly
on
the
on
the
drawing
board.
So
we
have
a
lot
of
things
that
we
want
to
capture
in
the
document,
but
right
now
they
are
not
quite
there.
Yet,
of
course,
just
as
Cevallos
presentation,
this
one
will
focus
on
the
parameters
that
need
to
be
defined
for
technology.
B
Specific
implementations
in
this
case
see
Fox.
We
we
don't
necessarily
have
to
focus
on
different
classes
and
package
sizes,
because
it's
more
deterministic
in
the
Sig
Fox
Network
there's
only
one
class
and
one
size
of
packet,
both
from
uplink
and
downlink
I
mean
one
specific
size
for
the
uplink
and
one
for
the
downlink.
What
we
want
to
describe
is
the
network
architecture
equivalences
that
we
have
the
type
of
rules
that
we
are
going
to
consider
how
to
use
them.
What
are
the
parameters?
B
So
this
is
just
a
reminder:
it's
already
captured
in
the
overview
document,
but
from
that
architecture
point
of
view
in
the
case
of
the
Sig
Fox
Network,
there's
all
the
devices
connected
to
a
single
cloud.
So
we
have
the
controller,
which
is
basically
in
the
class
with
the
registration
authority
and
multiple
base
stations
in
the
world
that
that
provided
the
single
connectivity.
So
if
we,
if
we
consider
the
the
Schick
core
it'll,
be
most
likely
outside
the
cloud
or
in
the
cloud
with
all
the
basic
functionality
in
each
one
of
the
of
their
devices,.
B
Yeah
I
think
the
well.
That's
that's
my
last
slide
right
now
again.
What
we
are
working
first
of
all
is
on
the
on
the
on
the
compression
part
and
then
we're
going
to
focus
on
the
fragmentation
tomorrow.
We
already
are
going
to
have
a
lot
of
discussion
on
the
fragmentation
side.
We
have
done
some
some
some
studies
that
I
think
are
good
for
for
the
discussion
that
we're
going
to
have
tomorrow.
But
whoever
wants
to
contribute
to
this
work,
please
let
myself
Carlos
or
Lauren
no.
B
A
C
C
Don't
ask
me
all
the
deep
questions
keep
them
for
later
and
I
hope
that
maybe
even
while
we
don't
saw
them
on
the
mailing
list
or
will
be
presenting
more
specifically
on
LTE
and
at
the
next
meeting.
So
with
this,
some
of
you
I
hope.
Many
of
you
know
about
the
Etsy,
so
the
Etsy
has
its
headquarters
in
Santa
Paris
in
France,
and
they
are
working
on
radio
related
matters.
So
you
don't
expect
too
much
on
the
IR
layers,
but
they
are
helping
us
actually
on
how
you
can
use
the
radio
in
particular
in
Europe.
C
They
will
provide
you
the
ammonite
for
using
the
radio
spectrum
in
Europe
so
and
that
doesn't
seem
to
work
for
me.
Okay,
so
I
don't
want.
To
paraphrase
this,
what
I
want
to
insist
on
is
Etsy
is
responsible
for
the
harmonized
standards
and
how
you
use
the
spectrum
in
Europe.
So
you
will
will
talk
about
Ian's
friend
with
220,
in
particular,
for
the
subject
balance
and
that's
another
nice
standards
which
is
issued
by
HC
HC,
is
also
created.
A
group
called
erm.
C
C
Ok,
ok,
so
just
like
I
said,
there
are
number
of
types
of
document
that
Jesse
produces
of
interest.
For
us.
There
are
the
system,
different
documents,
so
system
reference
is
a
useful
document
for
other
bodies,
so
ITU
uses
at
CSR
Docs.
We
might
also
be
references
at
CSR
docs
system
reference,
their
high-level
type
of
architecture,
document
of
interest
as
well.
C
The
harmonized
standards
like
I
says
300
to
20
in
particular,
is
is
of
interest
for
us,
because
that's
where
you
define
the
things
like
the
duty
cycle
in
the
subject
balance
to
truth,
and
there
is
a
list
of
officer
ducks.
In
particular,
you
see
the
the
und
SR
Ducks
video
sub
gig,
so
it's
tier
1
or
3
4
3
5,
and
that
gives
you
how
you
can
do
a
try
narrowband
and
that's
for
interest.
That's
of
interest
for
seat
rocks
and
the
last
one
I
will
explain
it
a
little
bit.
C
C
Next
slide
go
to
tools
of
basically
paraphrasing
here.
Yes,
so
I
mentioned
Ian's
300
to
20.
There
is
another
one
which
is
of
interest,
is
Renault,
3
204
and
that
one
is
more
specific
to
the
band
above
870
megahertz.
Okay,
where
has
220
applies
to
allow
job,
and
all
of
them
are
limited
to
500
megawatts
MIDI.
What's
a
mega,
what
should
be
medium.
C
Well,
maybe
that,
and
and
and
and
the
jute,
the
three
oh
three
to
four
to
four,
as
also
some
rules
that
are
most
similar
to
what
you
do
in
the
US,
with
the
400
milliseconds
that
make
yeah
seconds
of
duty
cycle.
Okay
next
slide,
please,
and
more
specifically,
and
more
of
interest
with
us,
so
in
the
ER
MTG
28
specifically
focuses
on
on
LP
one
type
of
technology.
So
there's
three
major
activities,
one
is
on
LTM.
Energy
nd
will
be
doing
a
lot
more
than
just
looking
at
the
radio
footprint.
C
So
LT
n
is
where
our
sig
Foxy's
is
being
worked
on
LP
one
CSS,
so
there
isn't
a
so
doc,
which
is
mostly
complete
and
LP
one
CSS,
that's
that's
all
over,
and
that
will
really
tell
us
about
the
footprint
and
matching
that,
with
the
the
radio
spectrum
use,
H
and
Yaman
a
solid
and
then
there
is
a
third
piece
which
she
which
deals
with
mesh
networks.
Next
slide.
Please.
C
So
this
the
piece
which
hopefully
but
no
I-
will
expand
next
time
so
Ben,
who
has
built
a
whole
science
LightWire
for
us
on
this
tour,
to
tell
us
a
bit
more
about
what
ltn
is
doing,
and
it
is
my
hope,
but
we'll
see
if
that
works,
that
for
recharter
will
be
pointing
on
ltn
as
an
open
standard
I
supposed
to.
We
always
mention
sig
folks,
but
that's
kind
of
mixing
with
a
brand
name,
and
it's
always
hard
for
us
to
build
up
and
stand
out
and
put
brand
names
in
them.
C
So
it
would
be
actually
more
politically
correct
to
reference
the
HC
documents,
as
opposed
to
references
Brown.
So
that's
why
I
have
good
hopes
in
the
work
that
is
happening
at
LT
n
for
us
as
a
reference
and
like
I
said
when
I
will
will
explain
to
us
what's
going
on
in
LC,
and
there
are
some
slides
done
in
this
slide
where
which
which
gives
you
some
hints
about
that
next
slide.
C
One
calais,
if
you
want
to
jump
on
the
mic
on
on
any
of
them,
you're
just
a
free
write.
So
this
is
basically
the
use
cases
for
TN
go
ahead.
We
know
that
I
mean
this
really
matches
sick
folk.
So
all
you
know
about
sick.
There
is
more
than
sick
folks,
nail
TN,
but
all
you
know
about
sick
folks.
Pretty
much
applies
next
next.
C
So
the
two
on
the
right
are
synchronized
and
alpha
would
could
pick
optional
it's
time
from
GPS
conserving
the
battery
operation.
That's
an
interesting
trick,
but
it
could
pick
its
time
from
GPS.
Next
and
said,
the
reason
s
el
derecho
system,
reference
document
for
LP,
one
CSS,
which
is
really
low
as
you
can
recognize
it.
So
the
document
is
20
odd
pages
and
it
will.
It
will
show
you,
our
radio
spectrum
is
being
used
by
loja.
So
it's
it's
it's
it's
only
a
secondary
reference.
C
For
us,
our
primary
reference
would
be
low
1,
which
is
also
an
open
standout,
so
we're
happy
with
it,
but
but
the
lower
one
won't
tell
you
any
much
about
the
physical
space
what's
going
on
on
the
radio,
so
at
least
we
can.
We
can
have
that
reference
next,
so
you
recognize
the
aloha
classes
next
yeah,
the
last
but
not
least,
there
is
the
work
on
mesh,
so
Bob
and
Charlie
you're
in
the
room.
So
if
you
want
to
tell
something
about
it,
but
basically
there
is
this
work.
C
This
is
also
happening
in
TG
28
and
that
basically
looks
a
lot
like
why
son
4
I
can
see
about
it
and
then
again
my
understanding
is.
They
are
looking
at
the
radio
footprint
and
look
considering
the
the
impacts
on
the
harmonized
standards
for
it.
But
if
you
guys
want
to
participate,
know
if
you
do,
but
there
is
certainly
a
a
an
interleaf
interoperation
between
a
chi
felly
in
this
work.
C
C
It
is
considering
pretty
much
every
technology
that
we
are
working
on
in
this
base.
They
will
be
making
sure
that
we
we
get
our
own
high
standards
that
allows
us
to
use
the
radio
spectrum
as
we
need
and
in
a
fair
fashion
they
are
three
main
focus
which
correspond
to
SiC
Fox
loja,
and
why
son?
Obviously
they
don't
have
env,
IOT
and
LTM
here,
because
they
are
doing
it
as
3gpp,
but
also
even
more
Heavy
D
working
on
this
technology.
So
they
are
pretty
much
working
on
everything
we
are
working
in
this
room
on
next.
C
This
is
the
author
of
the
slides.
Actually,
the
slides
were
built
for
a
conference
which
is
happening
now,
I
think
in
London
and
Joseph
is
the
person
who
actually
wrote
it,
but
they
were
validated
by
erm
g28
and
I
got
authorization
to
present
them
to
you
today.
So
thank
you
at
sea
for
the
slides,
I'm
not
ready
to
take
any
question,
but
if
you
have
a
simpler
one,
I
could
maybe
help.
C
N
But
we
had
two
ongoing
projects
that
are
already
approved
and
we've
been
talking
about
here
in
the
IETF
I
Triple
E
aspects
from
one
of
those.
The
last
last
of
the
kind
of
the
in
process.
Amendments
is
15.4
s
which
is
titled
spectrum
resource
utilization,
and
what
that
is
is
adding
a
lot
of
management
tools
to
measure
channel
response
and
channel
characteristics
to
really
allow
a
lot
more
intelligent
application
level
based
management
of
the
channel
from
for
more
efficiency.
N
So
that's
actually
finishing
up
sponsor
ballot
and
should
be
proceeding
to
I
Triple
E
review
committee,
which
is
the
last
step
in
the
approval
process.
So
I
fully
expect
that
will
be
published,
probably
a
little
optimistic.
The
December
5th
is
the
meeting
date
for
for
the
review
committee
and
I
think
it'll
probably
be
January
sometime
when
that's
published,
so
that
will
finish
up
all
the
current
outstanding
amendments.
We
have
a
number
now,
five
of
them
I
believe
that
are
complete.
N
We
just
finished
a
revision
last
year,
which
is
15.4
2015
and
we've
opened
another
project
to
do
a
revision
called
15
that
for
2015
revision,
one
we're
just
starting
to
collect
input
on
that.
We
have
a
rollup
from
I
Triple
E
editorial
staff,
which
includes
all
the
amendments
except
s,
I
think
we're
going
that
route.
N
We've
decided
at
the
at
the
September
meeting
that
what
we
would
do
is
send
out
for
informal
electronic
ballot,
the
roll
up
that
we
have
just
to
collect
opinions
on
what
might
be
deprecated
what
needs
enhancing
was
broken
just
a
number
of
things,
rather
than
debate
that,
amongst
about
a
rather
small
group,
people
who
are
I
Tripoli
802
have
15.4
aficionados
who
regularly
attend
the
I
Triple
E
meetings.
We
are
also
sending
that
to
other
organizations,
so
that
will
be
coming
here
to
all
the
groups
that
are.
You
know.
N
We
like
like
six
low
six-man
core
six
dish
LP
when
for
commentary
you
know
so
we'll
send
that
around
the
draft
roll
up,
so
that
we
can
collect
opinions
not
just
from
those
participants
within
within
the
ADA
to
have
15
organization,
but
everywhere
else,
but
also
cited
the
ZigBee
Alliance.
So
why
Sun
to
thread
to
is
a
100
and
a
few
others?
So
the
idea
here
is
to
really
kind
of
move.
This
next
revision
on
to
something
that
is
very
strongly
relates
to
some
of
the
practical
issues
of
the
user
community
Alex
yeah.
A
N
Letter
or
be
an
official
letter
which
I
haven't
written
yet,
in
fact,
I
was
supposed
to
write
that
right
after
the
September
meeting
and
didn't
do
it.
Gary
Stubing
is
chairing
the
activity,
but
then
he
couldn't
show
up
with
singapore's
I'm,
blaming
him
for
the
fact
that
we
did
get
it
out.
But
I
didn't
write
the
letter
so
I'm
writing
a
letter.
It'll
be
sent
out
to
everybody,
probably
via
email,
there'll,
be
a
comment.
Resolution
spreadsheet.
N
B
Cs
Curtis
Mia
hi
Bob
yeah
sides.
You
know
I
miss
the
the
meeting
last
week
because
I
had
to
be
here
already
since
last
week.
But
could
you
just
give
us
a
brief
update
on
and
I,
don't
know,
I
guess
into
at
the
executive
committee
meeting
on
Friday?
Probably
you
discussed
this
bar
on
the
LP
one.
Is
there
a
letter
and.
A
N
Hang
on
second,
okay,
I've
just
gone
through
the
two
real
projects.
Beyond
that
we
have
three
new
work
items.
One
actually
is
rolling
out
of
an
interest
group
activity.
Let
me
get
to
that
last.
One
of
the
new
work
items
is
at
your
prior.
Perhaps
are
all
aware
that
there
were
some
security
issues
that
were
uncovered
in
803
dot
eleven
recently
that
created
and
facts
are
still
are
creating
a
bit
of
an
industry
brouhaha.
We
have
taken
a
look
at
15.4
I,
don't
think
we
suffer
quite
from
the
same
issues
at
8:02.
N
Dot
11
has
got
on
that,
and
but
it
just
is
a
wake-up
call
that
we
really
should
be
paying
attention
to
how
we
should
be
evolving
15.4,
expanding
its
capabilities
to
really
take
into
consideration
some
broader
set
security.
So
we
just
formed
a
study
group
called
security
next
generation
and
it's
anticipating
the
continuing
future
suggest
as
the
mission
statement.
A
N
Relating
to
fan
extension-
and
this
is
technically
an
interest
group-
but
it's
actually
working
on
advancing
a
project
request
in
its
define
yeah
enhancements
to
the
existing
15-
that
for
what
we
call
the
Sun
rises
in
15.4
G,
enabling
the
support
of
high
data
rates.
We
still
have
to
define
what
high
means
and
the
support
for
long
range.
We
still
have
to
define
what
that
means
so
those
activities
we
expect
that
also
to
be
improved
in
March.
N
We
need
to
nail
this
down
a
little
bit
more
specifically,
but
is
sort
of
building
up
the
next
case
for,
what's
currently
in
the
Sun
Phi
thing
for
smart
metering,
smart
city
applications,
then.
Lastly,
we
have
been
having
7
months
worth
now
of
an
interest
group
activity
which
is
equivalent
to
an
IETF
Bob
on
low
power
white
area,
so
that
finished
up
actually
in
September.
N
There
was
something
less
than
30
kilobits
per
second
in
license
exam
frequency
bands
unable
to
operate
the
significantly
increased
robustness
in
the
presence
of
interference
from
other
users
in
the
band
analyses
presented
in
the
LPW
in
this
group
have
shown
that
significant
performance
gains
are
possible,
so
that
activity
is
just
kicking
off.
I
think
it's
a
pretty
good
probability
we'll
be
able
to
get
a
par
written
in
January
and
Newport
Beach
and
bring
that
into
the
March
meeting
as
well.
A
Yep
so
Alexander
again
just
a
short
question
on
the
new
activities
that
are
coming
up
and
things
that
you'll
be
looking
at
or
starting
to
look
at.
Do
you
feel
that
there
are
some
things
that
we
should
consider
for
the
new
charter
that
you
know,
new
items
that
were
new
work,
that
we
should
be
thinking
of
like
at
least
start
to
look
at.
B
N
If
that's
in
the
January
time
frame,
it
literally
means
that
maybe
we
can
post
that,
as
as
a
document
an
LP
win
document
in
in
the
January
time
frame
and
get
inputs
on
that,
because
otherwise
it'll
move
pretty
quickly
after
that.
So
if
we
can
post
that
and
maybe
get
comments
via
the
email
list
which
I
know
you
guys
are
very
want
to
do
so
that
would
be
very
helpful
and
we
can
incorporate
those
in
the
March
the
March
meeting
and
then
move
that
forward.
Yeah.
B
And
no
I
guess
my
comment
again
from
from
participating
in
the
group.
Most
of
the
the
results
from
the
study
pointed
towards
I
would
say
three
main
characteristics
of
this
potential
amendment.
One
of
them
was
star
topology,
the
second
one
was
frequency
hopping
and
the
third
one
was
forward
error.
Correction
right,
so
I
guess
that
from
that
point
of
view
the
impact
would
be
another
significant
at
higher
layers
like
at
Mac,
but
still
just
just
heads
up
of
what
what
the
potential
part
will
show
up
and
I
don't
know
it.
N
C
No,
so
we
we
encourage
people,
since
it's
a
result
of
this
meeting,
to
submit
documents
on
Chicago,
foo
and
bar
over
shake.
Now,
that's
the
new
thing.
So,
if
you're
interested
in
applying
certain
flows
over
shake,
it's
cool
to
start
working
on
a
bar
over
shake
and
we'll
see
how
this
document
can
be
incorporated
in
your
chapter
work
that
we'll
be
doing
so
that's
one
and
the
second
is.
C
A
A
So
this
was
a
basically
the
missing
piece
for
continuing
the
the
shake
over
a
co-op,
yeah
chic,
the
co-op
chic
draft,
and
thank
you
very
much
Karsten
for
this
I
think
this
is
a
great
start
and
we
will
say,
be
setting
up
the
registry
as
you
suggest
it,
so
that
will
be
perfect
and
yeah.
Thank
you
very
much
about
this,
and
another
point
is
that
we
were
really
happy
with
the
hackathon
during
the
past
two
IGF.
A
So
it
would
be
really
good
if
on
the
next,
so
on
the
next
idea,
we
will
be
doing
a
hackathon
so
be
aware
of
this
from
from
now
and
we'll
be
looking
into
having
intra
parole
fragmentation
like
the
full
shake
that
the
full
the
full
package
right,
be
there
if
you
with
your
implementation
of
shake
with
the
compression
and
the
fragmentation,
hopefully
by
that
time,
we'll
have
some
input
on
the
shake
of
a
few
documents
so,
and
this
will
serve
as
an
input
for
photo.
She
cover
full
documents.