►
From YouTube: IETF-LPWAN-20220222-1500
Description
LPWAN meeting session at IETF
2022/02/22 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
As
usual,
we
we
will
give
a
few
minutes
for
the
late
joiners
to
arrive
and
we
will
start
the
session
around
five
past
the
hour.
B
I
got
some
larsen
when
you
guys
were
talking.
B
B
Okay,
anyway,
so
I
guess
it's
it's
time.
Do
you
want
me
to
do
the
intro
this
time?
Relax
or
do
you
want
to
do
it?
B
No,
no
go
ahead,
go
ahead,
okay,
so
this
is
an
official
lp1
working
group
intermeeting
and
so
welcome
you
all
and
as
usual,
since
this
is
an
offshore
meeting,
we
have
to
abide
to
not
well
so
they're,
not
well,
as
the
usual
pattern
type
pr
policy
whereby,
if
you're
aware
of
any
ipr
on
something
which
is
being
discussed
today,
please
disclose
that
ipr
during
the
meeting
or
let
the
chairs,
know
after
the
meeting
and
then
please
be
aware
of
all
the
other
best
practices
that
we
have
at
the
atf,
including
entire
husband.
B
So
usually
remember
a
reminder:
the
minutes
are
being
captured
and
the
link
is
given
here.
It's
always
safe
for,
in
particular,
if
you,
if
you
speak,
that
you
visit
the
minutes
as
they
are
being
taken
to
ensure
that
what
you
wanted
to
express
is
effectively
captured.
B
Anyone
is
welcome
to
contribute
to
the
minutes
at
any
time.
So
it's
very
useful
thing
to
open
this
link.
B
If
you
don't,
if
you
have
a
problem
with
that,
please
refrain
to
to
speak
and
the
attendance
is
automatically
captured
since
you,
you
logged
in
the
mythical
meeting
going
through
the
ietf
data
tracker
account,
so
your
presence
actually
locked,
but
the
agenda
today
we'll
have
a
little
bit
more
time
than
usual
on
the
administrative
yeah,
because
we
want
to
discuss
ietf
113,
so
we'll
see
where
we
are
and
and
how
much
time
we
have.
Then
we
have
15
minutes
by
anna
on
the
progress
on
the
nbiot
document.
B
I
understand
that
there
is
a
very
good
progress
there.
So
now
you
you'll
be
speaking
at
for
20.
420,
and
then
we
have
a
presentation
by
carless
about
the
chicaner
compression
over
a
2015.4
on
the
role
of
the
dev
and
device
and
application
layers.
B
That
would
be
also
15
minutes
and
we
have
a
little
bit
of
time
laurence.
You
did
not
send
slides
or
request
a
slot,
but
still
I
thought
it
was
good
to
have
a
little
sync
on
when
you
are
on
the
data
model
and
one
carlos
told
us
that
you
would
not
be
there,
but
if
there
is
any
status
after
my
review
on
the
compound
act
document,
it's
always
welcome
as
well.
B
One
little
thing
about
the
compound
hack
is,
I
initially
was
the
shepherd
for
it,
but
we
we
might
have
to
switch
so
so
we'll
discuss
that.
But
at
least
I
prefer
the
review
so
so
this
that
match
is,
is
still
valid
for
for
answers.
So
if
there
are
authors
of
the
component
and
the
one
galaxy
is
not
there,
but
please
consider
the
review.
B
We
had
a
good
number
of
action
items
last
time
so
alexander,
there
were
two
things
on
your
side,
and
I
know
the
second
one
has
been
done
for
the
first
one.
I've
not
seen
you
call
for
adoption
for
the
om
draft.
Did
I
miss
something.
C
No,
so
the
point
was
so.
The
first
thing
is
that
we
checked
if
we
have,
if
it
was
adopted
and
actually
dominic
did
the
the
lookup
and
he
didn't
find.
C
I
mean
we
didn't
actually
call
for
adoption
of
the
document
and
what
we
said
was
that
he'll
need
to
integrate,
so
that
here
is
the
the
the
team
received
some
remarks
and
he
needed
to
integrate
them
and
submit
as
dash
o2
and
then
call
for
adoption
of
that
document.
C
But
I
don't
think
that
I
saw
this
one
submitted.
So
here
probably
the
point
would
be:
do
we
call
for
a
dash
for
for
the
current
one
to
be
adopted
and
then
integra?
Of
course,
the
the
the
modifications
can
be
integrated
later,
because
dominic
is
going
to
be
quite
heavily
loaded.
I
think
in
the
next
week.
So
you
know.
B
B
At
the
time,
it's
not
the
most
important
thing,
but
then
there
was
a
to-do
for
me.
Actually,
the
shepherd
review
for
the
compound
act
which
which
I
did
it
might
or
might
not
be
the
shepherd,
but
it's
actually
a
review.
So
I
think
it's
good
dominique
is
not
with
us.
B
He
was
to
richard
if
florence
changed
the
data
model
addressed
the
issue,
so
we
have
to
to
check
that
on
the
mailing
list
and
republish
the
oam
dock
and,
like
you,
have
not
seen
it.
Actually,
it's
not
republished.
So
we'll
have
to
see
with
dominique
about
those
issues.
B
Laura
you
were
to
to
republish
the
data
models.
Maybe
you
were
waiting
for
dominic
to
confirm
something,
because
we
said
we
wanted
to
work
with
glasgow.
E
It
has
a
new
date
on
it,
so
it's
easier
to
recognize
that
it's
a
new
one
and
I
made
all
the
edition
to
be
compatible
with
rfc
format.
This
means
that
all
the
lines
are
short
enough
not
to
go
after
the
last
column.
So
it's
so
it's
compiled
without
any
error
messaging
right
now
so
now.
The
next
step
is
to
take
the
draft
and
to
do
copy
and
past
to
put
them
in
into
the
draft
and
add
to
one
or
two
comments
for
the
new
things
that
have
been
added.
So
it's
not
that
difficult.
B
If
you
manage
to
publish
the
draft
to
the
data
tracker
within
you
know
this
week
or
very
early
next
week,
I
guess
we
can
still
call
for
one
group
last
call
with
the
target
date
of
the
of
tuesday
of
the
atf,
which
is
our
meeting
okay
up
to
you.
Otherwise
we
will
start
the
worker
class
call
at
the
ietf
and
we'll
complete
it
one
more
thing:
okay
and
laura,
you
discussed
that
you
would
suggest
a
hackathon
for
the
atf
and
the
I
guess
on
the
data
model.
E
B
Okay,
that
that's
really
cool
what
group
status,
so
we
alexander
effectively
edited
the
milestone.
So
now
the
oam
document
is
expected
at
the
very
end
of
this
year
and
the
rest
is
pretty
much
the
same
as
it
was
still.
We
have
remember.
We
have
the
sigfox
document,
which
was
which
was
expected
some
time
ago,
and
it's
still
not
there.
It
was
kind
of
blocked
by
the
component,
but
our
copper
deck
is
mostly
done
so
hopefully
the
fox
document
can
can
go
for
less
call
as
well
very
soon.
B
So,
what's
what's
new
on
the
documents,
we
have
two
new
publications,
so
the
ndiut
that
now
we'll
talk
about
next
and
version
three
of
the
component,
which
is
what
juan
carlos
promised
us
and
effectively
one
goddess
has
done
the
old
new
text
edition,
as
as
we
suggested.
So
that's
why
I
could
perform
my
review
on
it.
So
the
review
has
been
disclosed
on
the
mailing
list
and
we
are
waiting
for
for
commands
and
then
there
is
oh
that's
my
mistake.
I
thought
was
not
there,
but,
yes,
it
is
effectively.
B
So
so
so
so
I
mean
that
that
should
be
good
enough
alexander
to
call
for
adoption.
B
F
B
B
So
first
thing,
if
you
plan
to
attend
remotely,
please
be,
and
from
the
u.s
in
particular,
please
be
aware
that
the
us
will
have
shifted
in
summer
time,
but
not
europe.
This
this
week
and
the
week
before
itf
are
the
two
weeks
which
are
you
know,
always
weird
every
six
months,
because
the
us
shift
before
europe
does
so.
Europe
will
still
be
in
utc
plus
one.
So
it's
going
to
be
12,
00,
utc,
1300,
utc,
plus
one
okay
and
it's
gonna
be
29,
21,
0
0,
I'm
sorry,
the
other
way
around.
B
Five
a.m.
I
guess
in
pacific
time
and
eight
eastern
so
be
aware.
You
know
it's
just
it's
one
hour
or
less
time
shift
between
north
america
and
europe.
That
is
usually.
B
So
basically,
I
I
just
wanted
to
know
in
the
small
group
that
we
have
here.
Do
we
have
a
lot
of
people
who
plan
to
be
physically
present
at
the
atf
or
is
it
like?
People
expect
to
be
remote,
as
we
did
recently
for
the
recent
years.
C
C
B
Because
my
current
plan
alex
was
not
to
be
physically
there
either,
but
I
I
really
thought
that
you
would
be
actually
a
discoveries,
so
yeah
I'll
check.
Maybe
that
would
be
a
reason
for
me
to
eric.
I
guess
you
you
guys
expected
that
at
least
one
of
the
two
chairs
would
be
present.
D
I
was
hoping
for
this,
and
basically
it
looks
like
lauren
is
coming
so
lauren,
maybe
or
whoever
steps
forward,
but
getting
somebody
in
the
room
plus
me
because
I
will
be
in
the
room.
Basically
do
the
welcoming
and
a
few
words,
because
I
think
it
is
important
to
have
a
human
being
in
the
room
as
well
in
labor
meetings.
So
I
said
the
name
of
lauren
because
he
replied
the
first
with
I
will
come,
but
anybody
can
do
it
and
the
chair
needs
to
agree.
Of
course,.
B
B
B
Okay,
thank
you
very
much
so
I'll
see
reiki.
I
might
discuss
again
see
if,
if
I'm
coming,
but
the
plan
was
still
not
to
come,
so
in
that
case
the
horse
playing
the
role
would
be
very
appreciative.
B
Yeah,
we
will
send
an
official
call
for
presentation
for
this
meeting
be
aware
that
we
have
asked
for
only
one
hour.
You
you,
you
might
have
seen
that
the
slots
for
two
hours
were
scarce
and
people
were
asked
to
to
strongly
justify.
If
they
really
wanted
two
hours,
we
didn't
think
we
we
would
consume.
B
We
would
really
use
well
two
hours,
so
we
will
be
calling
for
10
to
15
minutes
max
slot,
depending
on
on
which
document
that
is,
if
you
ask
so,
we
will
be
asking
you
know
if
you
want
to
present
physically
or
remotely
and
what
kind
of
duration
you
expect
and
we
might
have
to
shorten
your
direction,
the
duration,
certainly
it
will
be
below
15
minutes,
so
the
the
meeting
will
be
in
grand
park
hall
2,
and
this
could
be,
like
I
said,
1
pm
time
noon.
Utc.
B
And
with
this
that's
the
end
of
the
slides
and
we'll
keep
the
aub
for
later
so
now
the
the
the
floor
is
yours.
If
you
remember
you,
you,
you
have
to
click
on
the
slide
share
on
the
top
left
of
your
screen.
You
see
where
there
is
the
aired.
B
B
F
Okay,
thank
you.
So
we
have
finished
to
make
all
the
modifications
to
the
nv
iot
configuration
or
this
version.
So
next
slide
is
here
and
the
first
thing
we
have
done
is
we.
We
eliminate
the
delay,
tolerant
problem
that
we
think
we
have
to
do
a
new
document.
That's
what
we
have
discussed
one
more
ago.
I
think
so.
F
We
will
create
a
new
document
for
this
big
frames
to
be
sent,
and
so
we
finish
with
all
the
needs
and
the
modifications
for
the
configuration
of
cheek
fragmentation
and
compression
over
the
nv
iot
network,
and
so
the
the
new
thing
in
this
version.
Seven
is
that
we
make
the
rule
id
space
variable
size
for
compression
and
for
fragmentation
too.
F
That's
the
only
modification,
the
two
big
modifications
we
have
done
and
we
think
that
we,
we
are
ready
and
we
are
ready
for
for
this
last
call,
but
perhaps
we
need
some
reviewers
before
or
late
over.
I
don't
know
if
we
make
the
last
call
and
we
get
reviewers
or
if
we
have
reviewers
and
we
made
a
less
call.
B
Actually,
we
now
find
one
reviewer.
We
will
do
a
deep
review.
Just
you
know
to
to
extract
the
some,
maybe
typos,
and
if
there
is
a
big
bag
before
everybody
reports
it.
So
it's
kind
of
nice
to
have
one
deep
review.
Would
there
be
a
volunteer
in
this
call
for
doing
that?
Deep
review.
B
B
Do
you
even
I
see,
come
in
and
go
out
to
ask
which
would
be
the
deadline
for
this
review?
F
B
B
F
B
Session,
so
we
can
effectively
discuss
them
during
the
session,
let's
read
it
so
alex,
and
what
do
you
think
we
careless
provides
this
review
by
atf
at
the
etf?
We
we
look
at
the
commands.
We
consider
if
the
document
is
ready
based
on
the
commands
and
we
we
do.
The
last
call.
C
Yes
sounds
really
very
reasonable
and
thank
you
very
much
carlos
for
for
taking
for
taking
that
to
do
because,
yes,
we
are
almost
there
with
that
document.
B
G
Okay,
can
you
hear
me.
B
G
Okay,
okay,
so
well!
This
presentation
is
about
the
topic
for
discussion
on
the
use
of
the
dev
and
up
roles
when
trying
to
use
chic
header
compression
over
15.4
networks.
So
this
is
related
with
a
draft
which
anna
and
I
are
quartering
and
it's
intended
for
six
low.
But
of
course
it's
using
chic
and
it's
very,
very
related
with
with
lp1.
G
So
well
just
as
background,
so
probably
everyone
in
the
call
knows
well
these
concepts,
but
basically
we're
going
to
talk
about
the
devon
up
roles.
So
rfc8376
is
is
the
first
one
that
defines
deven
app.
That
would
correspond
to
the
constrained
device
like
the
sensor,
actuator
and
so
on.
An
app
would
correspond
to
some
entity
on
the
network
side
such
as
an
application
server,
so
rfc8724
basically
uses
the
same
terms
and
also
adds
a
little
bit
details
regarding
the
definition
and
also
in
in
that
rfc.
G
G
One
thing
to
keep
in
mind
that
later
will
appear
is
related
with
the
terms
applying
and
downlink,
because
in
in
the
same
rfc,
applying
and
downlink
are
defined
based
on
devon
app,
because
applying
means
from
depth
to
up
downlink
is
the
other
way
around.
So
later.
We
also
refer
to
this.
G
So
in
rfc8724,
the
compression
rules
for
some
ipv6
and
udp
head
fields,
and
actually
those
are
the
prefix,
the
iid
and
the
port
numbers
are
actually
expressed
in
terms
of
depth
and
up.
So
they
are
not
expressed
by
the
positions
of
of
these
fields
in
the
headers.
So
this
is
when
we
write
the
rules
for
compression
and
decompression.
G
So
now
the
question
would
be
okay.
Now,
what
happens
if
we
try
to
to
use
chic
header
compression
in
15.4
networks?
Well,
in
some
cases
we
may
have
star
topology
networks
where
we
may
have
constrained
devices
talking
to
some
network
site
app.
So
in
that
case,
the
the
current
model
with
the
depth
and
up
terms
fits
really
well
also.
G
However,
maybe
some
concern-
or
some
questions
may
arise
in
mesh
topologies,
because
there
may
be
peer-to-peer
scenarios
where
maybe
there
are
say
two
constrained
devices
talking
to
each
other,
and
in
this
case
maybe
it's
not
so
clear,
which
is
the
role
that
will
correspond
to
each
because
both
might
be
candidates
to
be
considered
as
dev,
but
at
least
considering
the
definitions.
Strictly
so
some
example,
let's
assume
some
nodes,
a
and
b
a
light
sensor,
a
light
bulb
that
need
to
talk
to
each
other,
maybe
through
one
or
several
hops,
in
the
middle
so
yeah.
G
Maybe
we
might
try
to
to
still
use
the
same
terms
depth
and
up
for
expressing
the
rules
for
header,
compression
and
decompression,
and
maybe
we
could
say:
okay,
let's
assume
that
the
node
on
the
left
will
be
dead.
The
one
on
the
right
will
be
up.
Okay,
perhaps
this
might
work.
Maybe
then
we
need
to
add
another
node
in
the
scenario
node
c,
which
has
some
control
on
the
threshold
setting
of
the
light
sensor.
G
So
then
there
could
be
a
question:
okay,
which
is
the
role
in
this
case
for
a
and
c
in
in
this
kind
of
interaction
when
they
exchange
messages.
So
perhaps
we
could
say:
okay,
maybe
the
note
a
could
be
up
here
and
note
c
would
be
that.
But
maybe
this
creates
problems,
and
maybe
it
would
be
easier
to
to
say
that.
Well,
let's
try
to
make
notes
only
have
one
role
for
all
the
interactions
they
have,
so
maybe
it
would
be
better
to
say,
okay
yeah,
by
doing
like
this
node
a
is
only
dep.
G
The
other
nodes
are
only
up,
it
might
seem
to
work.
However,
maybe
the
question
is:
can
we
ensure
yeah?
Can
we
ensure.
B
Yes,
and
just
to
to
to
let
you
know
we
we've
been
working,
you
know
we
have
an
architectural
document
which
is
work
in
progress.
G
Yes,
so
thank
you
for
the
comment.
The
point
is,
then,
how
we
apply,
how
we
define
the
rules
for
compression
in
in
this
sort
of
peer-to-peer
scenario
because
yeah
I
I
perhaps
I
should
revise
again
the
the
architecture
document,
the
lp1
architecture,
but
I
don't
think
the
details
for
that
or
that
my
problem,
let's
say,
is
solved
at
the
moment
in
that
document.
G
So
yeah,
maybe.
E
E
Okay,
so
so
I
said
that
it's
in
the
data
model-
we
we
have
this.
So
if
we
change
it
has
to
be
done
very
very
quickly
and
I
and
I
think
it
will
be
difficult
to
to
do
it
and
it's
not
a
technical
problem.
It's
just
a
naming
problem,
so
maybe
we
we
keep
it
and
say
that
this
one
is
dev.
This
one
is
up
and
it
really
depends
in
your.
F
I
mean
it
depends
on
who
is
sending
and
who
is
receiving
an
a
or
or
any
node
could
be
dev
or
up
depending
on
what
he's
doing
that's
my
idea,
I
don't
know
perhaps
I'm
wrong,
but
a
could
be
dev
if
he's
something
to
be,
and
it
could
be
up
if
it's
receiving
or
vice
versa,
I
mean
it
could
be
playing
the
both
roles
and
it
has
rules
for
when
he's
dead
and
rules
on
his
app.
G
So,
in
that
case,
perhaps
actually
continuing
from
from
this
common,
it
means
that
the
one
option
would
be
to
stick
to
to
the
depth
and
up
rolls
it's
the
like
the
first
bullet
on
the
first
half
of
the
slide,
and
then
the
idea
is,
we
need
to
add
some
some
additional
information
to
each
node
to
indicate
whether
it
is
going
to
be
acting
as
depth
or
up
for
any
possible
endpoint.
Let's
say
is
that
the
idea.
B
If
you
really
have
a
point-to-point,
symmetrical
exchange
and
remember,
for
instance,
we
have
a
draft
on
ppp,
where
we
used
shake
to
compress
high
speed
lines
and
it's
between
two
arbitrary
devices,
and
so
the
traffic
can
be
back
and
forth.
B
So
so,
if
we,
if
I
hear
anna
well,
you
would
become
dev
at
the
time
you
sign
a
frame
and
up,
if
you
receive
it,
and
so
the
next
frame
might
be
going
the
other
direction,
in
which
case
now
the
in
the
other
direction.
The
sender
is
there
and
up
is
the
receiver.
B
If
really
that's
the
case,
then
yes,
I
agree
with
lauren.
We
need
to
sign.
Dev
is
so
referred
to
the
architecture
to
say
it
can
be
peer-to-peer,
in
which
case
dev
is
the
peer-to-peer
sender
and
up
is
the
peer-to-peer
receiver
or
something
like
that.
B
C
I
just
want
one
point
here
before
I
joined
the
queue
I
did
before
so
yes,
I
mean,
I
think
that
here
we
have
probably
a
fundamental
question
to
to
to
discuss
and
it
is
as
as
carlos
said
so.
The
notion
of
dev
and
app
are
very
clearly
defined
when
we
are
in
a
mesh.
Oh
sorry,
when
we're
on
in
a
star,
topology
or
or
even
you
know
in
a
point
to
point,
we
can
like.
We
have
two
points,
so
we
can
stipulate
pretty
clearly
you
know
like
we
can
define.
C
This
is
the
def,
and
this
is
the
app
right,
but
in
mesh
like
what
happens
in
an
intermediate
node,
so
I
think
that
the
sender
and
the
receiver
themselves-
you
know
the
two
endpoints
can
be
pretty
clearly
we
we
can
particularly
define
what
devon
app
means,
but
what
happens
in
intermediate
nodes?
You
know
that
need
to
that.
Would
that
might
need
that
information
to
route
the
message.
C
E
Yes,
it
depends
really
on,
for
example,
if
you
go
back
to
the
first,
your
drawing
you
may
have
also
triangles.
This
means
that
the
two
up
can
talk
together,
two
another
one.
Yes,
this
one,
so
when
you
have
up,
you
can
have
also,
b
and
c
that
can
talk.
E
E
No
no,
but
if
you
have
a
mesh,
I
think
everything
here
is
on
a
mesh
and
we
can
communicate
each
other.
It's
not
a
start
apology,
so
maybe
that
sort
of
control
can
or
also
send
message
to
light
bulb
directly,
and
so
here
you
in
that
case
you
have
app
and
up
and
up
if
you
keep
the
same
name
for
every
device,
and
so
I
think
in
that
case
you
should
find
a
direction
or
you
you
did.
E
You
fix
a
direction,
and
you
say,
for
example,
a
to
b
will
be
uplink,
and
so
this
way
this
one
is
a
dev,
and
this
one
is
up
a
to
c
will
be
dunling.
So
this
one
is
a
dev
and
this
one
is
up
and
of
course
the
name
devon
app
has
no
no
meaning,
but
we
have
to
to
force
a
direction
because
the
direction
will
tell
you
if
the
dev
is
in
the
source
or
in
the
destination.
B
B
Okay,
I
mean
I
guess
we
can
update
the
architecture
to
reflect
that,
but
then
there
will
be
a
need
for
negotiation
right.
I
mean
that
that
needs
to
be
from
arbitrary
pe
to
peer
peer-to-peer.
If,
if
one
must
be
named,
dev
and
the
other
must
be
named
app,
then
we
need
to
negotiate
and
that
might
require
some
particular
exchange
on
some
particular
networks.
B
C
So
so
in
that,
in
that
order
of
of
thought,
if
we
have
let's
say
like
the
easiest
solution
would
be
to
to
actually
have
a
bit
in
the
in
the
packet
and
that
bit
says
well,
that's
an
uplink
or
or
it's
a
downing
right
and
that
can
be
like
you
don't
care
if
it's
really
an
uplink
or
downlink.
It's
just
that
the
sending
node
can
say,
hey.
C
Well,
I
think
that
that's
an
uplink,
so
I
set
a
bit
to
one
and
so
now
I
know
that
you
know
the
def
address
is
going
to
be
used
as
a
as
a
you
know,
for
the
source,
ip
and
and
the
app
is
going
to
be
for
the
destination
right
and
if
the
bit
is
set
to
zero,
it's
the
the
opposite-
and
you
know
in
the
network,
you
can
just
say,
like
the
sender
is
just
marking
the
bit
and
maybe
intermediate
nodes
can
change
the
bit
if
that's
doesn't
match
their
rules.
E
So
for
me
it's
not
a
question
of
bit.
It's
more
a
question
of
normally
when
you
have
shake
you,
you
know
your
traffic
and
then
you
create
rules
for
that
traffic,
and
so,
during
the
rule
creation,
you
have
to
say
you
act
as
this
link
will
be
viewed
as
uplink
or
downlink.
B
Butler,
if
you
have
a
large
number
of
devices-
and
there
can
be
a
lot
of
communication,
a
peer-to-peer
communication
between
those
devices,
any
20
and
just
discover
again-
I'm
thinking
about
the
p2p
case
right-
you
have
many
robots
in
the
factory
and
and
they
discover
each
other
or
it
might
be.
If
you
want
to
do
peer-to-peer
robots
to
robots,
then
they
will
have
to
name
one
of
them,
the
dev
and
one
of
the
mdf.
D
B
Clear
what
uplink
is,
but
sometimes
it's
not
in
which
case
I
guess
they
will
have
to
negotiate.
Maybe
it's
out
of
scope
for
what
we've
written,
but
still
it
has
to
be
negotiated
or
configured.
You
know.
Sometimes
you
take
the
smallest
mac
address.
You
do
anything
and
but
so
so
far
for
some
links
there
is
natural
sense
of
uplink.
If
the
robots
talk
to
the
scanner
or
something,
then
then
we
we
know
that
this
the
robot
is
the
dev.
B
On
the
other
hand,
if
a
robot
talks
to
another
robot,
then
there
needs
to
be
a
tie,
breaker
to
say
who
will
play
the
death?
Yes,.
E
B
B
Okay,
so
I
guess
we
we
will
laura
is
back
no.
B
We,
I
guess
we
understand
the
prime
we.
We
need
a
little
bit
more
discussion,
but
I
think
my
current
understanding,
alas,
is
it
can
be
addressed.
Sometimes
there
is
no
obvious
sales
of
uplink.
B
Sometimes
there
is
none,
and
when
there
is
none,
we
can
say
that
there
needs
to
be
an
out-of-bound
negotiation
discussion
to
select
who
is
dev
and
who
is
app,
and
there
are
all
sorts
of
tiebreakers
in
the
industry
for
that
sort
of
thing,
including
the
smallest
mac
address
right.
So
it's
a
re-doable,
but
then
we
have
to
say
it
has
to
be
standard
out
of
bed
and
separately
from
what
we're
doing
naming
those
devils
app.
G
G
B
Yeah,
because
it's
if,
if
I
send
you
a
frame
and
then
you
send
me
a
frame
at
some
point,
one
of
them
will
still
be
the
the
dev
and
the
other
will
still
be
the
app
means
we
can
it's.
I
I
see
it
I
initially.
I
thought
that
was
what
that
I
wanted
to
do,
but
I
realized
it's
very
hard
to
switch
the
role
on
every
frame,
whether
I'm
sending
to
you
and
you're
sending
to
me.
The
sender
becomes
the
dev
I
can.
It
can
be
kind
of
hard.
B
G
B
C
G
Well,
the
the
point
is
that
well
well,
using
devon
up
is
a
way
to
use
a
single
rule
to
allow
compressing
in
both
directions,
actually
see
both
directions
directions.
So
it's
like.
If
we
use
something
like
source
and
destination,
we
would
have
like
twice
the
the
number
of
roles
we
would
duplicate
with
the
number
of
probes.
So
that's
so
that's
drawback
also.
G
B
B
Great,
so
we
will
we'll
discuss
it
on
the
mailing
list
and
and
hopefully
we'll
conclude
that
the
atf
and
that
will
certainly
end
up
in
the
architecture
document
and
and
yes,
it
will
impact
the
yak
document
as
well.
Whatever
decision,
yes,.
C
Yes,
so
what
I
wanted
to
say
is
that
maybe
we
can
address
this
as
an
extension
right
I
mean
just
to
to
say:
okay.
Well,
we
will
be
addressing
the
peer-to-peer
shake
in
a
second
document
and
maybe
you
know,
do
not
postpone
the
the
data
model,
because
if
you
understand
correctly
like
it's,
the
source
and
destination
solution
proposed
by
carlos,
it's
like
it
doubles
the
rules,
which
is
exactly
the
same
thing
as
adding
one
bit
to
indicate
the
direction
right.
C
So
we
have
the
sense
that
here
we
are
fighting
about
a
bit
like
we're
fighting
on
one
bit
of
compression,
so
basically
to
indicate
the
the
the
the
direction
in
some
way.
So
you
know
probably
we
could
end
up
having
a
document
which
is
in
line
with
the
architecture
that
that
states.
Well,
you
know
in
a
peer-to-peer
setup
that
works
like
this,
and
then
you
need
this.
B
If
we
define
a
bit,
we
need
a
standard
track
document
just
for
that
bit.
It's
one
way
of
doing
it
and
yeah
completely
acceptable,
but
we
we
need
one
more
draft.
B
On
the
other
hand,
if
we
say
in
the
architecture
that
so
so
that's
that's,
basically
sender
becomes
dev
right,
that's
that's
option
one,
and
actually
it
was
option.
Two
in
calais,
slack
and
and
the
other
option
is
we
designate
for
each
peer-to-peer
relationship
with
using
nato,
dev
and
another
map.
I
don't
know
which
one
makes
the
most
sense,
but,
but
if
we,
if
we
take
we
designated,
they
have
an
app,
then
we
don't
need
a
new
bit.
We
don't
need
to
to
change
data
model.
C
B
Yeah
we
have
the
two
options,
but
in
the
end,
if,
if
we
go
for
for
the
bit,
then
that
will
impact
the
data
model
because
we
will
need
to
declare
that
bit
as
well.
So
we
need
to
talk
soon
between
now
and
the
atf.
We
need
to
agree
on
this.
B
Do
you
hear
me
yeah.
E
E
So
if
we
have
this,
then
it
means
that
we
we
have
only
here,
we
have
a,
we
can
have
a
direct
direction
if
we
say
that
everybody
is
in
the
common
rule,
then
it's
more
difficult
to
say
who's
up
with
down.
B
I
mean
we,
I
am
not
sure
I
follow
you,
we
can
have
a
rule
every
device.
Let's
say
we
have
a
large
network
of
peer-to-peer.
Every
device
are
basically
the
same
fabric,
but
they
can
talk
to
one
another,
so
that
could
be
a
single
set
of
rules
apart
from
the
the
ip
address
themselves,
right
or
mac
address
or
whatever,
but
but
for
for
the
traffic
they
do,
etc.
B
That
could
be
a
single
common
set
of
rules
and
they
would
just
have
to
decide
when
a
talks
to
be
whether
a
in
the
rule,
five
is
the
dev
or
is
the
app
yes,
but.
E
C
B
So
basically,
let's
describe
the
two
solutions:
careless
since
you're,
the
one
who
bears
this
slide.
Would
you
mind
sending
an
email
to
the
mailing
list
explaining
the
two
solutions?
I
mean
how
to
discover
devon.
B
Is
it
sender
which
basically
the
one
who
sends
the
frame
which
is
who
sets
the
bit
and
and
is
the
dev
and
no
and
the
other
one?
When
there
is
a
reply
or
yes
is
the
app?
It
still
doesn't
care
to
me
no
or
if,
basically,
once
a
talks
to
b
over
a
mesh,
then
for
that
particular
peer-to-peer
relationship,
they
have
to
decide
before
they
start
talking.
Who
will
be
there,
and
I
can
talk
to
five
people
on
some
of
them.
I
would
have
negotiated
them
there
and
others.
I
would
have
negotiated
them.
B
B
So
yeah,
it
would
be
ideal
that
we
really
understand
taking
some,
maybe
some
examples
which
one
of
those
two
ways
works
best.
And
if
that
means
we
have
a
bit
which
says,
oh
I'm,
using
five
acting
as
a
dev,
then
yes,
we
need
the
bit
and
but
if
we
need
a
bit
that
impacts
a
lot
of
documents.
B
B
And
with
this,
do
we
have
any
other
all
right?
You
wanted
to
speak,
you
see
in
the
queue.