►
From YouTube: LPWAN WG Interim Meeting, 2021-01-19
Description
LPWAN WG Interim Meeting, 2021-01-19
A
So
this
is
the
second
train
of
the
fp1
working
group
for
this
year.
2021
welcome
to
the
group.
This
is
an
official
ietf
meeting,
so
the
best
practices
apply
in
particular
best
practice
regarding
patents
and
ipr.
So
if
you're
aware
of
any
ipr
that
is
disclosed
discussed
today,
please
let
us
know
during
the
meeting
or
tell
the
chairs
at
the
end
of
the
meeting.
A
We
are
recording
the
meeting,
so
the
minutes
will
be
published.
They
will
be
available
to
all
so
we'll
so
recording
in
a
minute.
Links
will
be
given
on
the
minutes
with
the
minutes
of
the
meeting
on
the
mailing
list
and
the
attendance
will
be
recorded
from
the
webex
attendee
list.
So
if
you're
attending
sharing
a
desktop
with
somebody-
and
your
name
is
not
sharing
here-
please
let
us
know
and
go
to
the
notes
on
the
link
that
was
given
on
the
chat
and
add
your
name
to
the
blue
ship
list.
A
A
A
A
A
And
then,
because
of
our
attendance
from
americas,
I
also
requested
to
make
it
late,
but
I
guess
that
every
group
with
an
important
population
from
america
will
also
ask
for
something
like
that.
That
won't
help
a
lot,
but
that's
the
way
I
asked
for
this
building
and
the
next
discussion
will
be
a
sheikh
of
our
of
our
one.
B
A
C
C
We
have
the
technology
specific
documents,
we
have
the
yang
data
model
coming
in
the
oem
and
we
other
other
ideas
on
the
table
like
how
do
we
do
shakeover
ppp?
So
these
are
like
give
different
bricks
and
from
the
co-op
draft
there
were
a
lot
of
a
lot
of
questions
about.
Okay,
how
these
or
how
do
these
all
these
things
work
together.
C
So
how
are
context
provisioned,
you
know,
and
and
during
the
discussions
with
so
there
were
olivia
and
we
who
had
some
questions
about
in
the
working
of
flora
one
you
know
how
do
we,
you
know
reset
some
parameters
or
how
do
we
re
recalculate,
the
the
the
id
and
error
handling
and
all
that
right
and
and
these
things
in
our
opinion,
they
need
to
be
handled
like
in
a
they
need.
They
need
to
be
a
store
right.
C
C
C
So
with
no
further
ado,
let's,
let's
go
to
the
first
element,
is
what
we
learned
from
the
shecos
core
and
the
co-op
and
all
the
discussions
with
the
with
the
isg
and
with,
and
we
think
the
need
to
go
further
in
the
security
considerations
right
well.
The
first
thing
is
that,
as
we've
always
been
saying,
shifts
can
be
on
different
levels.
C
Well,
that's
an
example
right
for
us
or
very
specific,
for
example,
we
can
apply
shake
before
the
comp
before
the
encryption
and
after
the
encryption,
so
we
have
chic
on
all
these
all
these
places
and
so
that
architecture,
the
way
we
provision
the
context
and
all
that
you
know
that
needs
to
it-
needs
to
fit
these
different
use
cases
right
or
or
we
may
decide.
Well,
you
know
for
one
well
for
one
sheet:
we'll
have
one
architecture
from
the
other
will
have
different
architecture
right,
but
we
need
to
to
spell
this.
G
A
F
C
F
H
C
C
Okay,
oh
moved
closer
to
the
wi-fi,
so
so
we
have
right
this
these
different
instances.
So
the
first
thing
is
basically
the
boundaries
are
not
explicitly
on
the
osi
layers
right.
We
can
have
one
cheek
instance
that
is,
for
example,
compressing
ip
and
udp,
plus
the
fragmentation,
then
another
instance
working
on
oscar
outer
and
another
in
oscar
inner.
So
you
see
that
there
could
be
completely
different
distances
on
on
the
same
level
on
the
same
layer
from
the
osi
perspective,
or
it
could
be
the
same.
C
Shake
instance
doing
all
that
right
so
that
that's,
but
let's
say
that
okay,
they
can
be
under
different
layers,
and
each
of
them
have
potentially
a
set
of
rules
that
are
different
and
they
can
could
be
managed
by
different
entities.
So,
typically,
if
we
have
the
network
there,
it
can
be
managed
by
one
by
one
entity
with
one
set
of
rules
and
the
the
application
layer
check
can
be
managed
and
there
could
be
rules
managed
by
handled
by
different
entities.
C
So
you
know
that's
something
that
I
think
that
we
need
to
have
in
mind
when
we,
when
we
design
the,
when
we
define
the
architecture
and
let's
start
really
simple
right,
let's
start
really
simple
and
say:
okay,
what
are
the
entities?
Well,
we
have
the
the
device
side
and
then
we
have
the
the
core
network
side.
Here,
I'm
not.
C
We
are
not
talking
specifically
about
you,
know
this,
which
gateway
on
which
level
right,
we
just
say,
okay.
Well,
there
is
the
device.
There
is
the
the
core,
the
application,
and
then
you
have
the
compression
and
fragmentation
and
reassembly
and
and
and
they
compared
and
there
are
the
set
of
rules.
So
the
r
is
the
set
of
rules
and-
and
you
know
like
the
compressors
and
like
the
check
instances,
are
reading
the
rules
from
the
from
the
rule
set.
C
Oh
yeah,
so
that's
a
good
question.
It's
just
because
that's
like
a
very
high
level
representation,
so
it
it's
this.
Basically
that
could
that
should
be
considered,
or
so
it's
the
device
talking
to
the
core
like
to
the
network
gateway
or
it
could
be
the
application
on
the
device.
So
let's
say
the
the
os
core,
the
co-op
score
talking
to
the
application
that
is
in
the
cloud.
C
H
C
C
Okay,
let
me
highlight
her
okay,
so
here
the
of
course
the
the
the
this
is,
the
shape
of
the
compressor
right.
It
reads
the
rules
from
the
from
the
rule
set,
and
then
there
is
this
entity
that
we
may
say
that's
a
rule
manager
and
that
rule
manager,
you
know,
has
it
it.
It
is
the
one
that
this
entity
that
goes
and
and
reads
and
creates
and
updates
or
deletes
rules
from
the
rule
set
that
are
that
are
in
the
in
the
rule,
store
and
full
manager.
C
C
It
so
the
rule
manager
in
that
point.
In
that
perspective,
so
two
rule
managers.
They
they
work
in
pairs.
So
if
we
say
that
the
device
and
the
core
or
device
in
in
the
in
the
cloud
you
know
there
are
rule
managers
on
both
ends
and
high
level
requirements
or
high
level
design
choices,
are
you
know
we?
We
have
the
the
the
shake
model
representation
done
in
yang
in
the
protocol
from
the
protocol
selection,
we
can
have
many
different
protocols.
C
The
core
conf
is
the
one
that
seems
like
the
native
one,
because
it's
young
native
it
uses
co-op.
It
uses
a
c-bor,
so
it's
really
quite
efficient,
but
there
be
other
there
could
be
others
like,
as
we
have
the
example
with
the
pvp
draft
there.
You
know
we
have
the
the
the
the
protocol
for
session
negotiation
that
that's
used
between
the
two
entities
that
could
be
looked
at
as
as
rule
session
managers
like
rule
managers.
C
C
So
if
we
are
working
on
a
network
level
check,
these
can
be
a
local
ipvc
address
of
v6
addresses
or
if
we
are
looking
on
an
application
level
check,
then
that
can
be
global,
ipv6
addresses
and
in
that
way,
of
course
they
can
be.
You
know
they
can
communicate
over
ip
over
the
the
shaky
instances
and
just
a
short
note.
In
some
cases
these
could
be
collocated.
They
can
can
reuse
the
application
level
protocol.
C
So,
for
example,
if
you
have
a
application
level
shift
that
compresses
co-op
traffic,
you
know
for
some
co-op
applications
that
could
be.
You
know
that
there
could
be,
it
could
be,
the
the
rule,
manager
could
reuse
the
same
co-op
server,
and
so
it
can
have
like
a
logistical
endpoint
that
can
be
that
can
be
used
as
as
communication
between
the
two
and
on
the
secure
security
wise.
So
this
is
how
both
rule
managers
are
able
to
communicate
to
each
other
and
on
the
security
on
a
security
wise.
C
Well,
there
is
a
choice,
of
course,
but
we
can
simplify
the
things
and
say
well
on
the
network
level
chick.
If
the
layer
2
encryption
and
the
layer
2
security
is
deemed
sufficient,
then
maybe
we
don't
need
additional
security
or
you
know
we
can
say
well.
We
need
end-to-end
encryption
or
end-to-end
security
for
application.
As
for
application
level
shake
as
with
you
know,
oscar.
C
It's
well
that's
about
the
it's
about
the
protocol.
Let's
say
it's
about
the
protocol
that
allows
the
two
rule:
managers
to
communicate:
okay,
so
to
secure
them
to
secure
that
traffic.
Okay,
then
there
could
be
additional
yeah,
but
here
is
it
this
part,
and-
and
in
that
last
point
I
think
I
already
mentioned
you
know
the
rule.
C
The
measure
protocol
goes
through
the
sheet
compression
and
the
compression
could
go
through
the
shake
compressing
the
compressor-
and
let
me
just
give
you
an
example,
so
this
is
an
example
of
a
network
level
shift.
So
here
we
have
both
ends.
Let's
say
that
the
left
hand
side
is
the
device
and
the
right
hand.
Side
right
is
the
core.
C
Here
we
have
the
sheet
compressors
and
the
compressors,
and
here
we
have
the
lpn
link,
so
the
application
is
talking
with
through
the
ip
stack
through
the
chic
instance
here
over
to
the
other
side
through
the
ip
stack
to
the
other
application
site.
Well,
that's
really
nice,
where
the
sheet
compressor
and
the
compressor
you
know,
uses
the
rules
that
are
in
the
rule
store
and
now
what
we
have
is
that
the
rule
managers
can
communicate
through
their
management
protocol.
C
For
example,
core
con
over
earth
core
can
communicate
to
each
other
and
that
communication
actually
could
go
through.
You
know,
as
a
as
I
said
before,
you
know
if
they
are
on
the
same,
so
if
the
network
level,
so
that
they
could
be
using
link
local
ipv6
addresses,
so
each
of
them
has
a
link
locally.
At
six
address,
these
ipv6
addresses
can
be
discovered,
can
be
provisioned
in
advance
can
be
defined.
You
know
to
be
generated
in
in
a
static
in
a
static
way.
C
You
know
I
mean
the
the
link
offices.
Of
course
they
are
known,
but
the
the
destination
port,
and
all
that
you
know
all
the
they
run.
The
viewpoint
can
be
fixed,
and
so
you
know
the
first
rule
manager
coming
x
over
the
ip
stack.
Then
it
goes
over
the
shake
instance
all
the
way
to
the
other
ip
stack
and
then
up
to
the
room
manager.
C
So
they
have
like
this
indication
the
protocol
exchange
between
the
two
rule
managers,
and
then
I
mean
core
conflicts
like
it's
like
netcom.
You
know
you
can
have
all
the
configuration
all
the
all
the
operations
that
are
necessary
there
and
then
the
rule
managers
can
perform
cred
operations
to
the
to
the
rule
stores
on
both
on
both
sides.
C
C
A
A
F
A
C
C
C
Exactly
exactly,
and
and
yes,
yes-
and
this
is
where
this
is
where
we
were
discussing-
and
this
is
where
the
point
that
you
know
maybe
when
it
shows
up
the
device
it
can
send
an
operation
to
the
other
manager
to
say
hey.
Well,
you
know,
go,
do
a
dns
operation
or
you
know
fetch
the
the
the
rules
from
from
from
from
that
url.
A
H
B
A
The
compressor
will
find
somehow
a
url
url
of
the
room
manager
where
the
room
edger
are
positioned.
So
it's
not
really
the
room
manager,
it's
the
roof
itself
on
the
url.
So
so
there
will
be
a
relation
between
a
server
which
provides
the
rules
and
the
rule
managers
on
both
sides,
which
you
know
basically
the
left
side,
discovers
the
device.
D
A
Fetches
the
rules
from
the
url
from
the
rule
manager
and
then
fetches
the
rules
themselves
from
the
url,
and
then
it
tells
you
know,
as
it
creates
the
ppp
session
in
in
the
ppp
headers,
where
I
describe
the
compression
it
tells
where
the
url
is
for
the
compression
rules,
so
that
the
other
side
can
go
and
fetch
the
same
rules
at
the
same
url,
and
the
expectation
is
probably
that
your
hull
can
be
local.
For
instance,
if
you
have
a
control
loop,
you
know
inside
the
factory
network,
not
necessarily
connect
that
to
the
internet.
F
A
C
A
A
There
is
this
expectation
that
there
are
two
entities.
One
is
really
the
logic
which
says
you
know
you
pick
those
rules
and
the
other
piece
is
just
the
main
storage
of
these
rules.
Like
the
repository
of
the
books,
it's
kind
of
separate
and
the
cool
thing
about
having
your
house
for
the
rule.
Is
that
your
hand
that
you
know
it's
unique
and-
and
you
want
to
be
sure
that
both
aliens
will
use
the
same
data
for
compression
and
decompression,
and
they
don't,
you
know,
use
the
different
rules.
A
C
C
Exactly
exactly
so
so
yeah
I
mean
we
really
wanted
to
get
the
the
ball
rolling
because,
as
I
said,
we'll
be
talking
about
this-
and
we
got
a
lot
of
comments
from
the
for
the
co-op
shook
over
co-op
sorry,
co-op
oversight,
draft
that
were
basically
saying,
hey
guys.
How
do
you
do
that?
How
do
you
do
that?
C
D
So
in
this
case
a
sheet
architecture-
and
I
was
a
little
confused
about
what
exactly
we
were
saying,
because
we
had
already
presented
an
architecture.
Now,
it's
clear
to
me
that
it's
two
different
things,
but
probably
there
should
be
some
some
explanation
or
some
mapping
explaining
how
that
was
a
basic
arc
network
architecture,
and
this
one
is
expanding.
C
A
It
it
really
depends
on
what
we
want
to
put
in
this
document,
but
I
believe
we
we
need
architecture
and
framework.
It's
usual
now,
I'm
seeing
that
in
many
places,
but
you
need
the
architecture
to
position.
The
objects
like
you
need
to
describe
what
this
rule
manager
is
about.
If
we
have
a
rule
store,
we
need
to
explain
what
it
is.
Then
we
need
to
position
which
object
talk
to
which
object
and
when
and
all
this
is
architecture.
A
Yeah,
yes,
and
then
once
we've
done
that
we
can
explain
those
things
in
more
details
which
could
be
framework.
But
there
is
an
architecture
piece,
that's
missing
and
I
was
talking
to
alexander
and
if
you
remember,
or
maybe
you've
seen
it.
Maybe
not.
We
published
a
document
in
the
ieee
and
both
ideotriple
unity
have
journal
pretty
much
interval
about
the
time
when
we
formed
this
working
group
and
we
actually
described
the
architecture
in
there.
G
A
I
believe
that
the
text
or
the
general
you
know
we
need
to
adapt
it
to
because
things
have
changed,
but
we
need
to
to
bring
that
back.
We
need
to
explain,
for
instance,
the
discussion
about
where
you
have
a
crypto:
you've
got
a
separation
of
endpoints
and
you've
got
separation
of
rules,
etc,
etc.
This
is
architecture.
This
is
not
framework.
A
So
we
we
need
that
and
it's
not
in
87
24
I
mean
that's,
that's
missing
and
that
really
caused.
You
know
a
lot
of
hassle,
in
particular
for
the
co-op
document
where
actually
it
was
one
ist
review
which
pointed
out
that
having
those
two
different
stages
of
check
was
a
major
architectural
point,
and
since
we
didn't
have
an
architecture,
it
didn't
show
anywhere.
D
A
A
A
We
don't
want
to
have
two
documents
either
it's
very
hard
at
some
point
to
say:
oh,
this
is
purely
architecture
and
that's
purely
framework,
that's
very
hard,
and
we
don't
want
to
throw
two
documents
at
the
asg.
On
the
other
hand,
we
want
to
have
this
one
early
enough,
because
it's
already
too
late,
I
mean
we
already
suffered
in
some
reviews
because
we
did
not
have
it.
A
C
So
if
you
have
you
know,
we
are
really
welcome
to
having
other
use
cases
or
or
or
points
you
know
to
include,
and
the
point
would
be
and
also
have
like
the
in
this
document
has
at
least
pointers
or
to
to
give
the
big
picture
as
much
as
as
we
can,
of
course,
with
to
the
details,
but
at
least
the
big
picture
of
okay.
How
are
all
the
questions
that
we
that
we'll
have
for
for
some
time?
You
know
how
are
they
handled
and
when
a
device
goes
into
a
network?
C
A
I'm
sorry
since
we're
at
it
and
we're
talking
to
edgar
edgar.
Can
I
have
a
quick
question
to
you
because
I'm
happy
to
see
you,
but
we
we
kind
of
had
to
do
from
last
time
to
find
some
help
to
quote
and
quote
replace
you,
because
we
we
thought
that
you
were
no
more
with
us.
So
I'm
very
happy
to
see
you
and
I
wonder
if
you
you
plan
to
have
time
to
work
with
anna
on
the
5g
document
or
or
if
it
was
just
by
chance
that
we
had
you
today.
H
Well,
the
plan
is
that
I
I
will
try
to
help
bring
up
the
latest
things
missing.
Hopefully
I
I
can
continue.
I
it's
not
yet
fully
agree
with
my
manager,
but
then
I'm
also
looking
for
some
support
from
the
product
people
to
see
if
we
can
actually
raise
their
profile
of
shake
in
general,
so
maybe
try
to
see
if
we
can
bring
it
to
3gpp
and
so
on,
because
they
haven't
been
so
far
much
interest,
but
then
now
that
there
are
some
concrete
use
cases
for
it,
then
maybe
the
story
will
be
different.
G
G
A
G
D
A
E
A
A
C
No,
no,
it
was
it
was
that
so
we'll
be
working
on
the
architecture
document,
and
we
consider
this
to
be
to
be
our
our
job
as
a
as
chair
from
the
start
with
pascal-
and
the
point
would
be,
you
know
that
it's
it
takes
all
the
considerations
for
for
the
working
group.
So
please
don't
hesitate.
You
know
to
give
your
feedback
and
and
to
actively
propose
or
criticize
the
the
text
as
it
is,
and
and
yes
so
that
there
was
maybe
a
final
final
thing.
C
A
G
G
G
I
It's
not
so
much
about
header
or
data
by
the
way.
It's
simply,
if
you're,
using
something
like
gzip
or
anything
which
is
this
compression,
then
you
are
open
to
something
because
you
exchange
dynamic
dictionaries,
kind
of
which
is
not
the
case
with
so
this
attack
does
not
fly
yeah,
so
it's
basically
conforting
the
message
that
yeah
this
attack.
That's
not
a
public.
G
H
A
A
But
but
fact
is
it's
much
better
that
you
have
published,
because
you
can
basically
send
him
in
your
response.
Gary
is
the
deaf
and
you
give
him
the
url
of
the
diff
or
something
you
say,
publish
17.,
and
that
was
just
for
you.
So
all
the
gifts
that
are
there
are
for
you,
something
and
and
then,
when
he
processes
that
that
would
be
a
lot
easier
and
faster
for
him,
because
he
has
to
reload
the
full
context
of
his
previous
review.