►
From YouTube: IETF110-RAW-20210308-1200
Description
RAW meeting session at IETF110
2021/03/08 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
For
politeness
as
I
drink
my
coffee,
so
it's
approaching
12
o'clock,
it
is
12
o'clock
shall
we
shall
we
start?
I
want
the
rides
to
present,
but
I
run
a
4k
monitor
so
some
if
they
are
too
high
resolution,
for
whatever
reason
can
somebody
please
shout
and
we'll
do
something
different.
A
So
let
me
just
try
and
get
the
chair
slides,
which
have
all
appeared
in
the
wrong
order.
A
Yeah
there
we
go
yes,
so
can
you
see
my
screen?
We
can
excellent.
So
obviously
I
now
can't
see
meet
echo.
I
can
only
see
the
slides
I'm
sharing
but
we'll
make
it
work
somehow.
A
That
would
that
would
be
great,
and
do
you
want
to
kick
off
either
or
or
why
don't
you
have
a.
B
A
It
okay,
no
worries,
so
I'm
assuming
we've
got
everyone
here,
we're
about
one
minute
behind
time,
but
we've
got
a
fairly
packed
schedule,
so
I'll
press
on
hello,
everyone
and
welcome
to
the
raw
working
group
meeting
at
ietf,
110
virtual
slash
pretend
we're
in
prague
good
morning,
if
you're
in
the
states
good
evening,
if
you're
in
asia,
hello
good
day,
if
you're
in
europe.
A
So
as
this
is
a
working
group
meeting,
this
is
covered
under
the
note.
Well,
if
this
is
your
first
time
attending
an
ietf
working
group
meeting,
I
suggest
you
find
a
copy
of
the
note
well
and
read
it
carefully.
Those
of
you
who
are
old-timers
are
probably
familiar
with
this.
This
is
the
standard
note.
Well,
79
is
the
document
which
describes
in
great
detail
what
this
actually
means,
but
the
executive
summary
is
that
line
in
bold,
which
is
you
are
contributing
to
the
ietf
by
speaking.
A
That's
the
short
answer
so,
and
here
is
the
various
other
policy
documents
you
need
to
know
about
anti-harassment
code
of
conduct.
If
you
have
any
concerns
about
any
of
these
things,
we,
the
chairs,
are
your
first
port
of
call
and
we
can
escalate
this
to
the
various
working
groups
set
aside
specifically
to
cover
these
sort
of
things.
A
So,
administrative,
I'm
assuming
you're,
all
on
me,
techo
some
of
you
might
be
on
jabba.
Some
of
you
might
be
dialed
in
through
some
audio
stream
and
just
listening,
but
the
details
are
on
the
screen.
Now
key
points
are
eve,
is
currently
tracking
the
jabber
which
is
integrated
into
meat
echo.
A
So
if
you
are,
if
you
have
comment,
please
a
quick
chat
message
is
great
or
you
can
use
the
meet
echo
facility
to
join
the
queue
equivalent
of
raising
your
hand
and
we,
the
chairs,
will
start
pushing
people
through
the
queue,
so
they
can
make
comments
at
the
microphone
so
to
speak.
A
The
other
key
point
is:
we
are
using
kodi
md
for
our
live
minutes,
I'm
not
sure
if
we've
got
a
volunteer
for
a
minute
taker,
yet
I
can
only
see
my
screen
and
not
meet
echo,
but
we
need
to
collaboratively
produce
some
minutes
for
this
meeting
for
posterity.
A
So
please
join
in
the
integrated,
cody
md,
it's
marked
down.
It
will
handle
multiple
people
typing
simultaneously.
Please
don't
massively
overwrite
other
sections
that
other
people
are
typing
in.
There
will
be
an
opportunity
before
miteka
closes
down
at
the
end
of
the
session,
just
to
quietly
take
out
your
typos
and
things
like
that,
but
I
know
at
the
last
session
no
sorry
at
the
virtual
107
which
we
held.
A
We
had
a
bit
of
a
up
with
the
blue
sheets
and
we
lost
half
the
attendees
list
because
somebody
was
very
excitably
editing
or
there
was
a
glitch
or
something.
So,
although
it
works
pretty
reliably,
please
be
a
little
bit
careful
about
simultaneously
typing,
exactly
the
same
characters
as
somebody
else.
Otherwise,
the
normal
things
are.
We
have
a
mailing
list,
I'm
sure
you're
all
subscribed
to
it.
A
The
mailing
list
is
the
official
place
where
consensus
is
achieved
and
decisions
are
made.
So
if
you
have
a
long
and
detailed
discussion,
the
mailing
list
is
the
place
to
have
it,
and
even
I
may
at
certain
points
as
time
presses
on
during
this
meeting
say.
Let's
take
that
to
the
list,
which
means
it's
a
valuable
discussion,
but
it's
consuming
all
of
our
agenda
and
we
want
to
get
on
some
other
points,
and
the
mailing
list
is
the
right
place
for
that,
and
a
link
to
the
meeting
materials
is
at
the
bottom.
A
So
this
should
be
well
it
isn't
it
isn't
should
be.
It
definitely
is
where
you
can
get
a
copy
of
all
the
presentations
that
are
being
presented,
plus
the
chair,
slides
and
the
agenda,
and
the
minutes
should
be
there
as
well,
when
we
have
got
around
to
uploading
them
after
this
session.
A
It
normally
takes
us
a
little
bit
of
time
thanks
to
time
zones
to
get
that
sorted,
but
the
minutes
will
go
up
there
for
all
posterity,
so
agenda,
I've
sort
of
done
the
intro
I'm
doing
the
intro
we're
going
to
kick
off
with
ldax,
because
nielsen
the
team
have
done
lots
of
extra
work
and
we'd
really
like
them
to
present
what
they
have
done.
So
we
can
see
where
we
are
in
terms
of
progressing
that
document.
A
As
far
as
I'm
aware,
it
is
getting
pretty
mature,
but
I
will
leave
niels
to
let
us
know
what
he
thinks.
The
next
steps
are.
As
far
as
the
working
group
is
concerned,
this
is
a
working
group
document,
so
it's
ours,
the
group
to
have
consensus
on
whether
we
think
it's
finished
not
finished,
ready
for
working
group,
last
call,
etc,
etc,
but
niels
and
the
author
team
obviously
are
the
ones
holding
the
pen
after
that
pascal's
gonna
go
over
the
changes
that
have
happened
in
the
raw
technologies
draft.
A
So
that's
for
those
of
you
unfamiliar
it's
a
great
lengthy
document
which
covers
a
lot
of
the
link
there,
technologies
that
are
out
there
a
lot
of
the
things
we're
copying
across
from
det
net
and
sort
of
state
of
the
art
in
terms
of
what
we
could
use
to
build
raw
systems
and
tacked
on
to
the
end
of
that.
A
I
I
asked
pascal
if
he
could
go
over
some
of
his
what's
currently
a
personal
draft
into
proposed
architecture
for
raw,
so
this
introduces
some
of
the
concepts
that
have
been
discussed
on
the
list
in
person
at
meetings
before
introducing
the
concept
of
path,
selection
element,
how
that
integrates
with
om
and
upstream
traditional
teas
style
pce,
and
how
that
integrates
downstream,
with
tsn
and
various
wireless
technologies,
etc,
etc.
A
And
I
thought
it
was
useful
to
go
over
that
one
more
time,
because,
following
from
that,
I'm
doing
a
short
presentation
on
the
d-let
protocol
and
how
that
might
apply
to
raw
how
it
might
bring
us
some
interesting
things
that
we
could
reuse
or
build
upon.
Carlos
bernandes
has
some
interesting
use
case
analysis
for
mech,
and
I
have
to
remember
what
this
is.
It's
basically
edge
compute
use
cases
and
how
those
edge
compute
use
cases
really
need
some
understanding
of
if
they're
running
within
a
raw
environment.
A
What
can
raw
tell
the
edge
compute
management
system
and
an
orchestrator
so
that
it
understands
the
capabilities
of
the
network
as
it
starts
to
push
functionality
out
to
the
edge,
but
obviously
I'll?
Let
carlos
clarify
that,
because
I'm
approximating
my
understanding
and
we
have
a
presentation
from
ruta
sophia,
I
hope
I
pronounce
your
name
correctly
talking
about
some
of
the
industrial
requirements.
A
So
there's
a
really
nice
personal
draft
has
gone
in
with
lots
of
detail
about
industrial
wireless
and
the
sort
of
things
that
that
use
case
would
like
to
see
coming
from
determinism
and
reliable
layer,
wireless
layer
and
and
how
sort
of
what
they'd
like
to
see
raw
tackle
as
part
of
their
use
cases,
and
we
can
have
a
discussion
about
that
on
whether
that
gets
integrated
into
some
of
the
use
cases,
documents
or
the
technologies
or
whether
it
lives
on
as
its
own
document,
and
hopefully
that
will
promote
some
good
discussion
as
well
and
for
the
last
10
minutes,
we've
set
aside
some
time
for
discussion.
A
We
have
a
hard
stop,
because
this
is
the
ietf
working
group
meeting.
So
we
have.
We
are
bounded
by
time.
Obviously,
as
I
said
before,
conversations
can
continue
to
the
list.
Add
infinitum
so
eve.
Do
you
want
to
step
in
and
go
through
some
of
the
milestones,
because
I
feel
like
I'm
just
talking.
B
Okay,
for
those
of
you,
who've
been
tracking
our
milestones
they.
B
These
are
the
milestones
we
set
when
we
set
our
charter
and
at
that
point
in
time,
we
identified
four
documents
that
we
had
ambition
to
deliver,
both
as
working
group
items
for
adoption,
as
well,
as
you
know,
eventually,
to
submit
to
to
graduate
through
the
process,
and
those
are
the
items
that
you
see
here
in
bold
face
a
use
case
documents
originally
what
was
a
requirements
document
but
which
has
evolved
into
somewhat
of
a
technologies
document
not
somewhat,
but
it
is
evolved
into.
B
Alternatively,
a
technologies
document,
the
architecture,
framework
document
and
ultimately
get
to
a
point
where
we
have
a
document
that
is
evaluating
the
existence
of
ietf
technologies
and
a
gap
analysis,
and
so
some
of
these
items
have
already
been
created
and
are
wending
their
way
through
the
system.
We
have
a
use
cases
document.
Many
of
these
have
been
well
I'll
say
that
the
use
cases
document
seems
to
be
tracking.
B
It's
been
adopted
by
the
working
group,
as
has
the
technologies
draft
the
we
have
not
submitted
anything
to
the
iasg
as
yet.
But
you
know
and
we'll
have
some
discussion
today
about
the
architectural
framework
document,
and
so
you
can
see
we're
a
little
bit
behind
in
where
we
meant
to
be,
but
nonetheless
there's
a
healthy
collection
of
internet
drafts
that
will,
we
believe,
with
some
maturation
will
get
us
to
where
we
want
to
be
so.
B
I
would
say
that-
and
we
discussed
this
last
time
as
well,
that
although
we
are
somewhat
behind,
we
are,
we
seem
to
be
making
steady
progress
and
we
will
focus
a
little
bit
on.
Although
there's
no
evaluation
of
an
existing
itf
technologies
and
gap
analysis
document,
we
feel
that
that
the
other
documents
are
steadily
marching
us
towards
that.
B
Please
so
this
is
just
a
preview
slide
of
what
we're
hoping
will
happen
after
the
presentations,
but
while
you,
you
are
listening
to
the
presentations
and
hopefully
participating
in
some
of
the
discussion
afterwards,
keep
in
mind
that
some
of
the
things
some
of
the
issues
that
are
top
of
mind,
is
whether
the
architecture
document
is
ready
for
working
group
adoption.
There
have
been
some
just
early
morning
back
and
forth
on
the
mailing
list,
which
has
been
quite
interesting,
which
we
will
return
to
a
discussion
today.
The
oam
draft.
B
Is
it
also
ready
for
working
group
adoption
and
the
technologies
draft?
Should
we
be
submitting
it
to
the
iesg
and
then,
as
was
stated
earlier,
we
have
this
wonderful
new,
detailed
industrial
requirements
draft
whether
to
keep
it
separate
or
combine
it
that
seems
top
of
mind
and
then
these
other
topics
for
which
we
have
presentations.
B
The
the
mech
drafts
the
d
left
draft
for
raw
and
just
to
bring
to
your
attention
a
draft
that,
although
we
decided
not
to
schedule
for
this
session,
we
anticipate
including
it
in
the
next
ietf
and
part
of
why
it's
not
here
being
discussed,
is
just
scheduling
issues
and
also
that
it
will
be
presented
during
the
second
session
for
debt
net,
which
is
tomorrow,
and
we
would
encourage
those
of
you
participating
here
today
to
attend
there
to
to
catch
that.
B
B
Unless
I
I
think
it's.
A
Oh
yeah
yeah,
I
mean
niels.
If
you
want
to
present
that's
fine
because
then
you
can
control
the
slides
by
all
means.
If
you
don't
have,
if
you
can't
present,
I
can
stand
in
if
you
need.
A
C
I
think
it
does
yeah
good,
okay,
okay,
yeah,
it's
it's
great
to
be
here
and
today
I'm
going
to
give
an
update
about
the
work
that
we've
been
doing
for
the
last
three
months.
C
So
next
today,
I'm
going
to
present
the
ldx,
the
lbn
digital
air,
multiple
communication
system
turned
ldax
and
the
draft
version
is
o7.
Next
slide,
please
yeah!
Here
we
find
the
load
well
again,
I
think
we
saw
that
already
next
one,
please
yeah,
that's
the
current
version.
So
if
you
have
not
had
the
chance
to
read
it,
yet
it's
a
great
read,
I
can
assure
you
so
please
go
ahead.
C
We
also
received
a
lot
of
feedback,
so
thank
you,
everyone
for
providing
us
with
a
valuable
input
so
far
and
as
you
can
see
this,
this
version
is
now
from
17th
of
february
2021.
So
rather
recent
next
slide.
Please.
C
Yeah
here
we
can
see
some
changes
that
happened
since
the
last
itf
line.
So
last
time
was
all
about
bringing
in
the
reliability
part
into
the
draft.
So
why
ldx
really
fits
the
description
of
the
the
group
theme
here
and
now
this
time
we
were
asked
about
the
security
of
ldax,
and
so
mainly,
we
focused
on
chapter
10
here,
so
the
security
aspects
of
ldax.
What
kind
of
security
do
we
need
here
in
this
technology?
C
Also,
on
a
broader
scale,
we
had
some
discussions
with
iko
so
with
the
international
aviation
organization
and
radio
manufacturers
about
the
general
architecture
and
ecosystem
in
which
aldex
would
live,
because
aldex
will
probably
be
deployed
starting
around
2024.
C
So
a
lot
of
things
are
currently
shifting
and
moving,
and
it's
quite
the
exciting
time
to
to
be
honest,
and
so
also
another
important
update
was
just
that.
Basically
in
this
draft,
what
we're
doing
is
describing
the
data
link
between
a
ground
station
and
an
aircraft.
So
in
previous
drafts
we
described
the
data
link,
architecture
between
a
ground
station
controller,
controlling
multiple
ground
stations
and
then
controlling
multiple
aircraft,
and
now
we're
only
focusing
on
the
ground
station
to
aircraft
station
part
yeah.
So
let's
dig
in
next
slide.
C
Please,
let's
start
off
with
the
basic
question,
so
why
does
aeronautical
communications
in
particular
need
security
and
what
did
happen
over
the
last
30
years?
I'm
saying
30
years,
because
aviation
thinks
in
very
long
terms.
So
if
you
think
the
last
digital
data
link
for
terrestrial
communication
that
was
actually
adopted
and
specified,
and
so
on,
there
was
video
number
two
and
the
first
specification
that
defined
that
was
in
1990.
C
So
though,
it's
roughly
30
years
ago
actually-
and
since
then
a
lot
has
changed.
So
the
problem
that
we're
facing
now
is
the
the
the
changing
threat
landscape
because
historically
the
communication,
navigation,
surveillance
and
short
cns
wireless
technology-
they
emerged
from
the
military
and
the
military
has
a
lot
more
bandwidth.
They
have
a
lot
more
spectrum.
C
They
have
a
lot
more
resources
to,
for
instance,
use
physical
layer,
robustness
measures
such
as
frequency
hopping
or
pilot
symbol,
scrambling
and
stuff,
like
that,
so
to
make
it
robust
and
secure
already
on
the
physical
level
and
for
aldex.
This
is
not
possible
because
we're
talking
about
the
civil
technology
here,
so
we
have
less
spectrum
available
and
then
the
question
is
also
with
software
defined
radio.
C
So
I
have
some
laying
around
here
actually
and
then
there's
a
lot
of
open
source
software,
making
them
able
to
to
capture
traffic
or
possibly
even
to
inject
data
into
the
aeronautical
data
stream
and
as
all
of
this
is
wireless.
Obviously
this
is
quite
the
threat.
C
Obviously,
civil
aviation
is
currently
facing,
so
the
consequences
are
that
future
technologies,
and
I'm
talking
about
eldags
as
one
of
them,
obviously,
but
also
one
that
was
already
published,
aeromags
or
then
satcom
iridium,
said
certains
or
inverses,
with
broadband
and
and
all
the
stuff
coming
up
for
the
future
communication
infrastructure
for
aeronautical
comms.
All
of
these
need
to
have
strong
security
features
already
implemented
on
on
the
link
layer.
Basically
because
that's
the
first
point
of
contact.
C
C
Here
we
have
the
shells
and
shoulds,
so
what
should
ldex
have,
which
shall
alex
have?
Obviously
the
very
first
requirement-
that's
not
listed
here
specifically,
is
if
we
use
security
measures
here.
So
if
you
put
security
in
the
system,
obviously
the
regular
working
should
not
be
hindered
in
any
way.
So
we
have
to
make
sure
that
whatever
security
measures
are
put
in
that
safety
is,
is
in
no
way
endangered.
C
Obviously,
so
that's
the
availability
and
continuity
as
we
know
it
so,
for
instance,
packet
rate
limiting
and
stuff
like
that,
so
make
sure
that
technology
is
available,
but
it's
also
make
sure
that
whatever
security
you
put
in
that
the
technology
itself
remains
available,
then
one
big
important
point
is
the
integrity
of
messages
in
transit,
so
whatever
is
being
sent
on
the
data
link
needs
to
to
remain
authentic
and
integra,
so
no
other.
C
For
instance,
no
adversary
should
be
able
to
put
in
data
link
on
data
on
the
data
link,
obviously
also
authenticity.
So
that
means
we
have
to
have
mutual
authentication
in
in
the
field.
Then
they
should
provide
confidentiality.
So
that's
a
question
of
key
management.
Basically,
because,
obviously,
aviation
is
handled
around
the
world,
so
how
do
you
make
sure
that
if
a
message
is
delivered
in
a
confidential
manner
and
some
air
traffic
control
service
or
some
other
air
traffic
control
from
another
country
needs
to
have
access
to
this
kind
of
information?
C
So
confidentiality
is
a
should
requirement
for
other
sensitive,
for
instance,
business
data
stuff
like
that,
then
the
non-repudiation.
This
is
important,
obviously,
for
the
sensitive
part
of
the
mutual
authentication
key
exchange
part
and
then
there's
the
authorized,
permitted
actions
of
users
and
deny
actions
else.
So
we
have
to
have
some
kind
of
identification,
authentication,
authorization
and
so
forth
and
also
alex
needs
to
have
some
kind
of
capability
to
prevent.
If,
if
there's
an
intrusion-
and
we
need
to
prevent
it
to
spread
from
there,
obviously
so
next
slide,
please.
C
So
this
brings
me
now
on
how
do
we
incorporate
now
security
into
the
protocol
stack
of
ldac?
So
ldx
security
is
located
on
the
link.
I
could
say
so
because
above
ldax
above
the
subnetwork
protocol,
the
snp,
it
is
foreseen
to
use
ibv6
or
and
then
above
udp,
so
ldx
security
secures
the
connection
between
an
aircraft
station
in
the
ground
station.
C
As
I
said
before,
so
just
the
very
first
time,
for
instance,
there
there's
a
plane
flying
around
flying
around
and
then
there's
an
aircraft
station
broadcasting,
it's
beacon
and
then
the
aircraft
catches
up
beaten
and
sees
okay,
for
instance,
there's
some
kind
of
a
signature
with
a
timestamp
in
something.
So
I
know
it's
about
the
ground
station.
Then
it
starts
making
basic
contact
so
just
a
cell
entry
process
where
the
aircraft
gets
access
to
the
lx
resources.
C
So
the
actual
data
link
communication,
user
data
communication
and
then
the
entire
authentication
procedure
actually
starts.
So
this
is
why
we
say
the
security
really
is
between
aircraft
and
ground
station
next
slide.
Please.
C
So
yeah,
how
do
we
put
in
security
and
what
kind
of
security
do
we
actually
put
in?
So
here
we
have
the
protocol
stack
again
so
below
we
have
the
physical
layer,
medium
access,
layer,
mac,
and
then
we
see
here
this
dch
and
dcch
and
so
forth.
So
dch
is
the
data
channel
used
for
user
data
communication.
C
Then
we
have
the
ccch
dcch,
the
random
access
channel,
the
rach
and
the
pcch.
So
many
many
channels
here,
so
the
random
access
channel
is
the
one
where
an
aircraft
comes
into
the
cell
and
says
hey
I'm.
Here
I
want
to
get
access
to
the
cell.
The
bcch
is
basically
the
broadcast,
whereas
when
the
ground
station
announces
its
existence
to
the
world
and
then
the
common
control
channel,
the
ccch
is
for
that.
C
The
ground
station
grants
resources
to
an
aircraft,
so
an
aircraft
can
actually
transmit
in
the
data
channel
and
the
this
is
the
age.
Finally,
is
the
resource
request
channel
so
to
speak
and
and
then
you
can
see
that
the
dls,
so
the
data
link
service
here
is
is
for
the
user
data
part
and
the
lme.
That's
the
ldx
management
entity
is
basically
for
maintaining
the
link
and
and
also,
as
you
can
see
here
now
handling
most
of
the
security
part
and
then
on
the
snp,
so
the
subnetwork
protocol
layer,
v4c
user
data
security.
C
So
as
we
see
here,
user
plane,
security
will
be
handled
in
the
s
p.
Currently
we're
discussing
and
also
iko
has
some
ideas
on
that
that
aes,
256
galore
counter
mode
would
be
a
great
idea
because
it
provides
confidentiality
and
integrity
at
the
very
same
time.
So
that's
a
great
thing.
C
If
that's
not
possible,
then
also
we're
considering
hmac
with
hash
functions
from
the
shower
3,
family
or
shake,
and
then
more
interestingly,
actually
is
the
lme
now
so
there
will
be
ldx
specific
certificates,
the
same
way
as
aeromax
has
arrowmax
specific
certificate.
So
aeromax
is
an
airport
communication
data
link
and
this
aldex
is
for
terminal
maneuvering
areas
and
on
route
communication
on
on
continental
flights,
basically
or
when
an
aircraft
flies
over
continent
and
and
so
yes,
aldex
specific
certificates
and
handles
the
mutual
authentication.
C
So
there
will
be
some
kind
of
station
to
station
or
sql
protocol.
I'm
going
to
come
to
that
a
bit
later
so
entity,
authentication,
key
negotiation,
key
derivation,
key
management
key
handling,
basically,
is
the
task
of
the
lme
or
some
some
part
of
the
lne
lme.
Obviously,
security
logging
is
what
we
need
and
because
resources
requests
or
sending
beacons
and
stuff
is
also
triggered
by
the
lme,
then
the
control
channel
protection
in
some
ways
also
part
of
the
enemy
next
slide.
Please.
C
Yeah
trust
is
probably
the
most
important
thing
in
any
system,
so,
as
I
said
before,
ldx
will
follow
the
aeromax
lead
and
also
using
future
communication
infrastructure.
Fci
specific
pki,
also
defined
here
in
this
rfc
and
we'll
use
some
x
509
certificates
that
are
very
specific
so
prior
to
the
atm
ips,
so
the
aeronautical
telecommunications
network
over,
for
instance,
ip
there
was
way
back
a
cars
and
and
acres
in
2007..
C
They
had
a
great
update
in
the
arring
standard
823
with
eric
message,
security
and
they
basically
pre-define
what
kind
of
secure
for
what
kind
of
certificates
you
will
have
in
this
in
this
ecosystem,
and
we
will
probably
follow
their
lead
and
also
and
just
incorporate
the
updates
that
happen
since
then,
the
mutual
authentication
and
key
agreement.
C
We
have
unique
identities
for
aircraft
and
ground
stations
and
we're
currently
going
for
either
an
identity
based
station
to
station
protocol
or
an
identity
based
sign
in
max
so
sigma
protocol.
So
sigma
is
part
of
dls
1.3
now,
so
I
think
it's
a
great
way
to
go
forward
next
slide.
Please
yeah,
then
the
choice
of
the
diffie
hellman
and
that's
a
good
question.
So
what
kind
of
different
do
we
need?
Because
of
the
life
span
of
aeronautical
communications?
C
You
would
think
we
will
definitely
have
to
go
for
a
post-quantum
security
problem
with
post
quantum
is
so.
We
looked
into
super
singular
society,
helming
key
exchanges.
It
requires
a
keys
of
currently
2
640
bits.
C
So
if
you
compare
that,
for
instance,
the
elliptic
curve,
so
you
have
a
factor
of
10
in
between
so
the
current
way
forward
will
be
to
use
an
elliptic
curve
cryptography
with
two
five
six
keys
and
then
with
the
possibility,
obviously,
to
upgrade
cypher
suites
two
to
incorporate
then
post
quantum
robust
ciphers
later
on
and
for
key
derivation
we're
going
for
the
hash
based
message:
authentication
code
kdfs
with
hkdf
next
slide.
Please.
C
As
I
said
before,
user
data,
security,
as128
gallery
counter
mode,
256,
color
counter
mode
or
the
hmax
3
128
should
be
enough
for
user
data
integrity
protection
simply
because
data
is
very
limited
still
in
the
spectrum.
C
So
if
you
apply,
for
instance,
a
256
mac
here,
a
bit
mac
here-
that's
that's
simply
too
large
and-
and
the
key
basically
is-
is
the
result
of
this
mutual
authentication
key
agreement
procedure
that
we
discussed
earlier
on
so
the
station
to
station
sigma
and
then
derived
by
the
hkdf,
and
then
we
have
the
session
key
to
use,
for
instance,
user
data
security
and
now
for
control
channel
security.
This
is
way
more
complicated
because
the
challenge
is
here:
they
are
small.
I'm
talking
small
about
the
random
access
has
56
bits.
C
The
dedicated
common
control
channel
is
83
bits,
so
yeah,
they're
small
and
the
other
important
thing
is
that
everyone
in
a
cell,
so
every
aircraft
in
itself
needs
to
be
able
to
see
what
other
aircraft
around
him
or
her
or
it's.
I
think
it's
a
bit
received.
So
they
have
to
be
able
to
read
that
so
we're
talking
about
group
keys
so
we're
talking
about.
We
have
an
elder,
excel
group
keys.
Why
are
they
one
way
function?
C
Trees
because
they
simply
put
the
least
amount
of
load
on
the
link,
time-bound
signatures
in
the
broadcast
in
the
broadcast
channel.
Then
the
cse
plus
mac
approach
in
the
common
control
channel
and
encryption
cc
and
mac
in
the
dedicated
control
channel,
simply
because
we
don't
have
space
next
slide.
Please.
C
Yeah-
and
I
think
I'm
just
in
time-
I
made
it
thanks
for
listening
everyone
and
welcome
for
questions.
A
Now
you
very
much
niels
that
was,
that
was
fast.
Sorry,
we
started
slightly
late
and
therefore
compressed
you,
let's
hold
questions,
because
I
see
no
one
in
the
oh,
yes,
I
I
can't
pronounce
your
name.
I
am
really
sorry,
but
but
go
ahead.
D
Yeah,
okay,
that's
right
nils!
Maybe
it
has
been
discussed
before.
But
can
you
revise
what
is
the
nature
of
coordination
between
iko
and
this
craft
and
so.
C
D
C
A
Okay,
thank
you
niels.
I
think
we
will
move
on
to
pascal.
Thank
you
very
much.
Let
me
stop
sharing
that
and
find
pascal
slides.
If
you
are
there
pascal
there
you
go.
A
C
Kyle
sorry
to
to
interrupt
here,
I
just
wanted
to
finish
my
talk
with
one
thing,
so
we
haven't
received
any
feedback
during
the
last
three
weeks,
so
we
encountered
everything
incorporated
everything
and
now
we
would
like
to
ask
for
last
call
actually.
So
if
there's
any
feedback,
please
give
the
feedback
you
want
to
give
and
we're
asking
for
the
last
call.
A
Okay
noted
niels,
what
I
will
do
is
I
will
make
a
note
to
say
that
on
the
list,
because
that's
the
right
place
to
do.
The
last
call
calls
I'll
announce
that
I
think,
given
the
complexity
of
this
subject,
we
will
probably
go
for
quite
a
number
of
weeks
for
the
last
call.
Sometimes
you
say
two
weeks
because
everyone
knows
the
subject,
but
I
think
people
need
to
have
a
chance
to
read
this
in
depth.
A
So
obviously,
even
I
will
have
a
discussion
with
you
about
what
we
think
the
complexity
is,
but
I
can
imagine
six
eight
weeks
something
like
that
to
let
people
know
that
means
everyone
else
in
the
working
group.
Please
take
a
chance
to
read
this.
It's
a
good
work
but
b
it's
a
working
group
document,
so
we,
the
group,
need
to
be
sure
that
we're
happy
with
this
and
when
we
are,
we
can
press
the
button
so
yeah.
Thank
you
for
the
reminder.
Niels,
good.
E
Okay,
I
was
citing
whether
to
share
screen
on
just
the
app,
so
I
shared
the
app
and
thank
you
for
for
giving
me
back
the
authorization
okay,
so
I
have
actually
two
things
to
discuss.
One
is
the
raw
technology
for
which
we
publish
published
a
draft
one
with
some
additions
on
the
airbag
side
and
then
we'll
go
per
your
request
right
to
discuss
a
bit
on
the
architecture
document
and
what
just
happened.
So
there
are
some
news,
so
actually
I
will.
E
I
will
send
you
the
update
of
the
slide
for
publication,
because,
because
of
the
discussion
we
had
today
on
the
mailing
list,
I
changed
them
a
little
bit.
So
this
is
the
technology.
So
why
do
we
have
this
draft?
We
have
this
draft
because
some
of
the
technologies
that
are
being
used
by
row
are
actually
not
usual
to
the
atf.
E
E
So
we
we
cover
four
technologies,
wi-fi
six
and
beyond
wi-fi
seven,
be
we
cover
1540
ach,
which
is
the
radio
link
used
by
six
dash.
We
cover
5g
6g
nldx
that
neil
just
discussed,
and
thanks
nils
and
karina
for
the
updates
on
this
techno
terminal
technology
document.
So
so
what
happened
recently?
Last
time
I
told
you
that
we
had
this.
This
simple
structure
with
for
x
for
technology
x.
We
had
x1
x2,
x3
and
actually
janas
when
he
published
the
5g.
E
He
added
something
about
deployment
and
spectrum,
which
was
kind
of
nice
kind
of
sleek.
So
we
we
discussed
with
with
the
group
whether
the
other
technologies
should
align
to
this
and
for
now
o'neill
dax
is,
but
I
really
hope
that
tsch
and
wifi
do
as
well,
because
that's
a
very,
very
interesting
discussion,
mostly
because
you
know
the
spectrum
that's
currently
used
by
most
wi-fi
applications
is
a
very
busy
spectrum,
but
there
are,
for
instance,
for
wi-fi.
E
So
that's
that's
a
a
pretty
interesting
discussion.
If
you
want
to
reach
more
determinism,
more
reliability,
then
having
some
capabilities
to
play
with
spectrum
is
is
important.
So
we
have
this
discussion
in
ldax.
We
have
this
discussion
in
5g.
I
wish
to
have
it
in
wi-fi
and
for
tch.
There
is
not
much
to
say
because
it's
just
the
plain
sub,
gig
and
and
2.4
belts
for
now,
maybe
in
the
future,
but
so
what's
new
the
dock
was
adopted.
E
We
are
now
zero
one
four
I
can
say,
apart
from
this
discussion
on
spectrum
that
that
I
just
introduced,
we
are
pretty
much
there,
so
I
would
you
know
like
to
discuss
with
the
chairs
and
how
to
move
on
with
asking
for
publication.
E
Like
I
said
this
was
already
emulated
by
a
dac.
So
only
really
wi-fi
needs
to
to
to
do
some
work
on
that.
Maybe
some
things
change
on
on
the
11th
side,
so
maybe
there
could
be
some
little
update
on
on
ts
and
over
wi-fi.
So
that's
something
I'd
like
to
see.
I
was
wondering
if
we
wanted
to
to
discuss
a
little
bit
about
ip
itself
like
for
now.
E
This
is
just
the
lower
layer
technologies
to
want
to
stick
at
that,
or
do
we
want
to
to
have
some
notes
about
how
we
could
signal
stuff
at
the
upper
layer
that
we
could
fit
into
the
lower
layer?
Maybe
maybe
not
it's
just
something
I
was
wondering
so
if
you
want
to
discuss
that
on
the
mailing
list,
but
my
bottom
line
is
I'm
very
happy
with
the
content
of
this
document.
E
We
want
some
more
on
the
prime
statement.
I
realized
that
there
are
documents
like
the
one
that
root
has
just
which
we'll
be
discussing,
which
will
also
contain
some
requirements
and
prime
statement,
I'm
not
really
clear
about
where
that
piece
goes.
That's
another
discussion
for
the
chairs,
because
we
see
some
of
the
prime
statement
in
this
document
kenneth.
We
see
some
of
it
in
the
architecture
and
we
see
some
of
it
in
the
in
the
use
cases.
E
So
so
do
we
think
that
it's
something
that
you
can
intuit
from
these
three
documents
or
something
that
should
be
written
somewhere
like
here.
A
So
rick
jumping
in
on
that
point,
a
question
to
the
working
group,
I
would
say,
is:
do
we
actually
want
to
pull
that
text
out
of
each
of
these
three
documents
and
make
a
short
punchy
problem
statement
draft,
or
are
we
just
making
work
for
ourselves
open
question.
A
A
There
is
no
explicit
reference
material
to
say
this
is
the
problem
raw
is
trying
to
solve.
I
think
we
need
to
look
at
what
debt
net
has
done,
because
debt
net
has
done
a
really
good
job
of
this
sort
of
thing
and
take
some
guidance
from
what
they've
they've
done,
but
perhaps
a
problem
statement
document.
If
it
doesn't
waste
our
effort
may
have
value,
but
let's
take
that
one
to
the
list,
but
I
think
that's
a
useful.
Well,
if
we've
got
time
at
the
end
of
the
session,
that's
a
useful
discussion.
E
E
It
really
explains
why
what
you
know
what
scheduling
can
do
for
you
and
why
it's
needed,
but
why
this
text
is
actually
left
in
the
in
in
the
technology
draft?
It's
just
you
know
it
could.
C
E
B
And
I
like
this
question,
because
I
know
that
we
in
earlier
iets,
we
discussed
this
and
we
punted
on
the
issue.
But
you
can
see
what's
happened,
which
is
that
it's
scattered
about
in
several
documents-
and
I
like
the
crisp
definition
frankly
of
the
problem
statement
in
debt
net,
and
I
I
personally
believe
that
it
would
be
good
to
emulate
it.
F
G
Yes,
do
you
hear
me?
Yes,
we
do.
Okay
regarding
I,
I
am
very
interested
in
this
draft
or
document
important,
and
I
agree
with
that.
We
need
to
discuss
the
problem
statement
and
the
case
the
use
case
for
this
document
so
because
it's
related
to
the
aw
or
the
raw
technologies
regarding
the
5g.
Actually,
it
includes
technologies
which
are
not.
G
I
haven't
read
the
document
deeply,
but
I'm
interested
to
to
get
a
feedback
on
this
because
usually
when
on
the
documents,
as
for
as
a
title
saying,
raw
technologies,
that
means
it's
the
use
where
we
can
say
the
background
for
us
all
this
working
group.
So
it
needs
to
be
very,
very
well
read
and
very
well
commented
on.
Thank
you.
G
E
E
H
E
So
yeah,
so
if
if
we
could
get
a
slight
update
from
the
wi-fi
side,
that
would
be
wonderful
and
then
we
would
and
if
we
have
to
eliminate
this
piece,
which
is,
could
be
moved
the
one
on
scheduling,
then
let's
finalize
the
document
and
then
you
can
do
your
review.
I
mean
let's
agree
and
what
exactly
what
move
we
do
and
once
we've
done
those
moves.
Yes,
let's
figure
the
review
please
and
that
will
really
appreciate
your
risk.
You
call
us.
A
Okay,
so
what
that
sounds
like
to
me
is
at
the
last
ietf
we
discussed.
Was
this
ready
for
last
call?
I
think
we
still
don't
think
it's
ready,
because
there's
questions
over
the
problem
statement.
There's
questions
over
the
wi-fi
and
I'm
going
to
raise
a
question
in
my
presentation
as
well,
so
I
think
we're
close,
but
we're
not
there.
Yet
that's
what
I'm
hearing
but
yeah
more
comments
to
the
list.
E
I
A
You
can
you
can
buy
a
little
bit
of
time.
We
we
actually
have
more
than
10
minutes
spare
at
the
end,
so
you're,
okay,.
E
Okay,
so
the
first,
the
first
challenge
is
since
today
I
just
published
ocx
very
little
changes,
but
what
you
can
see
on
the
remaining
last,
the
biggest
change
is,
I
invited
lou
because
he
kind
of
indicated
that
he
would
be
interested,
but
it's
not
100
sure,
but
since
it's
still
this
personal
submission,
I
I
did
that
and
I
hope
that
lou
effectively
finds
the
time
to
contribute
and
help
us
here.
E
The
one
thing
I
shared
on
this
slide
is
how
again,
because
of
a
a
requirement
from
lu
in
his
mail,
he
said:
hey,
oh,
I
read,
he
said
you're
describing
a
lot
of
the
cross
layer,
integration
which
we
can
do
on
tach,
very
specifically,
and
not
much
on
what
is
pure
ip
layer,
and
my
intention
was
exactly
the
opposite.
I
think
we
said
when
we
chartered
etc,
that
we
won't
be
focusing
on
one
particular
technology
where
we
could
do
cross
layer
like
thch.
Otherwise
we
would
have
done
that
at
six
dash.
E
E
We
want
to
bring
some
more
dynamics
in
how
we
do
per
packet
control
to
to
trigger
that
net
services
for
one
packet,
but
not
necessarily
the
same
for
the
next
packet,
which
is
basically
this
psc
engine
that
that
we
define-
and
we
also
need
to
define
the
signaling
that
will
enable
the
activity
of
this
psc
engine.
So
so
that's
why
I
added
this
text
really
the
intention
and,
and
now
I'm
checking
with
the
group
that
will
agree.
E
We
are
doing
a
an
ip
layer
layer
to
independent
technology
over
the
top,
and
what
we
are
doing
is
is
controlling
how
we
we
make
the
that
net
services
layer,
that
net
service
layer
operation
like
replication,
elimination
and
we
extend
actually
what
that
net
has
defined
with
barrio
overall
radio
networks.
But
we
could
do
the
same
same
on
non-radio
networks
with
because
we
are
layer
twin
dependent,
it's
more
like
radio
needs
it.
Radio
brings
us
a
lot
of
diversity
that
you
know
pure
point-to-point
wires.
Won't.
A
I
completely
agree
with
you
that
it's
about
providing
an
ip
layer
across
the
possible
layer,
two
technologies
and
I
think,
going
back
to
abjassalam's
point
about
the
technologies
draft.
I
think
the
technologies
draft
should
probably
be
called
underlying
technologies
or
supporting
technologies
because
it
discusses
the
the
layer
two
out
of
which
we
can
build
the
left
or
on
top
of
which
we
can
build
the
layer.
Three.
A
My
comment
is:
I
should
probably
take
it
to
the
list
anyway,
but
pareo.
You
know
the
opportunistic
overhearing
that
may
work
really
well
for
some
link
layers
when
you
can
get
that
cross
layer
communication,
but
I
can't
see
in
things
like
802.11
or
in
5g,
the.
C
A
Ip
layer,
even
getting
access
to
do
to
start
turning
on
radios
into
overhearing
mode,
so
we
have
to
understand
that
that
perio
is
is
a
great
technology.
Overhearing
part
of
pario
is
a
great
technique
when
it
is
possible
from
the
link
layer,
but
with
some
link
layers,
it's
just
not
possible,
but
that
doesn't
prevent
raw,
and
perhaps
it's
just
a
matter
of
changing
some
of
the
wording
slightly
and
I'm
happy
to
suggest
text
which
I
have
been
before,
but
have
failed
to
actually
do
so.
A
I'm
very
sorry
and
I
will-
and
I
will
do
better,
but
I
just
otherwise.
I
completely
agree
because
this
is
the
ietf
we
have.
Our
our
remit
is
link
is
ip,
not
the
link
there
yeah.
E
Carry
on,
I
completely
agree
with
you,
because
it's
the
same
concept
of
barriering
can
be
used,
for
instance,
just
to
give
you
an
example
in
d11
ocb,
where
you
don't
have
the
context
of
a
bss,
and
so
you
are
not
constrained
to
an
association
of
who
sends
and
who
receives.
So.
Instead
of
being
point
to
point
because
of
the
association
which
filters
who
can
talk
to
whom
11p
can
be
multiplied
to
multi-point,
and
so
you
can
effectively
do
exactly
the
exact
same
thing.
A
I
I
am
sure
there
is
link
there
technology
solutions
per
technology,
I'm
just
very
wary
about
producing
link
layer,
specific
solutions.
E
A
No-
and
I
I
could
imagine
doing
something
clever
with
any
cast
and
ip
tunnels
and
effectively
producing
overhearing
using
any
cast,
which
would
be
surreal
but
conceivable.
E
E
Okay,
but
your
point
about
renaming
the
draft
technologies,
I
love
it.
Let's
rename
it
like
an
underlying
technology
or
something,
and
then
please
think
twice
about
whether
this
discussion
on
scheduling,
which
is
really
about
those
technologies,
should
stay
there
or
not.
J
Told
us
go
ahead
yeah,
so
I
think
this
discussion
was
very
interesting
from
the
perspective.
I
would
agree
that
there
shouldn't
be
something
for
existing
link
layer,
specific
technologies.
On
the
other
hand,
these
layer,
2
tool
sets
that
can
help
build
a
better
layer
3
on
top
of
it
might
be
a
good
thing
to
collect,
and
you
know
promote
to
the
layered
technologies
as
they
evolve.
J
K
Yeah
yeah
and
I
was
getting
at
on
the
list.
I
wrote
this
in
jabber
doesn't
seem
like
anyone's
channeling
that
I'm.
K
I
think
there's
a
difference
between
the
architecture
and
a
particular
like
solution
space
framework,
and
you
know
what
what
pascal's
talking
about
here,
I
think,
is
perfect
for
a
particular
solution
space
that,
as
ricky
just
said,
is
within
scope
of
the
working
group.
Now
that
said,
it's
not
the
only
solution,
so
it
doesn't
belong
in
the
architecture
document.
K
So
I
I
really
think
it's
you're
making
the
case
that
we
need
to
split
these,
where
the
architecture
should
be
allow
for
any
particular
solution,
whether
it's
this
heavily
integrated
solution
or
or
you
know,
a
more
traditional
layered
solution,
we
want
to
allow
for
both
of
those,
and
then
we
can
have
frameworks
that
focuses
on
each
of
those.
A
I
I'm
in
a
sorry
I'm
jumping
in
I'm
in
total
agreement
lou,
because
I
think
some
of
the
architecture
is
great
and
really
generic.
You
know
the
pse
concept,
all
that
discussion
about
fast
turnaround
decision
making
as
compared
to
the
much
slower
turnaround
pce
that
highlights
the
need
for
that
control,
plane
protocol
so
that
the
pse
can
understand
what
it's
doing.
A
All
of
that
is
great
and
very
generic,
and
then
yes
for
some
of
the
fine
detail
about
overhearing
and
some
of
the
some
of
the
pareo
techniques
that
may
be
applicable
to
some
link
layers.
If,
given
the
requirements
of
link
layers
to
support
it,
possibly
brought
out
as
we're
creating
more
documents,
but
I
think
we're
not
creating
more
content.
So
I'm
I'm
in
favor
go
ahead.
George.
A
E
Yeah
but
the
intention
even
for
overhearing,
the
intention
was
not
to
be
specific
or
even
integrated.
The
intention
was
to
be
able
to
signal.
Please
pick
these
packets
and
and
have
enough
abstraction
that
it
can
be.
They
are
too
independent.
But
if
we
can
do
it,
it's
fine,
but
the
goal
was
to
to
make
it
viable,
because
I
know
at
least
two
of
those
radios
which
can
do
it.
A
E
Intention
was
not
to
be
specific
to
one
technology.
Certainly
I
mean
since,
since
I
mean
loose
point
at
the
first
buff,
we
kind
of
moved
clearly
towards
the
ipl
iep
layer,
operation
layer
to
independent
blah,
blah
blah
okay,
so
the
architecture
itself
basically
describes
three
steps.
We
we
need
to
learn
about,
and
it's
it's
a
loop
right.
It's
a
per
permanent
feedback
loop.
Where
we
learn
from
oem.
E
We
we
we
make
a
forwarding
decision
for
the
packet
which
is
done
with
this
new
psc
entity
that
we
have
defined
by
selection,
engine
and
and
then
we
take
action
and
the
action
might
be
done
on
the
same
node
where
the
psc
has
run,
or
it
can
be
done
on
a
different
node.
For
instance,
the
pse
could
just
act
as
a
thin
grass
like
there
is
a
full
feedback
loop
from
the
path
through
the
the
egress
back
to
the
ingress.
E
So
the
ingress
knows
how
the
previous
packets
have
failed,
and
so
it
can
make
decision
for
the
next
pack.
Yet
in
that
model
it
would
basically
signal
something
in
the
packet
like
segment
routing
or
something
which
would
affect
the
just
control.
The
the
the
that
net
service
layer
in,
for
instance,
replication,
are
not
d
in
this
picture.
E
E
Ingress
hints
like
I
want
to
get
this
level
of
quality
and
I'm
distributing
this,
this
load
or
the
statistics
to
get
there
to
different
nodes
and,
and
they
have
to
act
on
it-
to
reach
kind
of
a
goal
that
they
are
given
something
more
abstract,
so
that
the
psc,
which
would
be
distributed,
would
have
to
think
about
what
to
do
to
achieve
what's
being
asked.
So
that's
what
I
mean
by
raw
services
to
int
or
control
the
net
service
layer
here.
E
So
yes,
there's
there's
an
extreme
point
where
the
pse
is
fully
distributed,
meaning
that
every
node
is
aware
of
the
oam
and
the
packet
just
contains
the
information
about
the
flow
like
pure.net
information
without
any
sr
v6
type
signaling,
which
would
indicate
the
decision
done
somewhere
else
or
the
hint
from
somewhere
else,
and
so
each
node,
a
b
c
d
on
this
path
would
have
to
make
its
own
full
decision
based
on
the
rest
of
the
way.
So
right
now
the
architecture
allows
all
those
models
just
like
in
the
dead
net
architecture.
E
We
allowed
the
number
of
models,
but
then
we
said:
hey
we're
gonna
go
for
this,
so
here
at
some
point,
even
if
we
describe
all
those
models,
if
we
decide
to
move
on
with
doing
something
we'll
have
to
to
to
discuss
exactly
how,
for
instance,
do
we
really
want
to
do
this
fully
distributed
thing
which
can
be
hard
and
then
so
the
the
the
that
net
service
layer,
white
direct
plane
here,
it's
in
network
plane,
but
it's
called
service
layer
sub-layer
whatever.
E
So
in
the
data
service
layer
we
have
actually
enriched
it.
So
part
of
that
is
two
sparrow
functions
that
we
have
discussed.
There
is
all
the
time
discussion,
which
is
the
presentation
that
jakov
will
be
doing
tomorrow
at
that
net,
and
there
are
all
the
kind
of
hints
and
control
that
we
could
tag
it
from
the
ingress
in
the
packets.
E
So
the
rest
of
the
way
can
can
make
just
flowing
in
there
following
actions
of
also
more
psc
level
determination,
so,
whether
it's
a
hint
and
then
you
have
a
distributed
plc
or
of
pure
control
and
then
in
in
the
intermediate
node.
All
you
need
to
have
is
a
service
layer
which
understands
that
control.
E
So
that's
pretty
much
what
we
want
to
describe
very
abstractly
in
the
architecture
as
it
goes,
we've
done
a
lot
more
than
that,
because
we
don't
have
framework
documents
and
we
don't
have
prime
statement
documents,
so
we
can
have
three
parts.
One
of
them
is
is
read
the
prime
statement.
So
it's
it
was
much
needed
because
we
don't
even
have
a
terminology
without
it.
So
so
we
we,
we
define
the
terminology,
we
define
what
we
mean
by
reliable
and
available.
E
That
was
a
huge
discussion
at
the
buff
and
we
we
actually
decided
to
to
base
the
those
definitions
on
what
nasa
actually
uses
for
the
space
shuttle.
So
it's
you
know
whatever
happened
to
the
space
shuttle.
The
definition
look
good.
E
Then
yeah,
you
know
and
then
use
case
and
recommend
served
here.
We
are
not
dealing
with
specific
use
cases
like
amusement
parks
or
industrial
blah
blah.
What
we
mean
is
really
use
case
in
terms
of
single
hub,
multiple
access
or
more
like
single
technology,
multiple
hubs.
Basically,
so
that's
why
we
have
this
2.3.1
radio
access
protection
in
which
we
discuss
the
first
picture
here.
E
So
we
discuss
oops
this
model.
You
could
have,
for
instance,
5g
and
wi-fi,
and
the
psc
will
define,
decide
whether
to
use
5g
wi-fi
or
both
it's
just
an
example.
But
it
shows
that
if
you,
if
you
can
already
do
it
within
5g,
you
are
going
to
be
able
to
do
it
with
wi-fi
7
as
well
inside
the
technology,
but
it
would
probably
provide
even
better
diversity,
so
better
reliability,
if
you
can
do
it
across
technologies
and
that's
why
going
to
layer
3
is
actually
a
good
idea.
E
So
that's
that's
what
we
mean
in
this
section:
2.3.1,
radioaccess
protection
and
then
2.3.2
is
the
discussion
on
the
wireless
mesh
and
for
this
the
two
examples
are
wi-fi
mesh
and
tach
mesh,
for
which
we
want
to
to
provide
end-to-end,
reliability
and
availability
by
using
multiple
paths,
basically
and
diversity
and
across
all
you
know,
space
diversity,
time,
diversity,
coding,
diversity,
all
the
barrio
functions
blah
true
to
true.
So,
yes,
we
have
still
a
prime
statement,
a
framework
and
an
architecture
piece.
E
What
we
don't
have
right
now
is
discussion
on
not
only
the
the
where
to
forward
to,
but
the
when
to
forward,
which
is
really
something
that
jacob's
document
hints
us
and
effectively.
It
makes
a
lot
of
sense
to
to
signal
that
as
well
as
part
of
the
hints
that
the,
for
instance,
the
ad
end,
the
ingress
could
signal
it
could
effectively
signal.
What's
the
expected
schedule
for
this
packet,
so
the
packet
would
know
if
it's
ahead
of
schedule
or
below,
in
which
case
it
needs
to
be
accelerated.
E
A
Pascal,
can
I
just
jump
in
very
very
very
quickly
there
there's
some
very
similar
work,
that's
happening
in
or
you've
got
a
lot
of
feedback.
There's
some
similar
work,
that's
happening
in
the
dtn
working
group,
which
has
actually
come
out
of
the
delay,
tolerance,
deep
space
work
where
they
have
this
concept
called
contact
graph
routing
where
your
forwarding
information
base
is
augmented
with
contact
times,
so
they
can
know
when
an
expected
adjacency
is
going
to
form.
So
it's
effectively
time
to
tabled.
A
It
works
well
in
deep
space
because
you
know
where
your
probes
are
and
we're
talking
minutes
and
hours,
but
some
of
the
theoretical
work
they've
put
in
to
making
sure
that,
as
is
actually
watertight
and
mathematically,
sound,
could
be
reused.
A
useful
reference
point
I'll,
try
and
send
you
some
urls
and
and
if.
E
E
Is-
and
they
know
exactly
when
the
link
comes
up
when
the
thing
goes
down
now,
the
the
thing
is
with
with
those
radios
we're
talking
about
it's
more.
It's
more
dealing
with
uncertainty
than
dealing
with
certainty
like
there
are
certain
that
the
link
will
come
up
at
this
time
and
that
it
will
go
away
at
this
other
time.
We
are
completely
uncertain
that
the
next
packet
will
fly
through
on
this
link,
so
we
actually
leverage
blindly
a
lot
of
diversity
to
cope
with
the
unknowns
that
caused
this
loss.
E
So
there
there
is
a
link
between
the
two.
I
don't
know
how
far
it
can
go
or.
A
E
A
E
Is
something
coming
just?
I
just
wonder
how
far
I
want
to
take
this
architecture,
but
I
can
see
why
this
intuition,
you
have
in
mind.
I
can
see
how
interesting
it
is.
It's
really
interesting.
Okay.
So
there
was
the
discussion
of
splitting
architecture
framework
on
the
mailing
list
with
lou,
and
then
we
just
said.
E
Maybe
splitting
prime
actually
that's
kind
of
what
I
did
when
I
restructure
405,
which
is
I
I
basically
put
together
the
first
sections
on
prime
then
our
next
section
on
framework,
as
you
can
see
section,
3
and
section
4
and
architecture,
I'm
not
100
sure
how
I
mean
you
still
need
to
be
able
to
read
something
in
the
right
order.
So
you
don't
have
to
go
back
and
forth
between
things.
E
If
you
have
three
documents,
how
can
we
make
sure
people
read
them
in
the
right
order
and
don't
have
to
to
go
across
all
documents
that
that
might
be
a
bit
tricky
and
then
I
was
just
wondering
if,
if
you
guys
think
we
have
a
path
to
adoption
and
what
needs
to
be
done
on
the
path
to
adoption.
A
C
A
That
so
we
have
a
charter
item
to
get
this
done
and
I
think
it
makes
sense
prior
to
working
on-
and
I
know
the
ads
agree
on
this
prior
to
working
on
actual
implementations.
We
need
to
have
a
clear
idea
of
what
we're
building,
how
we're
building
it
and
why
we're
building
it.
So
that's
the
problem
statement,
the
the
analysis
of
the
technologies
and
the
general
architecture
so
yeah.
A
I
think
a
document
some
part
of
this
document,
whether
it
gets
split
or
whether
it
exists
as
one
will
prob,
ought
to
be
adopted
by
the
working
group.
A
G
Actually,
if
I
want
to
read
this
document
and
give
comments
on
it
or
I
need
to
make
sure
I
read
the
requirements
and
use
cases
documents,
so
I
was
expecting
to
listen
to
the
requirements
documents
first,
which
was
in
the
end
of
the
agenda
today,
but
usually
this
document,
in
my
opinion,
is
the
architecture
that
should
be
considered
or
looked
at,
or
indeed
after
we
decide
the
requirements
for
the
one
documentary
the
requirements
for
the
industry
and
the
other
is
the
use
cases
which
has
the
same
author,
mr
bhaskar,
and
I
thank
mr
maskal
very
much
for
his
participation
and
more
than
one
document
actually.
A
We,
the
intention
of
the
working
group,
is
not
to
perform
not
to
produce
a
formal
requirements
document
but
to
describe
the
problem
space
which
may
be
this
problem
statement
document
or
the
problem
statement
may
be
enclosed
in
another
document
to
describe
the
use
cases
which
is
driving
the
work
and
yes,
you're
right.
The
the
structure
is
not
entirely
clear.
Yet
none
of
these
documents
are
a
working
group
last
call.
A
None
of
them
are
ready
for
publication
and
we
are
still
massaging
the
the
ordering
and
and
how
they
are
held
together,
but
you
make
a
very
valid
point,
so
I
agree
so
pascal
is
that
everything,
because
I'm
watching
the
clock-
and
I
think
that's
covered
all
the
time.
E
A
E
A
Excellent
and
then
we
can
come
back
to
this
at
the
end,
we've
got
a
bit
of
open
mic
time
at
the
end,
so
we
can
certainly
discuss
as
a
working
group
where
we
think
we
are
in
terms
of
the
various
things
that
get
presented
following
that,
which
is
why
it's
I
thought
it
was
relevant
to
have
a
bit
longer
on
that
piece
eve.
Do
you
have
a
comment.
B
Except
that
we
probably
need
to
stick
to
our
schedule
a
little
bit
I'll.
B
Just
that
was
a
great
discussion
and
totally
worth
it.
A
But
you're
right,
I'm
watching
the
clock
on
this
one.
So
I'll
jump
straight
on
to
my
fairly
quick
presentation
on
dlip
and
what
it
means
for
the
raw
working
group.
Can
you
see
those
slides.
A
Thank
you,
you're
breaking
up
a
little
bit
eve.
Sorry.
B
A
Okay,
so
what
is
d-lab
so
d-lab
is
the
dynamic
link
exchange
protocol.
It
is
defined
in
rfc
8175,
and
that
is
a
standards
track
rfc.
So
this
is
a
standard.
This
isn't
an
informational
or
experimental.
A
It
was
originally
developed
to
as
a
building
block
to
solve
problems
within
the
man,
a
remit,
but
having
built
it
its
uses,
I
think,
go
much
further,
particularly
of
interest
to
raw,
so
I'm
going
to
run
through
a
very
quick
overview
of
what
ddep
is
and
what
it
does
and
then
get
on
to
where
I
think
it
ties
into
the
work
we're
looking
at
within
this
working
group
and
how
it
might
be
able
to
help
us.
A
So
at
the
simplest
level,
d-lab
is
a
it's
a
monitoring
protocol
that
runs
I'm
pretty
much
reading
the
slides
and
I
apologize.
So
it's
a
monitoring
protocol
that
runs
between
a
rooting,
layer,
3
device
and
its
locally
attached
link
layer.
A
Wireless
device
in
the
terminology
referred
to
as
a
modem,
and
it
allows
that
modem
to
say:
hey,
I'm
doing
stuff
at
link
there,
I'm
discovering
terminals
as
they
come
online.
I'm
monitoring
the
links,
I'm
running
my
own
control
plane,
but
here
is
the
information
I
know
so
you,
the
router,
can
do
cleverer
things
because
I'm
giving
you
understanding
of
what
the
link
layer
is
doing
so
there's
a
critical
component
to
this,
which
is
it
isn't
an
over-the-air
protocol.
D-Lab
does
not
run
over
the
wireless
medium.
A
What's
your
signal
to
noise
ratio,
whatever
it's
a
live
protocol
which
allows
the
modem
to
have
a
richer
conversation
with
the
router
about
the
state
of
the
wireless
network,
since
it
was
published
in
2019
and
since
then
it's
got
good
adoption
within
the
radio
and
network
vendors,
so
your
usual
router
guys
have
implementations
most
of
them.
I
don't
think
juniper
does,
but
I'm
sure
someone
will
correct
me
a
lot
of
the
radio
manufacturers.
A
Simply
because
it's
an
open
standard
and
it
allows
these
large
agencies
to
avoid
vendor
lock-in.
So
they
can
avoid
buying
a
big
vertical
solution
from
one
of
your
well-known
vendors
and
they
can
start
to
cherry-pick
radios
and
routers
from
people
who
make
really
good
routers
and
people
who
make
really
good
radios
rather
than
people
who
target
the
defense
industry.
So
from
a
customer
perspective
they
like
it
and
it
seems
to
it
seems
to
work
for
them
and
it's
an
okay
technology.
A
I
mean
I
disclaimer,
I'm
one
of
the
authors
of
dlab,
so
I
think
it's
good.
Obviously,
so
what
does
dnap
actually
provide?
Really
it
gives
you
two
things
it
gives
you
reachability
information.
So
when
a
new
radio
device
comes
on
channel,
the
your
local
modem
will
tell
its
attached
router
and
say:
hey
a
new
terminals
come
online.
A
If
you
send
me
ethernet
frames
they'll
pop
out
at
the
other
end,
because
I've
told
you
I
can
do
that,
so
you
don't
need
to
go
and
do
arping
or
pinging
or
polling
or
any
sort
of
oam
ippm
style
stuff
to
work
out.
If
someone
is
on
the
other
end,
the
link
layer
has
already
discovered
it,
because
it's
done
all
its
link,
their
channel
frequency
stuff
that
it
does.
It's
already
worked
out,
so
you
get
an
event
to
say
that
destination
is
now
there
and
these
destinations
are
logical.
A
F
Interested
in
that
raising
your
hand,
did
you
want
to
jump
in
and
comment.
J
A
Okay,
the
other
bit
of
information.
E
Yeah
yeah
rick,
I'm
sorry,
but
to
the
previous
point,
you
were
describing
the
lips
operating
between
the
router
and
the
modem
over
this
ethernet,
which
is
yes,
also
remember
that
the
original
use
case,
but
I've
seen
rfc,
which
I
found
critically
important
where
it's
it
could
actually
be
over
something
logical
like
over
a
tunnel.
The
one
where
you.
A
Yes,
I
I
can.
I
can
touch
on
that
at
the
end,
I've
intentionally
kept
this
fairly
simple
and
fairly
to
the
point
but
yeah
at
the
basic
level.
It's
a
simple
ip
connection.
It
does.
The
the
protocol
runs
over
tcp.
It's
it's
that
simple.
My
point
was
this
is
not
an
over-the-air
oam
protocol.
E
E
E
A
It
uses
gtsm
to
enforce
one
hop
for
the
d-lap
session
if
you
wish
to.
If
you
wish
to
communicate
with
remote
modems
that
are
multiple
hops
away,
you
need
to
go
and
use
another
protocol.
It's
not
designed
for
that,
and
we
did
that
intentionally
because
that's
the
wrong
way
to
think
about
what
dlap
is
for
ddep
is
designed
to
do
one
thing
only,
which
is
give
you
local
information
about
your
local
device.
If
you
wish
to
build
a
big
picture,
go
use.
Another
protocol
dlip
is
an
input
to
that
protocol.
A
A
A
A
I
can
tell
you
what
the
theoretical
maximum
given
the
negotiated
protocol
parameters
we're
using
and
there's
some
other
information,
such
as
the
mtu
quite
useful
for
working
out
how
big
your
packets
can
be
obviously,
and
some
other
things,
such
as
the
resource,
consumption
and
relative
link,
quality,
which
are
a
little
bit
heuristic
and
a
bit
estimated
haven't
actually
resulted
in
particularly
useful
metrics
when
implemented.
But
that's
that's
an
aside.
K
Actually
going
to
comment
in
response
to
pascal's
question
or
comment:
excuse
me,
so
dlapp
is
really
like
lmp
or
link
management
protocol
in
the
optical
space
that
came
out
of
the
c-camp
work
and
in
that
environment.
K
The
solution
does
exactly
what
pascal
says
is
it
collects
information
from
lmp
and
then
that
information
can
be
passed
around
through
gmpls
te
extensions,
so
like
when
I
sent
on
the
list
it
we
can
leverage
what's
been
done
in
the
past,
with
pce
and
t's.
This
is
exactly
what
I'm
talking
about
is
that
exact
approach,
pascal
that
you
were
asking
about,
has
actually
been
implemented
for,
but,
albeit
for
different
technologies,.
A
K
You
know
that
was
a
niche
protocol.
Most
of
those
have
gone
away
with
that
that
came
from
the
days
when
optical
line
systems
or
ols's
were
separate.
Now
they're
integrated
into
the
into
the
routers
with
integrated
photonics,
or
you
know,
tunable
optics,
but
it's
the
same
principle.
How
about?
Instead
of
I
put
the
presentation
together,
I'll
put
it
into
the
architecture
document
with
work
with
pascal.
A
Even
better
okay,
so
I
I'll
keep
going
on
this
one
just
to
keep
quick,
so
key
points.
Dlip
is
dynamic.
It's
I
think
it's
worth
reiterating
this.
Yes,
you
could
probably
just
use
a
standard
management
protocol
such
as
snmp
or
netconf,
to
poll
the
status
of
your
modem
and
get
the
metrics
that
the
that
the
modem
is
already
recording
for
its
own
management
and
monitoring
purposes.
A
A
A
So
that's
the
third
bullet
on
this
page,
which
is
the
link
capabilities,
are
we
define
them
in
terms
that
make
sense
to
a
router?
So
a
lot
of
the
radios
out
there,
they're
developed
by
very
smart
people
who
know
an
awful
lot
about
radio
technologies
and
their
life
revolves
around
signal-to-noise
ratios
symbol
rates,
bit
error
rates
and
all
this
crazy
physics
stuff
that
I
didn't
study
at
university
and
translating
that
into
something
a
router
can
make
sense
of
is
not
obvious.
A
This
gives
you
a
mechanism
where
both
link
layers
are
starting
to
report
their
capabilities
and
characteristics.
In
consistent
metrics,
so
you
can
now
compare
radio
mesh,
a's
values
to
radio
mesh
b's
values
because
they
are
both
agreed
on
what
those
values
mean.
It's
it's
really
handy
for
an
implementation
detail.
A
Okay,
so
dlip
is
also
extensible,
so
the
rfc
8175
describes
the
dlap
core
protocol,
which
includes
the
extension
mechanism.
The
core
protocol
is
the
general
protocol
session
establishment
security
announcement
discovery
all
that
good
stuff
and
then
the
actual
capabilities
and
information.
It
defines
a
small
common,
subset
and
a
mechanism
to
say
hey.
I
do
this
extra
standardized
extension
and
it
describes
how
one
standardizes
them
through
the
ietf
or
it's
possible
for
other
seos
to
do
it.
A
This
is
iana's
bread
and
butter,
so
extensions
can
be
introduced
after
the
release
of
8175
without
having
to
produce
d,
lab
v2,
dfv3,
dlip,
v4,
etc.
So,
there's
a
bunch
of
extensions
that
are
being
worked
on.
Currently,
a
d-lap
is
worked
on
in
the
money
working
group
which
will
be
meeting
on
friday
for
those
of
you
who
want
to
deeper
dive
into
into
working
on
d-lab
extensions.
A
There
is
going
to
be
a
big
discussion
there,
including
luca
and
lou,
and
myself,
some
of
the
extensions
that
are
going
on
at
the
moment,
so
there's
a
layer,
3
extension.
So
when
you're
this
touches
a
little
bit
on
what
pascal
was
mentioning,
you
can
treat
a
layer,
a
set
of
layer,
3
tunnels
such
as
an
nbma
vpn
network,
where
you
know
you're,
building
ipsec
tunnels
in
a
sort
of
sd-wan
solution.
A
There
is
also
another
extension
to
allow
you
to
talk
about
credit
based
flow
control,
so
you
can
rate
limit
the
amount
of
data
you're
battering
your
wireless
network
with
it
gives
the
modem
the
ability
to
push
back
against
the
router
and
say
hey
slow
down.
My
my
radio
medium
just
cannot
handle
that
gigabit
of
data
you're
shocking
at
me.
A
There's
also
some
interesting
work,
which
is
actually
lou
is
working
on,
which
is
to
do
with.
Instead
of
just
talking
about
the
logical
link
between
different
destinations,
but
to
subdivide
that
logical
link
into
different
traffic
classes
and
flows
and
to
talk
about
so
if
you've
got
a
radio
that
does
some
clever
things,
the
priority
based
queuing,
you
can
specify
some.
A
This
is
starts
to
become
of
interest
to
raw,
so
you
could
have
a
debt
net
style
traffic
classification,
where
you
have
the
time
sensitive
data
and
the
best
effort
data,
and
then
you,
your
dlab,
capable
modem,
could
say
this
tsm
style
time.
Sensitive
data
has
the
following
properties,
but
my
best
effort
is
just
it's
kind
of
currently
running
at
about
this
rate,
because
that's
how
much
spare
time
I
have
in
my
channel
allocation
or
my
tdma
cycles
or
whatever
there's
some
there's
an
extension
coming
out
to
actually
reflect
some
of
the
basic
radio
properties.
A
This
is
more
interesting
in
manet
than
I
think
in
raw,
but
it's
coming
out
and
there's
some
work,
which
I'm
still
trying
to
get
sorted
about
a
number
of
things,
such
as
pim
for
multicast.
There's
the
concept
of
rendezvous.
Point
selection:
it
makes
very
little
sense
to
elect
a
node
in
a
mesh
network
by
a
leader
election
using
node
id
and
picking
the
lowest
mathematical
number.
A
If
the
link
layer,
if
you
select
your
rendezvous
point
without
an
understanding
of
the
topology
that
the
link
layer
is
building,
you
can
choose
a
very
bad
rendezvous
point
very
simple,
very
easily,
but
I'll
go
into
a
lot
more
of
that
information
in
melee.
So
this
is
the
important
point.
Why
is
this
useful
to
raw?
A
So,
unless
the
underlying
link
layer
network
does
tsn
already-
and
if
it
does
that's
great,
you
can
say
hey
low-level
ieee,
tsn
or
or
5g
or
whatever
go.
Do
your
thing,
because
I
know
you
will
support
it
and
therefore
I
can
agree
with
the
constraints
that
are
applied
on
me
as
the
path
selection
element.
A
So
implementations
currently
exist
using
dlip
to
provide
stability
in
mayonnaise.
So
again,
it's
using
that
pushback
from
the
modem
to
understand
what's
actually
happening
in
the
radio
environment
in
order
to
provide
stability
in
these
really
ad
hoc
networks.
That
same
mechanism
can
be
reused
to
provide
determinism
in
much
more
controlled
environments,
so
factory
floor
or
amusement
parks.
A
There's
a
d-lab
has
a
dirty
little
secret,
which
is
the
link
characteristics
request,
which
is
an
unused
or
underused
function
which
allows
a
router
to
make
a
request
back
to
the
modem
to
say
I
know
this
logical
link
is
only
running
a
14
megabits
and
has
200
milliseconds
of
latency
on
it.
I'd
really
like
it
to
be
100
milliseconds,
and
I
really
want
a
bit
more
bandwidth
and
the
modem
has
an
opportunity
to
try
and
apply
that
using
whatever
link
their
technology
it
has
available
or
to
refuse
it.
A
It
can
say
you
know
you're
not
allowed
to
do
that
for
policy
or
physics
won't.
Allow
us
to
do
that
because
we're
in
a
tunnel
or
whatever,
but
this
could
be
the
it-
could
be
a
useful
mechanism
in
a
raw
context
for
the
path
selection
element
to
say,
I'm
being
requested
to
pin
down
a
track
with
these
criteria.
Hey
modem,
can
you
do
this,
so
this
is
something
I
think
is
worth
exploring.
But
again
I
think
protein
are
offline
and
have
an
extended
discussion
if
needed.
A
A
A
My
other
question
is:
do
we
see
any
raw
requirements
that
might
require
an
extension
to
delap
to
be
written?
So
are
there
things
that
a
pse
would
like
to
use
the
d-lap
protocol
to
do
that
are
currently
not
in
the
scope
of
d-lab?
A
So
is
there
some
way
that
it
would
be
like
to
write
a
d-lap
extension
which
allows
a
radio
sub
a
radio
system
to
say,
hey?
I
have
a
tsm
capability
and
it
is
described
as
blah
blah
blah.
That
would
be
a
very
obvious
deal
up
extension.
So
a
a
raw
capable
rooting
network
device
would
be
able
to
talk
to
a
an
attached
modem
over
a
d-lap
protocol
and
deal
and
over
that
protocol.
It
would
learn
that
hey
that
radio
I'm
attached
to
has
a
has
a
has
a
tsn
function.
So
great.
A
Let's
use
that
and
let
the
radio
go.
Do
the
tsn
stuff,
meaning
the
psc
doesn't
have
to
worry
too
much
about
all
the
perio
functions,
because
the
link
there's
doing
it,
which
is
great.
B
We
have
a
couple
of
folks
in
the
queue
we
are.
B
On
time,
so
I
would
ask
them
to
be
very
concise
and
carlos.
I
know
you're
you're
next
in
the
speaking
queue
for
the
presentations.
So
particularly,
if
you
could
ask
your
question
quickly,
that'd
be
great.
H
Sorry
sure
very
good
question
and
I'm
I'm
familiar
with
the
lab,
so
my
my
question
may
make
no
sense,
so
I
apologize
for
that.
But
what
is
that
about?
I
I
wondering
about
the
use
of
the
lab
for
oim
in
general.
I
don't
know
if
something
was
done,
but
applicability
in
raw.
I
think
that
that
could
be
useful
as
well.
A
It's
something
it
hasn't
been
addressed
in
monet.
It's
something
I
obviously
see
it's.
I
I
think
working
with
some
of
the
oam
ippm
link
sensing
hop
by
hop
stuff
as
compared
to
the
path
stuff.
I
think
it
has
definitely
has
a
path
to
a
part
to
play.
So,
instead
of
having
to
run
om
end
to
end,
you
may
find
some
segments
within
that
path.
Maybe
d-let
capable
and
you
might
be
able
to
effectively
spoof
the
oam
ippm
style
probes
across
that
link
very
interesting.
A
J
Internalists,
if
you
could,
I
think
this
is
a
deal,
is
just
one
example
of
you
know
exchanging
between
the
layer
three
device
and
they
the
underlying
layer
too
right.
So,
if
yeah,
I
think
the
group
wants
to
be
architecturally
clean.
There
should
be,
you
know,
a
protocol,
independent
definition
of
the
information
that
for
raw
is
of
interest
to
be
exchanged
and
then
an
instance
of
that
can
be
done
with
dlab.
But
if
architectural
clarity
and
that's
exactly
the
tool
set,
we
were
talking
in
before
about
right.
C
A
J
And
it's
also
very
much
abstracting
from
let's
say
only
tsns,
the
only
known
you
know
subnet
technology
that
provides
functionality
right
so
that
abstraction
doesn't
really
exist
so
far.
J
Well,
but
devnet
is,
by
now
from
the
service
fairly
limited,
and
I
think
that
raw
is
a
lot
more.
You
know
dynamic
with
respect
to
bandwidth.
Even
with
respect
to
you
know,
probabilistically
defined
latency,
as
opposed
to
only
you
know,
100
bounded,
so
I'd
be
careful
in
raw
to
constrain
yourself
to
only
what
is
currently
within
scope
of
that
net.
A
I
agreed
there's
a
feedback
loop
with
debt
net,
so
the
raw
chairs
meet
with
the
debt
net
chairs
every
two
weeks
and
I
see
quite
a
healthy
feedback
and
lou
is
about
to
jump
in
and
contradict
me.
But
but
yeah
we
see
that
as
we
can
kind
of
push
back
into
debt
net
and
say,
you've
got
to
think
bigger
because
we're
thinking,
bigger
and
we're
very
much
part
of
the
deterministic
family.
A
B
I
would
like
to
be
considerate
of
the
amount
of
time
for
our
last.
C
C
B
Would
like
to
cut
the
queue
and
take
some
of
the
questions
to
the
mailing
list
and
or
the
chat
window.
A
B
H
F
H
H
So,
as
you
know,
we
have
the
different
use
cases
covered
in
this
document,
I'll
they
are
listed
there
on
on
the
slide
and
for
each
of
the
the
use
cases.
Basically,
we
we
follow
the
following
structure.
So
far
we
describe
describe
the
use
case,
the
specifics,
the
challenges,
the
need
for
wireless
and
then
the
requirements
for
raw-
and
this
leads
to
the
next
and
important
slide,
the
one
that
I
wanted
to
discuss
today.
H
That
is,
on
the
one
hand
well,
there
have
been
not
many
updates
since
last
its
cycle,
and
I
take
the
blame
for
that
I'll
apologize
I'll,
try
to
to
do
more
more
or
update
the
content
for
the
next
before
the
next
atf,
and
for
that
one
thing
I
need
is
of
course,
input
from
the
working
group.
Remember
that
this
document
is
for
the
working
group
now,
so
I'm
just
trying
to
get
the
consensus
and
put
that
in
the
document.
So
please
provide
input.
H
But
in
addition
to
this,
one
thing
that
we
discussed
last
time
is
that
we
have
to
collaborate
and
align
a
bit
the
terminology
with
the
raw
architecture,
one
the
document,
so
I
I
will
be
in
contact
with
the
guys
working
on
the
other
already
in
the
other
document,
to
ensure
that
and
another
thing
that
we
must
ensure,
based
on
the
agreement
that
we
had
in
the
last
itf,
is
that
this
use
cases
document
is
basically
also
including
the
requirements.
That's
something
that
was
discussed
and
agreed
last
time.
H
H
That,
I
think,
is
a
very
interesting
document
that
is
specific
on
the
requirements
for
industrial
kind
of
use
case
or
a
scenario,
and
there's
been
some
discussion
on
the
main
list,
whether
we
should
incorporate
even
a
compressed
version
of
those
requirements
in
the
use
case,
since
we
have
requirements
in
the
use
case
document
or
to
merge
or
to
not
to
do
anything
or
do
an
any
other
thing.
H
I'm
perfectly
fine,
of
course,
with
any
decision
that
we
take,
I'm
probably
more
inclined
to
the
the
option
that
pascal
suggested
about
including
a
compressed
version
by
leaving
the
other
document,
leave
and
be
published
as
an
independent
document
with
all
full
details.
But
I
think
for
the
also
for
the
for
the
com,
the
consistency
of
the
use
cases
and
requirement
document.
We
need
to
to
include
some
part
of
a
compressed
version
of
this
of
it
in
the
use
cases.
C
H
H
Okay,
so
if
there
are
no
questions
with
these
related
use
cases,
then
let
me
move
into
the
second
part.
There
is
individual
submissions
about
rohan
and
mech
multi-access
edge
computing
as
rick
introduced
in
the
in
the
presentation
or
in
the
in
the
shared
slides
at
the
beginning.
So
I
will
not
go
into
the
details.
This
is
just
more
to
trigger
discussion
or
to
gather
whether
there
is
interest
in
this
kind
of
work
in
in
the
raw
working
group.
H
We
believe
that
there
are
use
cases,
as
also
documented
in
the
use
cases
document
that
that
justify
this
kind
of
integration
of
row
and
edge
computing,
and
there
may
be
things
to
consider
both
at
the
itf
side
and
the
etsy
in
this
case
for
mec
site
to
to
do
this
integration
and
the
idea
will
be
whether
to
explore
the
atf
side
of
those
things
in
in
atf
or
not.
H
So
there
are
two
documents
so
far,
the
first
one
that
is
the
draft
bernardo's
raw
mec,
that
is
about
extension,
to
enable
this
integration
or
the
use
of
raw
technologies
in
a
in
a
mech
environment,
make
deployment
and
then
the
second
one,
which
is
about
a
more
specific
point.
That
is
how
to
enable
the
terminal
to
to
do
the
selection
of
the
in
which
mac
hosting,
which
server
at
the
edge
to
deploy
an
application
and
configure
the
raw
network
connecting
that
at
the
same
time.
H
So
the
idea
we
have
in
mind
is
that
we
have
a
network
with
draw
enable
nodes
and
mec
h
platform.
Its
point
of
present,
whatever
you
want
to
call
it
in
in
etsy,
mag
will
be
net
platforms,
are
collocated
or
attached
to
these
raw
nodes
that
are,
of
course
connected
via
multi
multi-hope,
wireless
and
ibs.
H
That,
in
this
scenario,
we
of
course
want
to
enable
low
latency
to
applications,
and
we
may
have
multiple
platforms
and
we
may
have
applications
that
may
need
to
migrate
from
one
platform
to
another
platform
and
those
are
connected
wirelessly,
and
this
is
where
raw
getting
gets
into
the
picture.
Because
by
using
a
raw
technology
or
raw
deployment,
we
will
be
able
to
ensure
the
raw
requirements
that
they
make.
H
Applications
requires
not
only
from
the
beginning
when
you
instantiate
from
the
beginning
or
at
the
beginning
of
the
application,
but
also
when
you
need
to
migrate
an
application
due
to
whatever
change
in
the
network.
So
that
is
the
basically
the
the
starting
point,
and
this
is
the
the
simplest
scenario
that
we
have
in
mind.
H
With
that
in
mind,
we
started
working
into
a
potential
solution,
but
this
is
just
more
for
food
for
thoughts
in
terms
of
whether
this
makes
sense
or
not,
by
having
a
pro
a
specific
entity
in
the
mech
platform.
That
is
what
we
call
a
controller.
That
is
basically
the
one
computing.
What
needs
to
be
done
or
to
be
requested
to
the
raw
pc
on
the
on
the
atf
row
side
of
things,
to
enable
and
to
configure
the
network
between
the
raw
nodes
in
order
to
volunteer
the
requirements
of
the
mac
application.
H
The
draft
includes
procedures
for
doing
things
like
initial
make
application
requests
when
we
have
an
application
and
we
want
to
deploy
the
application,
ensuring
the
characteristics
for
that
traffic
flow.
How
to
do
this
and
how
to
interact
with
the
raw
pce
and
do
things
and
then
two
other
two
procedures
that
are
interesting
from
the
iam
side.
H
One
is
when
we
have
raw
iim,
triggering
or
or
informing
about
a
change
in
the
raw
network
that
may
have
an
impact
on
the
make
application
and
that
may
trigger,
for
example,
a
migration
from
a
mech
from
an
edge
server
to
another
one.
How
to
integrate
this.
That
makes
sense
in
a
scenario
like
this,
and
the
other
way
around,
that
is
to
use
the
information
that
make
oam
may
be
collecting
also
to
influence
on
the
raw
configuration
on
how
to
update
the
raw
configuration
on
the
ronit.
H
F
Do
you
think
you
could
wrap
up.
H
C
H
One
minute,
so
what
I
wanted
to
say
that
this
another
document
is
about
a
more
specific
point.
I
will
not
go
into
the
details,
because
my
main
point
is
about
the
scenario
not
about
the
solutions
yet
and
then
the
the
summary
or
the
wrap
up
is
whether
the
question
will
be
whether
the
working
would
think
that
there
is
interesting
in
exploring
this
kind
of
use,
cases
and
integration
of
technologies
and
to
ask
for
feedback
on
the
main
list.
That's
that's!
That's
it
from
message.
A
C
A
Think
this
is
personally.
I
think
this
is
really
interesting
work.
I
think
it's
a
little
early
to
to
work
on
detail,
but
as
a
use
case
for
how
we
want
to
use
what
we're
trying
to
do
in
raw.
I
think
it's
really
important
the
ability
to
if
we
build
interesting
raw
networks
that
apply
this
determinism,
the
ability
to
export
that
information
out
to
systems
that
use
it
and
to
take
feedback
from
those
sort
of
consumer
systems,
whereas
edge
computes,
be
whatever
vital,
really
useful.
H
A
So
it's
rooter,
isn't
it
excellent?
I'm
sure
I'm
not
pronouncing
your
name
right.
A
M
Okay,
we
are
so
thanks,
so,
first
of
all
rink,
and
if
thanks
for
the
last
minute,
accept
us
on
this
okay
and
basically
just
to
give
a
quick
overview,
because
I
think
there
is
a
confusion,
okay,
which
I'd
like
to
clarify.
M
So
in
terms
when
we
did
this
draft
so
me
matias
and
paulo
what
we
felt-
and
we
did
look
into
the
use
cases
draft-
was
that
we
needed
some
information
about
current
current.
Let's
say,
services
that
are
being
or
could
be
supported
by
wireless,
so
the
idea
was
actually
okay.
We
have.
We
are
having
wireless
being
integrated
into
industrial
environments,.
M
That's
where
I'm
looking
mostly
but
the
other
colleagues
are
looking
into
other
scenarios,
and
we
have
different
flavors
of
wireless
that
we
spoke
about
today.
That
are
important
for
raw.
But
the
fact
is
that
we
didn't
have
really
a
concrete
measure
in
terms
of
requirements.
Sure
everybody
speaks
about
bounded
legacy,
but
that
was
mostly
it
and
so,
in
our
case,
okay,
the
motivation
was
okay.
We
know
that
the
the
wireless
infrastructure
is
going
to
be
integrated,
of
course,
into
the
the
overall
infrastructure
that
we
have.
M
This
means
right
now
interconnected
to
5g,
fig
core
or
interconnected
to
ethernet,
with
tsms
and
therefore,
let's
say
our
boundaries
were
okay.
How
can
we,
which
requirements?
Can
we
have?
How
can
we
collect
these
requirements
in
different
services
so
that
what
we
built
on
wireless
on
detunistic
wireless
really
meets
what
we
have
on
the
wired
part,
and
so
in
terms
of
the
structure,
what
we
created
was
we
looked.
M
We
gathered
from
different
sources,
looked
into
current
services,
so
meaning
we
also
looked
into
use
cases,
but
we
actually
went
to
the
services
itself,
so
there's
a
distinction
between
a
use
case
and
the
service,
and
basically
we
collected
around
30
services.
We
grouped
them
into
different
categories
with
concrete
communication,
kpis
so
latency
sure
but
others,
and
then
we
said
okay.
So
that's
basically
what
we
have
today,
what
what
is
going
to
happen
then
discussing
okay-
and
this
is
more
a
point
of
view-
sort
of
individual
from
the
authors.
B
B
A
A
A
M
M
Yes,
okay,
no
actually,
the
next
one,
sorry,
okay!
So
basically
the
structure
is
still
quite
simple.
No,
no
prior
sorry
rig
right
slightly;
okay,
so
basically
it's
quite
simple.
I
said
so.
Basically,
we
collected
services
that
run
or
are
where
wireless
in
in
this
case
is
really
short
range.
Wireless
is
mentioned,
okay,
and
then
we
also
divided
on
at
least
three
examples
of
services
that
we
think
are
coming
in
the
in
the
short
run
and
there,
of
course,
we
do
work
similar
to
the
work
that
was
done
for
the
use
cases,
but
for
services.
M
M
So
here
you
have
an
overview
of
the
services
that
we
collected
and
the
sources,
even
though
that
is
not
completely
on
the
draft.
We
have
a
report
which
later
can
be
shared
okay
from
a
project
really
explaining
where
the
services
come
from
the
different
sources
next
slide.
Please.
M
And
so
what
you
have
on
this
slide
is
basically
the
collected
information.
Okay.
So
what
did
we
collect,
and
so
this
of
course
goes
for
the
regular
reasons
why
we
need
wireless-
that's
quite
important,
okay
in
particular,
with
manufacturing
and
then
so,
the
regular
kpis,
okay
latency,
but
also
whether
traffic
is
periodic
or
not
the
cycles.
If
available
that,
we
need
okay
to
support
the
payload
size,
tolerance
to
packet,
loss,
time,
synchronization
needs
and
whenever
possible,
also
aspects
such
as
no
density
or
an
area
next
slide.
Please.
M
M
So
it's
not
an
equipment
and
process
control,
use
guys
it's
actually
a
category
of
services
that
we
have
there:
okay
and
the
services,
for
instance,
control
of
machines
and
robots
or
plc
programmable,
logical
controller
to
plc
communication,
and
so
this
to
say
that
these
are
not
use
cases
okay,
so
they
are
services
and
of
course
we
can
integrate
them
into
the
use
cases.
But
there's
a
distinction
next
slide.
Please.
M
Okay,
so
it's
infrastructure
mode,
but
we
believe
the
other
part
is
necessary
and
then,
if
we
go
there,
what
which,
which
aspects
we
have
to
account
for
and
also
try
as
much
as
possible,
to
provide
specific
apis
next
slide,
please
so
in
terms
of
next
and
last
slide.
Okay,
so,
basically,
as
said
what
we
are,
what
we
have
collected
was
a
bunch
of
applications
and
it
would
be
great
to
grow
this
database.
Okay
and
categorize
them
provide
specific
apis
it
so
I
said
within
merge
or
not
merge.
M
This
is
something
that
is
so
it's
not
a
personal
or
individual
perspective.
Okay.
This
is
something
that
we
have
been
asked,
often
and
often,
and
often,
and
I'm
doing
a
project
at
several
projects
on
deterministic
wireless,
and
then
we
have
the
same
problem,
which
is
okay,
but
where
are
our
kpis
okay
and
so
the
question
of
course,
for
next
steps
is,
is
the
regular
one.
M
This
requires
work,
it's
just
the
first
version,
okay,
but
the
question
is
okay:
should
we
collaborate
with
the
draft
on
use
cases
and
what
I
try
to
alert
to
on
the
mailing
list?
Is
that
sure?
But
we
would
like,
as
far
as
possible,
okay,
if
everybody
agrees
to
keep
a
more
objective
structure
than
just
debating
on
the
cases
we
have
and
actually
build,
create,
kpis
and
and
with
with
specific
sources
and
again
alert
that
we
are
focused
on
on
services,
not
use
cases.
M
Of
course
this
can
be
merged,
because
the
use
case
has
a
bunch
of
services
inside,
but
so
adding
a
condensed
version.
I
quite
frankly,
don't
know
how
that
fits.
Okay
from
the
three
authors
we
discussed
when
we
started
this
work,
just
to
say
that
this
actually
I've
been
in
contact
with
if
it
got
delight
because
I've
covered
another
stuff.
So
this
is
not
for
now
it's
a
document
that
we
have
been
creating
over
the
last
year,
and
so
we
did
take
a
look
into
the
use
cases
document.
M
Okay
and
we
decided
to
go
ahead
with
an
individual
draft
because
we
felt
there
was
something
missing.
Okay,
I
actually,
I
think
I
raised
this
discussion
also
a
bunch
of
miles
ago,
okay
and
despite
the
fact
that
I'm
not
active
in
raw
I'm
listening.
So
there
are
the
reasons
for
for
in
terms
of
time,
so,
but
in
other
words,
I'm
open
and-
and
of
course
this.
This
has
to
go
to
discussion
and
to
merge
the
document,
but
so
our
our
idea
was
okay.
This
is
on
the
charter.
M
Rick
today
said:
okay,
the
charter
charter
is
being
defined
redefined,
but
it
is
our
belief
that
we
need
a
document
like
this
in
the
community
and
in
raw.
Thank
you.
A
Thank
you
ruta.
I
think
this
is
a
very
useful
and
a
very
in-depth
analysis.
I
think
it's
really
helpful.
So
thank
you,
as
I
said,
to
carlos
the
the
how
we
tie
this
with
the
use
cases
is
very
much
open
for
debate.
I
agree
with
both
of
you.
A
I
don't
want
to
lose
this
detail
and
adding
it
all
to
use
cases.
May
unbalance
the
use
cases
document
having
it
as
a
separate
document,
I
think,
is
incredibly
useful,
but
we
need
to
be
able
to
draw
the
two
together
in
some
way
in
cross-reference,
definitely
a
discussion
for
the
mailing
list.
But
yes,
I
personally
not
with
my
chair
hat
on.
A
I
personally
think
this
is
a
great
document
and
we
need
to
adopt
it
and
make
it
work
for
us
in
terms
of
our
grand
scheme,
for
how
we're
trying
to
make
our
documents
make
sense
for,
as
for,
as
everyone
keeps
saying,
for
the
for
the
fresh
reader
who
comes
along
in
five
years
time,
these
things
have
got
to
be
accessible
and
work
out
how
to
do
it,
but
thank
you
very
much
to
you
and
your
team.
That
was
really
good.
Thank
you.
B
Yes
and
thank
you
for
the
detail,
I
wholeheartedly
agree
that
this
level
of
detail
is
immensely
helpful.
G
Already,
but
at
least
we
discussed
this,
so
we
can
think
in
the
future.
How
about
the
technologies
and
the
documents
already
the
technology
document
and
regarding.
G
Maybe
after
we
we
decide
to
adapt
the
requirement
document
and
this
document
or
the
use
case
document
and
this
one
we
can
then
think
about
other
technologies
or
the
nick
and
dealer,
and
actually
I
will
add
also
that
dlip,
in
my
opinion,
is,
is
one
of
the
technologies
regard
needed
by.
G
So
it
can
be
included
some
information
in
the
technology
document
regarding
dlip
how
it's
used
or
how
it
can
be
used
with
other
technologies,
or
something
like
that,
and
also.
G
I
will
not
forget
that
I
thank
stan
for
the
deal.
He
was
the
first
part
of
this
and
we
forget
because
we
have
been
passed
away.
You
know
so
we
will
never
forget.
You
he's
done
a
very,
very
perfect
job
on
this
document
and
I
have
commented
on
it
and
he
was
very
nice
there
and
I
think
also
rick
knows,
and
he
or
he's
one
of
the
important
authors
also
so
dealer.
In
my
opinion,
it
will
help
a
lot
in
our
this
working
group.
So
I
hope
also
that
rick
will
do
some.
G
You
know
a
draft
or
something
like
extension
for
this
working
group,
because
it's
different
from
man
I'm
one
of
the
best
participants.
A
Case
it's
a
different
environment.
Just
just
to
note,
thank
you
abdusanam
just
to
note
the
use
cases
document
is
a
working
group
document,
so
we
have
already
adopted
that
so.
B
I
I
want
to
thank
everybody
for
their
presentations
and
I-
and
I
also
want
to
thank
whoever
it
is
who's
taking
the
notes
whose
names
are.
B
Oh
I've
been
following
the
notes
and
they've
been
extensive
and
wonderful,
so
whoever
is
taking
this.
Could
you
please
add
your
name
and
or
names
to
the
top
of
our
notes.
We
have
a
lot
of
terrific
detail
there
and
we're
at
the
top
of
the
hour,
so
we're
going
to
have
to
take
some
of
this
discussion
to
the
mailing
list,
although
we
try
to
encourage
discussion
throughout.
So
thank
you
all
for
your
participation.
I'm
almost
awake.
A
On
that
note,
I
will
add
my
thank
yous
as
well.
Thank
you
all
very
much.
I
think
that
was
really
useful.
I
will
attempt
to
be
in
gather
dot
town
normally.
I
would
be
somewhere
near
a
bar,
but
I
still
have
to
be
near
a
virtual
bar,
so
I
shall
try
and
look
there
for
the
rest
of
the
day
in
and
out
of
meetings.
So
please,
if
you've
got
questions
or
comments
about
raw.
I
sometimes
know
what
I'm
talking
about.
A
I
often
don't,
but
I'm
very
happy
to
talk
to
you
anyway,
so
you'll
find
me
as
rick
taylor
wandering
around
as
a
little
ascii
art
avatar,
but
otherwise,
thank
you
very
much.
We
will
raise
I've
made
some
notes
on
questions
to
take
to
the
list
and,
as
usual,
if
you
think,
we've
missed
anything
or
you
have
any
further
comment.
Please
use
the
list.
We
we
do
all
watch
it
and
thank
you
very
much
for
participating.
B
And
I-
and
I
would
say,
though,
if
you
have
some
comments
that
have
been
in
the
chat
that
you
would
like
to
reemphasize,
please
do
add
those
to
the
notes
as
well.
Yes,.
A
B
Them
we've
been
trying
to
integrate,
but
please
add
there
as
well
the
it'll
be
open
for
quite
some
time.
The
notes.