►
From YouTube: IETF109-RAW-20201116-0500
Description
RAW meeting session at IETF109
2020/11/16 0500
https://datatracker.ietf.org/meeting/109/proceedings/
B
Yeah,
I
think
the
uk
has
the
uk.
Has
it
worst
this
time,
because
I'm
I'm
one
hour
behind
europe,
so
it's
5
a.m.
For
me,
but
you're
right,
europe
can't
complain.
We,
I
think
somebody,
I
think
was
lou
berger,
did
some
analysis
on
relative
time
difference
to
ietf
conference
times
and
it's
easiest
for
europe.
B
I
think
it's
it's
hardest
for
west
coast
us
and
places
like
japan
where,
for
one
of
the
meetings,
it's
a
16-hour
time
difference
or
something
crazy.
Yes,
anyway,
shall
we.
C
D
B
So
good
good
evening,
good
morning,
everybody
welcome
to
session
one
of
our
etf
109.
So
this
is
raw,
reliable
and
available
wireless.
Given
it's
a
virtual
conference,
I
am
assuming
people
haven't
just
wandered
into
the
wrong
room
by
mistake,
so
you
do
intend
to
be
here,
and
you
are
all
very
welcome.
I
will
attempt
to
turn
slides
and
see
the
screen
at
the
same
time.
B
There
we
go
so
as
usual.
This
is
an
itf
meeting,
which
means
it
is
covered
by
the
note.
Well,
I'm
hoping
you
have
all
read
a
note
well
before.
If
not
here
is
a
short
summary,
the
boilerplate
text,
if
you
wish
more
information,
the
ietf
holds
lots
of
information
about
the
note.
Well,
then,
I
suggest
you
go
and
find
full
information
on
it
and
check
how
it
applies.
To
you
page,
two
important
note:
this
session
is
being
recorded,
so
any
comments
you
make
will
be
held
for
posterity.
B
This
isn't
a
blame
culture,
it's
actually
for
the
education
of
those
who
couldn't
make
it
they
get
a
chance
to
listen
to
this
again
during
their
normal
working
hours.
So
straight
on
to
the
administrivia
we
are
using
meat
echo.
Hopefully
you
are
all
using
meat,
echo
too,
but
I
know
some
people
are
only
listening
to
the
audio
stream
and
jabber
as
well.
So,
as
we
said
before,
we
started
the
session.
B
B
So
ethan
has
kindly
said
that
he
will
happily
type
away,
but
it's
a
collaborative
environment.
So
please
everyone.
If
you
want
to
make
sure
your
comments,
have
been
recorded
correctly.
Please
jump
into
cody
md.
The
link
is
on
the
screen.
It's
also
accessible
through
some
useful
shortcut
in
the
muteco
ui
itself
and
please
add
extra
comments.
Correct
your
name
is
a
common
thing
to
do,
because
we
all
get
over
excited
and
talk
very
fast.
B
B
That's
because
it's
a
pdf,
I'm
afraid,
but
the
pdf
materials
are
available
as
part
of
all
the
meeting
tools,
so
you
can
find
the
links
there
afterwards,
as
usual,
we
have
a
mailing
list
because
we
are
a
working
group,
so
hopefully
you're
subscribed
to
that.
If
not,
please
do
for
it's
the
correct
place
for
itf
discussion
as
as
ever
and
as
I
mentioned,
the
meeting
materials
are
all
available
on
the
raw
data.
Tracker
page,
so
you
can
find
them
there
so
straight
on
to
the
agenda
eve.
Do.
A
We're
in
the
middle
of
our
intro-
hopefully
it
won't
take
too
long,
but
to
give
you
a
sense
of
what's
coming,
we've
got
pascal
up
first
to
talk
first
about
the
technologies
draft,
which
was
formally
adopted
between
the
last
itf
and
this
one,
and
that
will
be
followed
by
the
architecture
draft
which
is
getting
fairly
mature.
So
there'll
be
some
discussion
about
how
mature
it
is.
A
We
also
adopted
the
use
cases
draft
which
carlos
will
give
us
a
brief
update
on
its
status,
not
a
lot
of
changes
there
since
the
last
time,
but
some
of
what's
coming
ahead
or
some
of
the
issues
that
are
open
niels
will
report
out
the
third
of
the
drafts
that
was
formally
adopted
at
the
last
ietf,
which
is
on
the
ldax
technology
and
finally,
fabrice
will
report
to
us
about
the
oam
draft
which,
between
the
last
ietf
and
this
one
was
as
recommended
and
agreed
to
by
both
the
debt
networking
group
and
the
raw
working
group.
A
It
was
split
into
its
respective
parts.
But
of
course,
given
that
the
authors
straddle
both
groups,
there's
harmonization
between
them
and
we
do
have
a
little
bit
of
extra
padding,
which
of
course
we
always
need.
So
in
fact
we
have,
I
think
in
it.
It
says
10
minutes
here,
but
we've
got
about
25
minutes
to
spare
beyond,
what's
listed
here,
so
really
kind
of
35
minutes
for
discussion
next
slide.
Please.
A
And
if
you
were
to
look
back
at
the
milestones
that
were
enumerated
in
the
charter,
the
first
of
the
milestones
was
to
produce
and
adopt
a
use
cases
document.
I
think
we're
right
on
on
task
for
that.
A
There
was
also
a
requirements
draft
that
was
mentioned
in
the
charter,
which
has
really
been
replaced
by
the
technologies
draft
and
in
fact
the
requirements
have
become
part
of
the
use
cases.
Internet
draft
and
the
technologies
is
kind
of
an
overarching
document
which
we'll
hear
more
about
in
the
session.
A
Our
other
milestones,
you
know,
if
you
look
at
what's
coming
up
for
you
know
this
month,
we
have
stated
that
we,
you
know,
perhaps
the
use
cases
documentary
would
be
ready
to
submit
to
iesg
we'll
have
some
discussion
about
whether
we
think
that
is
really
the
case
or
not,
but
additionally
we'll.
We
should
really
should
be
discussing
at
this
ietf
whether
the
architecture
framework
document
is
almost
there.
I
think
we're
close
december.
We
wanted
to
submit
that
technologies
draft
to
the
iesgen.
A
Again,
I
think,
after
we
hear
from
pascal
we'll
have
a
better
sense
of
how
some
of
the
authors
and
and
us
audience
members
feel
about
its
maturity
to
meet
that
goal,
to
submit
it
in
december,
and
you
know
the
thing
that
we're
really
headed
towards
as
a
working
group
is
this
draft,
which
would
be
the
evaluation
of
all
of
the
existing
ietf
technologies
in
a
gap.
A
Analysis-
and
you
know
we
really
can't
get
to
that
until
we
have
these
three
other
documents
completed,
and
so
it
it
appears
at
the
moment
that
december
was
a
little
bit
over
ambitious,
but
we're
not
far
off
we're.
Maybe
you
know
you
know
again.
It
depends
on
these
three
other
documents
that
are
kind
of
foundational
documents
around
use
cases,
technologies
and
architecture,
as
well
as
some
of
the
other
ones.
A
That
actually
aren't
in
these
milestones
that,
hopefully
we
will
add
to
the
milestones-
and
we
can
have
some
discussions
about
when
would
be
appropriate
time
frames
to
tie
ourselves
or
at
least
project
that
that
they
should
appear
on
this
list.
So
you
know,
and
then
obviously
these
these
last
couple
of
milestones
were
about
the
submission
of
these
things
to
the
iesg,
and
all
of
that
is
contingent
on
things
getting
mature
enough.
So
well,
we
will
have
some
discussion
about
all
of
these.
You
know
where
we
are.
A
I
would
say
that
you
know
just
at
10,
000
foot
view
we're
probably
about
six
months
away
from
four
to
six
months
away
from.
Maybe
these
the
last
document
and
we'll
just
have
to
see
how
that
plays
out.
B
So
can
I
just
quickly
jump
in
here
as
rick
again,
one
of
the
key
steers
we've
been
getting
from
the
ads
is
this
is
not
a
document
writing
working
group,
so
the
steer
we're
getting
is.
Please
don't
spend
two
and
a
half
years.
Writing
lovely
rich
documents
about
the
problem
before
we
get
trying
to
solve
some
of
the
problems.
B
So,
although
we
understand
that
it's
important
to
define
our
use
cases
and
really
understand
the
gaps
that
are
existing
and
it
would-
and
it
is
great
to
have
these
things
documented-
we
don't
want
to
spend
many
years
producing
lovely
documents
and
nothing
else.
So
we
want
to
move
on
to
proposing
protocols
to
solve
some
of
the
problems.
But
of
course
we
do
understand
that
we
have
to
define
the
problems.
Hence
these
milestones
are
pretty
you
know.
These
dates
are
pretty
tight.
B
We're
talking
about
september
november
december
this
year
and
understand
obviously
covet
has
made
everything
a
bit
more
difficult
and,
of
course,
until
you
actually
start
breaking
down
these
documents
and
understanding
the
problem
space,
you
don't
really
have
a
good
estimate
of
how
long
it's
going
to
take,
but
we
don't
want
to
see
these
data.
We
don't
want
to
be
having
this
discussion
this
time
next
year
with
2021
written
where
2020
is
written
now
and
still
not
actually
have
any
of
these
documents
finished.
So
that's
that's
my
little
two
cents.
E
B
Okay,
so
as
you
I'll
just
jump
back,
one
slide,
as
you
can
see
that
there
is
a
a
charter
item
to
say
that
there
should
be
it's
the
fourth
one
down
that
there's
a
in
november.
We
should
the
working
group,
adoption
of
architecture,
framework
aspects
for
a
wireless
network
document,
so,
of
course
the
charter
is
written
as
the
working
group
forms.
So
it's
the
view
from
march
april
whenever
it
was
this
year
rather
than
current
understanding.
So
pascal
has
got
an
individual
draft
talking
about
architecture
and
framework
aspects.
B
B
Are
they
looking
to
get
these
things
adopted,
or
were
these
proof
of
concepts
and
and
the
the
working
group
was
quite
a
good
place,
just
to
get
some
review
and
feedback
so
some
open
questions
with
my
chair
hat
on?
Personally
speaking,
I
think
it's
great
that
people
put
forwards
individual
drafts
here
are
some
concepts,
it's
a
great
forum
to
get
some
feedback
and
I'd
really
like
it
to
continue
to
be-
and
I
quite
understand
sometimes
having
put
a
bit
of
work
in
you
realize
yeah.
B
B
So
that's
a
that's
another
consideration
there
about
draft
adoption
and
the
other
slide
I've
got
is
about
draft
submission,
so,
as
eve
covered
in
the
charter
milestones,
we've
got
some
fairly
aspirational
dates
for
getting
the
use
cases
and
the
technologies
documents
off
to
the
iesg
for
review
and
formal
sign
off
pretty
quickly.
B
So
this
is
a
question
really
to
the
authors
and,
of
course,
to
the
working
group:
let's
not
go
to
the
isg
until
we
think
it's
ready,
so
the
question
is:
do
we
think
it's
ready
and
that's
that's
an
open
question
and
something
to
think
about
during
the
presentations
coming
up
and
perhaps
something
we
can
discuss
at
the
mic
and
on
the
mailing
list
after
this
session?
Okay,
so
that's
it
from
me
eve.
Do
you
have
anything
else?
You
want
to
add.
F
B
B
Brilliant
thank
you
right,
so
I
can
only
show
slides
and
not
see
meat
echo
at
the
same
time,
which
is
a
bit
annoying.
So
it's
pascal
first,
I
believe.
H
I
It
was
there,
I
was
hearing
you,
but
when
I
wanted
to
speak
and
then
I
lost
the
button
which
allows
me
to
share
so
which
one
is
okay,.
I
B
B
H
I'm
still
in
queue
for
I
can
see.
Okay,
I
can
see
you
in
the
queue.
I
B
B
F
I
I
I
So,
yes,
thank
you.
If
we
we
you
introduced
it
and
and
yes,
we
we
published
as
a
zero
zero.
I
So
there
are
not
big
news
for
this
draft,
since
we
introduced
the
the
5g
code,
the
text
last
time
so
for
newcomers,
I'm
just
just
a
quick
reminder
of
what
this
document
is.
So
basically,
this
document
illustrates
the
progress
that
has
been
done
on
a
collection
of
radio
technologies,
and
that
includes
wi-fi,
six
and
and
seven,
which
is
upcoming
15
for
tsch.
I
That's
where
six
displays
5g,
now
that
we
have
the
the
new
section
by
yanash
and
ldax,
which
will
be
also
discussed
separately
during
this
meeting,
which
is
air-to-ground
and
air-to-air
communication
for
planes.
So
all
those
technologies
have
a
very
interesting
feature
that
they
can
be
scheduled,
meaning
that
you
can
reserve
bandwidth
for
critical
flows
and
ensure
a
degree
of
reliability
and
possibly
warranty
latency,
it's
not
always
the
case,
but
you
can
provide
some
some
latency
guarantees
based
on
scheduling.
I
I
So
the
document
was
adapted,
it's
published
as
a
draft
etf
and
well.
We
did
work
quite
a
bit
as
a
personal
submission
and
you
find
there
are
many
authors,
so
it
was
a
mini
workgroup
document
before
it
was
officially
won.
I
mean
there
was
enough
people
like
a
group
of
people
working
on
this
document.
I
So
yes,
as
if
said
it's
already
pretty
already,
the
the
big
question
to
the
group
and
it's
gonna
be
on
the
next
slide
is:
do
we
have
the
exact
structure
that
the
group
wants,
because
what
it's
all
about
is
providing
a
structure
which
illustrates
what
the
technology
is?
What
the
documents
come
from.
You
know.
We
want
to
make
sure
that
the
open
standards
blog
because
the
atf
doesn't
want
to
work
on
proprietary
stuff.
I
I
So
we
have
those
three
main
sections
and
they
have
been
there
since
the
inception
of
this
document,
now
5g
came
last
and
as
as
you
can
see
on
the
right,
I
have
put
the
the
structure
of
the
5g
section
and
you'll
find
that
5gb
has
introduced
this
section
6.3,
which
is
not
in
the
general
framework
that
the
other
section
has
followed
about
deployment
and
spectrum.
I
I
was
wondering
if
we
want
street
equality
on
all
sections,
in
which
case
we
would
ask
the
the
authors
of
the
individual
section
of
technologies
to
provide
a
similar
section,
something
like
6.3.
So
so
that's
basically
the
the
big
question
there
for
the
group
today
and
over
the
mailing
list.
Now,
if
somebody
sees
that
there
is
yet
another
section,
that's
missing,
then
it's
it's
time
to
speak
and
then
we
again
will
go
through
the
editors
of
every
section
and
ask
them
to
to
produce
this
particular
section.
I
A
A
D
I
Oh
here
we
are
not
talking
about
ietf
technologies,
where
it's
really
on
the
radios
themselves.
It's
it's.
It
would
be
another
document,
though,.
I
I
B
Oh
perfect,
I
was
going
to
say
just
for
clarification,
there's
a
charter
item
to
do
that
exact
analysis
lou
for
ietf
technologies.
B
D
Well,
I
I
lost
audio
there.
I
don't
know
what
happened.
Yeah
thanks.
I
I
think
you
answered
it
actually,
which
is
it's
not
this
document,
it's
not
the
architecture
documents.
I
went
looking
for
it
in
the
architecture
and
didn't
see
it
either
is.
C
B
Oh
the
little
reload,
so
I
have
a
personal
comment
to
answer
pascal's
question
about:
do
we
have
to
have
the
same
sub
sections
for
every
technology?
B
My
personal
view
is
no,
if
it's
important
and
it
helps
to
explain
the
capabilities
of
the
technology,
for
example
5g.
I
think
believe
it
is
important,
then
sure
have
a
section.
If
it's
not
so
important
for
the
technology,
I
don't
think
we
need
to
fight
for
symmetry,
say:
oh
there,
you
are
missing
this
subsection.
With
this
particular
title.
B
I
It's
a
general
comment.
It
really
helps
now
on
the
specific
of
deployment
and
spectrum
I
mean
for
wi-fi.
We
all
know
right
now
for
wi-fi
six,
especially
it
could
be
interesting
to
have
some
clues.
You
know
to
give
the
group
some
information
about
how
well
of
wi-fi
six
is,
is
fairing
these
days.
Does
it
really
deploy
quickly
and
can
we
expect
to
get
some
services?
I
You
know
widespread
services
and
spectrum
there's
also
a
very
interesting
story
to
be
told,
because
there
is
a
huge
fight
for
spectrum
in
the
for
some
of
those
technologies.
I
Again,
I'm
thinking
about
wi-fi,
you
know
the
six
gig
has
been
granted
and
there's
more
so
maybe
we
could
ask
the
wi-fi
people
at
least
to
give
us
a
6.3
section
ldax.
I
would
be
curious
as
well
to
have
you
know
something
which
which
tells
us
about
what
the
you
know
future
the
projections
are
for
deployment
and
then
is
there
a
chance
to
get
more
spectrum
and
more
bandwidth
in
the
future
of
lab.
I
mean
that
could
also
be
interesting,
so
understand
your
general
command.
B
B
I
think
there's
something
to
be
said
for
given
ldx
has
a
draft
that
this
is
me
with
my
chair
hat
on
now,
ldx
has
a
draft
in
the
working
group.
It's
probably
easier
to
add
that
as
a
section
to
ldx
as
niels
suggests,
rather
than
duplicating
the
text
or
or
having
the
text
living
in
in
two
different
documents,
but
there's
also
a
a
jabber
comment
from
alexandra
petrescu
saying
as
5g
gets
deployed,
I
don't
hear
news
of
5g
features
about
qos.
I
might
be
wrong
how
about
talking
about
6g
as
well?
I
As
alex
says,
there
is
already
a
6g
discussion
list
at
the
atf.
So
if,
if
someone
wants
to
to
talk
to
yanash
and.
F
I
If
they
can
work
together
on
adding
some
6g
int,
we
already
mentioned
the
in
wi-fi
as
it's,
I
think
you
know
projecting
for
the
future,
which
is
like
a
near
future.
It's
not
like
in
20
years
is
of
interest.
I
would
be
happy
to
see
some
some
6g
text
as
well,
just
to
tell
us
where
6g
is
going
in
terms
of
determinism.
I
B
So
so
jumping
the
queue
slightly
myself
rick
again,
I
have
a
question
about
legacy
technologies.
So
from
my
last
reading
of
the
document
there's
a
lot
of
content
about
new
technologies
with
capabilities
that
are
applicable,
there
doesn't
seem
to
be
a
lot
of
information
about
existing
or
or
latent
latency
legacy
technologies
that
and
how
to
manage.
Some
of
that.
Do
you
think
that's
out
of
scope
for
this
document.
I
Well,
when
we
scope
the
document
trick,
we
we
looked
at
technologies
that
can
be
scheduled.
It
looked
like
the
the
common
point
on
technologies
that
we
would
cover,
because
we
we
wanted
to
to
see
if
we
could
push
them
into
bonded
latency.
I
And
so
we
didn't
try
too
much
incorporating
you
know
the
humongous
amount
of
non-deterministic
radios
that
are
around
here.
I
B
That
might
might
be
a
another
work
item
for
the
group
to
as
we
mature
our
proposed
solutions
to
these
things
and
I
spot
shinshan
in
the
queue
to
produce
a
document
saying
for
some
of
these
legacy
technologies
here
are
some
workarounds,
etc.
That
may
work
go
ahead.
Change.
B
J
Yes,
yeah,
I'm
working
in
faculty
in
cpp.
I
have
one
question
for
45g:
now
we
have
the
dedicated
spectrum
to
support
the
5g,
also
for
the
5gt
has
support
wi-fi,
even
satellite,
as
as
a
access,
10
access
technology.
I
don't
know
whether
we
need
a
steel
consideration.
B
Technology,
thank
you.
Pascal,
do
you
have
a
comment.
I
J
Available
for
5g,
they
can
use
a
multiple
path
to
approve
the
reliability
and
throughput.
So
our
topic
is
reliability
and
the
available
one
is.
If
the
multiple
paths
is
used,
they
can
improve
their
mobility.
No,
no,
the
5d
support
mobility.
They
can
support
the
input
of
improve
the
throughput
they
in
can
also
improve
the
reliability.
I
I
mean
that's,
that's
yeah.
We
totally
agree
on
this.
I
mean
that's,
that's
pretty
much.
Why
we're
here
and
the
architecture
as
a
picture
which
shows
exactly
this
right,
wi-fi
on
one
stream
and
5g
on
the
other
stream,
pretty
much
now
for
this
document,
which
is
just
explaining
the
technologies,
would
you
like
to
have
a
section
which,
which
explains
this
work
like
this,
this
integration
of
wi-fi
in
5g?
I'm
not
I'm
not
against
right.
I'm
just
trying
to
understand.
J
There's
also,
I
have
a
feature:
algebra,
reliability
and
low
latency
communication.
They
also
use
the
the
the
second
path
to
improve
the
reliability
and
the
throughput
to
download
their
latency.
This
means
they
use
the
multiple
radio
station
to
to
to
send,
or
you
see,
with
the
data,
to
improve
the
availability.
I
don't
know
whether
also
this
technology
should
be
considered
in
the
5d
part.
B
So
can
I
step
in
with
my
chair
hat
on.
What's
important
to
remember
is
this
is
the
ietf,
so
we
are
looking
at
engineering
solutions
between
heterogeneous
technologies.
B
What
I
mean
by
that
is
5g
may
have
a
solution
which
will
cover
increasing
reliability
between
satcom
systems,
radio,
aware,
radio
access
networks,
wi-fi
technologies
all
within
the
5g
technology
space,
and
that
that
will
be
great
where
the
ietf's
role
comes
in
is
when
data
leaves
that
bubble
of
technology
and
has
to
transition
across
to
another
network
using
different
technology,
but
from
our
working
group
perspective
still
needs
those
reliability
assurances
those
slas.
B
So,
yes,
I
think
there
is
a
value
in
having
some
more
words
in
the
5g
section
to
say:
5g
is
more
than
just
radio
access
networks
for
for
handsets.
It
also
has
these
other
features
to
talk
about
wi-fi
and
satcom
that
that
people
may
not
notice,
which
may
well
be
useful
for
our
further
work
and
analysis
to
understand.
B
So
I'm
watching
the
time
pascal
you're
eating
into
your
next
presentation.
Does
anyone
else
have
any
more
comments
on
the
technologies
or
shall
we
move
on
to
the
architecture,
discussion.
B
I
think
crack
on
pascal.
There
is
I'm
just
watching
that
there's
some
interesting
stuff
going
on
in
the
jabber
chat,
but
if
you
queue
up
your
next
presentation,
pascal
I'll
just
I
think,
there's
just.
I
We're
here
so
let
me
check
I
was
I
was
actually
presenting
preparing
for
the
next
slide.
I
Well
for
this
one,
the
question
was
mostly
do
do
we
want
to
discuss
what's
the
path
to
adoption
for
this
document
and
and
basically
yes,
I
had
another
slide
which
which
asks
if
we,
if
we
are
missing
a
topic
and
shushan,
maybe
was
telling
us
that
that
could
be
more
a
little
bit
more
in
the
5g
and
and
that's
to
be
discussed
with
the
5g
authors
if
they
want
to
discuss
a
little
bit
more
about
the
integration
of
wi-fi
and
5g
underneath
just
to
let
us
know
that
it
exists,
so
the
the
other
question
I
had
was
if
we
want
more
on
the
on
the
prime
statement
piece.
I
Basically,
but
okay,
okay,
I
mean
the
big
question
is
how
do
we
proceed
to
a
croplasco?
I
I
don't
see
that
we
want
to
change
the
structure
dramatically.
I
hear
from
the
from
this
call
that
we
are
pretty
much
okay,
and
so
the
question
is:
what's
the
path
to
work
up
last
call:
should
we
should
we
already
ask
for
a
reviewer
or
something
to
to
progress
towards
welcome
preschool.
A
Are
there
other
people
on
the
list
and
and
everybody's
audio?
You
don't
have
to
even
put
yourself
in
the
queue
for
us
to
hear
your
audio.
So
if
you
unmute
your
mic
and
you'd
like
to
raise.
B
B
B
A
B
It's
not
a
bad
system!
Actually,
okay,
so
we're
looking
at
about
50
50
from
those
who've
noticed
that
this
or
have
worked
out
how
to
make
the
tool
work.
Okay,
I'm
gonna!
That's
fairly
positive.
I'm
gonna
add
another
quick
one
now,
which
is
who.
B
B
B
Oh
enter
doesn't
work
there
we
go
so
this
is.
Are
you
willing
to
do
a
full
review
of
the
draft
I.e?
You
know
a
review
from
typos
to.
I
don't
understand
this
sentence
to.
I
think
the
section
is
in
the
wrong
place,
including,
I
think,
we've
forgotten
all
this
technology.
You
know
as
as
transcendent
said,
I'm
sorry.
My
pronunciation
of
asian
names
is
not
good.
A
But-
and
so
I
guess
for
ethan's
sake,
since
he
is
helping
us
with
the
notes,
those
of
you
who
have
raised
your
hand
who
are
willing
to
do
that
kind
of
thorough
review.
If
you
could
speak
up,
let
us
know
who
you
are
either
verbally
or
in
the
chat.
That'd
be
great.
B
B
But
so
so
please,
yes,
I
think
to
answer
pascal's
question.
The
next
step
is
people
please.
It
sounds
like
the
authors
think
this
document
is
getting
pretty
stable.
So
now
is
a
great
chance
to
have
a
deep
review
and
then
we
can
make
a
decision
about.
Is
it
ready
for
last
call,
depending
on
the
feedback
from
reviewers
sound
good.
A
B
Okay
right
so
moving
on,
because
I'm
watching
the
time
pascal
go
ahead.
I
Yes,
so
this
is
about
the
architecture
framework
document,
really
it's
it.
There
are
three
documents
in
one,
because
that's
kind
of
a
for
some
things.
It's
a
placeholder
and
one
of
the
things
that
I
would
have
love
to
see
today
or
maybe
another
remaining
list
later,
is
decide
what
stays
in
this
document.
What
goes
away,
what
serves
as
a
seed
for
another
document,
etc.
I
So
the
requirements
are
still
pretty
much
the
same,
and
it
kind
of
boils
down
to
the
use
cases
document
that
carlos
has
discussed
and
we'll
be
discussing
more.
If
we,
if
we
boil
down
everything,
we've
seen
so
far,
I
mean
my
current
understanding
and
the
other
person's
submission
is
that
we
have
two
major
use
cases
in
the
real
world
for
what
we
are
doing.
I
One
of
them
is
a
bit.
I
What
was
sorry,
I
can't
pronounce
your
name,
what
was
alluding
to
when
it's
done
inside
5g,
but
that
could
be
done
at
layer
3
as
well,
and
that's
what
roy
is
about
is
using
more
than
one
access
link
and
and
possibly
of
heterogeneous
technologies
to
achieve
a
more
reliable
end-to-end
transmission,
in
which
case
the
assumption
would
be
that
the
the
radio
link
is
the
one
that
is
the
most
susceptible
of
loss,
and
so
that's
the
one
we
want
to
protect
by
having
redundancy
etc.
I
With
the
helpful
thinking
that
the
rest
of
the
path
has
a
more
fixed
and
bonded
latency
and
whatever
is
behind
it's
wired.
Maybe
it's
that
net,
or
maybe
it's
just
good
enough,
and
and
so
we
we
really
care
about.
What's
hap
what
happens
on
the
on
the
terminal
equipment
on
the
stay
and
how
the
traffic
is
distributed
over
multiple
links
like
this
5g
and
wi-fi,
which
are
illustrated
up
there.
I
So
that's
the
first
case
we
protect
the
radio
access
second
case
is
is
more
complex,
is
when
we're
part
not
of
the
host
but
of
the
rotting
fabric,
and
in
that
case,
what
we
try
to
do
is
build
a
complex
path
that
we
call
a
truck
across,
possibly
a
radio
mesh,
and
so
what
we're
interested
in
is
monitor
what
goes
inside.
I
This
particular
track,
like
the
real
time
operation
of
every
link,
in
that
small,
we
hopefully
small,
track
and
making
a
decision
almost
on
a
per
packet
basis
on
a
per
few
packet
basis
to
ensure
the
dsla
of
latency
and
reliability
that
we
have
for
this
flow.
I
So
these
are
basically
the
two
use
cases
which
seem
to
boil
down
from
the
use
cases,
documents
and
and
from
what
we've
been
talking
about
so
far.
So
they
are
described
in
the
architecture,
it's
more
like
the
the
problem
statement,
piece
of
the
architecture
document
and
now,
if
we,
if
we
miss
some
abstractions
some
things,
we
need
to
look
at
and
solve
in
this
working
group.
Then
clearly,
we
need
to
know
because
we
need
to
add
stuff
to
this
section
now,
the
since
last
atf
and
sorry,
it's
not
actually
published.
I
I
can
publish
it
today,
but
the
document
has
been
through
a
bit
of
reshuffling.
It's
not
really
a
lot
of
new
text,
it's
mostly
yet
another
reorganization.
We
discussed
it
at
the
last
atf.
We
said
hey
this
section
and
this
section
they
seem
to
relate
to
to
the
prime
statement.
So
now
we
have
a
section
two
which
is
the
problem
and
then,
as
if
said,
we
initially
had
a
an
item
on
on
prime
statement,
which
is
now
kind
of
this.
This
section
two.
So
in
the
section
two
we
give
the
terminology.
I
So
if
we
want
to
describe
prime,
we
need
to
agree
on
terms.
What
do
we
mean
by
this?
In
particular,
we
need
to
agree
on
what
reliability
and
viability
means.
So
we
go
into
some.
Some
details
about
this
now
we
we
mentioned,
as
you
can
see
on
the
right,
the
section
section
2.3
we
go
through
the
two
use
cases
that
I
just
presented.
I
So
the
question
to
the
group
there
is
obviously
did
we
meet
miss
like
yet
another
important
situation
that
we
want
to
cover
this
framework,
and
then
there
is
this
section
2.4
that
even
lou
I've
been
talking
about
which
is
kind
of
yet
another
work
item
that
we
had,
which
is
this,
this
positioning,
the
existing
work
at
the
atf
and
positioning,
providing
a
gap
analysis
or
something.
I
So
since
we
don't
have
any
other
document,
I
cannot
use
this
as
a
placeholder,
but
I
didn't
get
to
write
too
much
into
it
and
and
maybe
I'm
not
even
the
right
person
to
write
into
it
now.
The
second.
I
Yeah,
the
door
is
open,
always
been,
but
if
this
goes,
if
this
becomes
a
work
group
document,
then
the
work
group
will
be
entitled
to
do
whatever
it
likes
into
this
right.
I'm
just
not
the
right
person,
probably
I'm
not
an
expert
in
delete.
I
have
some
clues
about
that
net,
but
still
I
mean
some
other
people
who
could
help
a
lot.
I
We
need
text
on
oam
and
and
now
we
have
authors
which
which
work
in
both
row
and
and
that
net,
so
they
could
produce
some
text
on
oam,
etc.
I
mean
there's,
there's
a
lot
that
could
be
done,
for
which
I
would
not
be
the
right
author,
so.
B
That's
when,
at
some
point
sorry
pascal,
it's
rick,
my
suggestion
would
be
that
looking
at
this
section
2.4,
I
think
that's
a
document
in
its
own
right.
I
think
it's
a
charter
item
to
cover
that
and-
and
yes
I
probably
am
a
dlap
expert,
so
I
can
certainly
help
put
some
of
the
text
together
for
that.
B
But
I
wonder
whether,
in
the
architecture
framework
draft,
the
section
two
you
have
here
should
be
much
shorter
and
call
out
to
the
working
group
use
cases
document
the
working,
the
working
group
technologies
document
and
hopefully
the
the
forthcoming
related
work
in.
B
You
know
and
call
out
from
here
so
to
say
this
architecture
framework
is
attempting
to
address
the
problems
that
the
following
problems,
as
listed
in
this
problem
statement
or
or
whatever
to
do
it
as
a
as
a
reference,
rather
than
inserting
all
the
text
in
here.
I
think
it
will
make
the
document
more
manageable.
B
I
I'm
asking
I
mean
we're
copying
agreement.
The
question
is
really
this
section:
two,
that's
why
I
kind
of
structure
things
into
three
blocks
is:
could
we
take
a
block
away,
but
then
it
needs
to
have
a
placeholder,
and
since
there
was
none
so
for
now,
I
I
just
did
it
this
way,
but
I'm
completely
happy
to
to
to
take
some
pieces
off
and
I
just
wanted
to
capture
whatever
I
had
to
make
sure
it
was
written
somewhere
because
right
now
we
don't
have
this
other
document.
I
So
if
we
agree
that
that
we
should
have
a
document
on
related
work
or
a
prime
statement
document,
I'm
not
100
sure
we
need
a
prime
statement.
If
we,
because
we
are,
we
have
the
use
cases
and
we
have
this
introduction
section
and-
and
we
you
know,
if
you
look
at
it
section,
2.3
is
like
one
or
two
pages
section
2.2,
but
I
think
it's
kind
of
important
it
does
two
or
three
pages:
it's
not
huge.
I
Okay,
the
2.4
would
become
huge
if
it
was
done
seriously.
B
And
that's
why
it
should
be
done
as
its
own
document.
It
is
a
charter
item
so.
I
I
You
know
they're,
not
fat.
Are
they.
B
No,
and
I
think
they
have
to
sorry
continuing-
I
think
they
have
to
be
there,
because
you
have
to
scope
this
document,
because
the
the
use
cases
document
is
is
general
and
the
technologies
document
and
the
requirements
they're
quite
general
and
quite
broad,
and
you
need
to
define
them
a
bit
more
accurately
in
this
document
to
say
this
framework
applies
to
these
use
cases
and
and
these
requirements
served.
So
I
think
this
is
quite
as
long
as
they're
short,
I
think,
they're
perfect.
I
think
you
have
to
have
them.
I
Okay,
so
after
that,
we
and
they
never
knew
where
to
go
framework
exactly,
but
because
the
framework
for
me
is
like
all
the
the
contacts
all
the
base,
but
you
know
we
don't
have
a
clear
definition
of
what
framework
is,
but
so
I
get.
I
I
gave
all
the
background
information
in
that
section
three
now
so,
as
you
see,
the
the
existing
document
is
kind
of
repackaged
into
framework
and
architecture,
and
by
framework
here
I
mean
yes,
all
the
backgrounds
so
explaining
what
the
parallel
functions
are
explaining
what
the
tracks
are
explaining.
I
What
can
what
can
be
done
at
the
pc
timescale
versus
what
we
want
to
do
here
so
that
that's
what
section
three
is
now
and
I
called
it
framework,
but
it's
it
could
create
background
as
well
and
I'm
open
to
to
to
any
other
name.
I
And
then
the
section
four
is
what
we
have
now
for
architecture.
So
we
provided
the
model
which
kind
of
inherits
from
the
net
model.
We
discussed
the
psc
the
section
for
that
too,
and
we
discuss
oam
section
4.3.
I
Then
this
discussion
of
flow
identification
versus
path,
identification,
which
for
which,
basically
that
net,
as
as
a
as
a
provision
which
is
not
fully
in
line
with
what
sixties
is
doing,
because
six
dish
has
a
flow
identifier
which
is
separated
from
the
five
tuple.
So
we
kind
of
we
try
to
kind
of
put
that
together.
I
The
key
thing
that
we
want
to
do
here
is
to
to
show
that
we
kind
of
decouple
the
the
path
indication
from
the
flow
indication.
So
if
one
wants
to
multiple
flows
could
be
injected
in
one
path,
if
you
like,
which
enables
us
to
to
to
have
separate
oem
packets,
which
don't
necessarily
have
the
same
five
tuple
or
six
double
and
still
fly
within
the
same
track.
I
So
we
have
the
track
id
and
we
have
the
the
the
flow
id
which
are
kind
of
separate.
Then
we
discuss
how
we
do
the
performing
decision
and
there
are
basically
the
usual
the
two
usual
methods.
I
One
of
them
is
the
source
route,
like
the
ingress
of
this
track
places
everything
in
the
packet
so
that
all
the
nodes
along
the
track
will
know
what
to
do
so.
It's
kind
of
you
know
the
segment
routing
the
source,
routing
type
of
approach,
but
here
it's
going
to
be
describing
not
a
linear
path,
a
to
b
to
c
to
d,
but
it's
going
to
describe
what
happens
on
a
two
two-dimensional
two-dimensional
graph,
so
like
a
dietary
graph.
So
so
there's
some
things.
I
I
It
generates
a
lot
from
sixties,
but
an
enroll
because
there's
a
lot
of
work
happening
at
raw
and
our
document
going
through
the
asg
right
now,
which
from
which
this
document
inherits
as
well
and
then
there
are
the
the
usual
securities
so
right
now
so
since
the
big
change
has
been
reshuffling,
the
section,
the
feedback
you
know
I
would
like
to
see
today
or
on
the
mailing
list-
is
about
the
structure
I
mean.
Are
we
missing
important
topics?
I
I
already
understand
that
2.4
should
go
away
and
I
would
be
happy
to
to
see
that
happen
as
soon
as
you
know,
the
document
shows
up
that
would
change
the
text
for
the
framework.
Are
there
components
that
are
missing
same
thing
or
you
know
whatever
should
go
there
and
for
the
architecture
same
thing
did
I
did
I
do
the
right
restructuring?
I
Do
we
agree
that
you
know
the
what
I
call
section
four,
the
architecture
is
really
an
architecture.
It's
really
what
people
expected
from
this
document.
Is
there
a
a
big
thing?
That's
missing
right
now
we
we
have
the
oam,
the
psc,
the
flows.
Is
there
anything
else
and
then
well?
You
know
at
some
point
I've
done
what
I
could,
because
that's.
F
I
B
A
Maybe
a
next
step
would
be
to
well
first,
this
this
particular
version
is
not
posted,
yet
so,
okay,
but
then
you're
so
really
soliciting
the
feedback,
and
once
we
go
through
that
phase
it
it's
likely
that
we're
we're
one
step
closer
to
asking
for
adoption.
B
So
pascal
rick
here
I
really
want
to
read
the
new
document.
This
is
me
speaking
personally,
I'm
very
happy
to
help
on
this,
because
I
think
this
is
actually
a
really
key
part
of
getting
on
with
doing
the
raw
work.
So
I,
even
if
this
document
gets
adopted
by
the
working
group
and
completely
rewritten
it
has
to
exist,
so
I
am
happily
offering
to
help
get
it
to
the
state
where
the
working
group
is
happy
to
adopt
it.
So
I'm
I'm
offering
help
here.
B
The
sooner
we
can
get
the
the
latest
draft
out
would
be
great.
I
think
it's
very
important
for
the
working
group.
This
is
now
me
with
my
chair
hat
on.
Please
working
group
read
this
document
because
I
think
it
has
a
lot
of
important
introduces.
A
lot
of
important
framework
is
a
good
word.
Architecture
is
also
a
good
word.
B
It
tries
to
set
down
a
lot
of
the
ideas
that
are
being
discussed
informally
in
a
formal
manner
and
if,
if
there
are
concepts
that
are
not
clear
or
are
incorrect,
this
is
the
time
to
to
say,
because
personally
I
think
this
is
the
right
approach,
but
the
point
of
the
working
group
is:
is
it's
not
just
my
opinion?
It's
everybody's
opinion,
so
so
please,
please
read
this.
I
Rick
two
things:
first,
one
is
send
me
your
git
id,
I'm
not
sure
the
whole
group
is
authorized
on
git
on
this,
so
but
does
it
get?
So
that's
that's
easy,
please,
for
the
harder
piece
you
know
I
mean
what
group
adoption
is
not
even
a
guarantee
that
the
document
will
be
shipped
one
day,
but
at
least
it
gives
the
ownership.
For
me,
that's
the
step
where
the
group
says.
I
Yes,
this
is
serious
work
and
then
we
want
to
take
it
over
and
so
and
and
to
get
those
reviews
that
we're
talking
about
and
to
make
the
dates
that
we
want,
which
are
kind
of
aggressive.
I
think
one
group
less
core.
A
So
why
don't
we
say
that
you
post
this
and
people
read
it,
and
we
have
some
that
we
ask
on
the
mailing
list
whether
it's
ready.
F
A
D
Okay,
I'm
now
eating
the
microphone.
I
think
you
know
filling
in
some
of
these
spots
or
at
least
identifying
where
the
gaps
are
would
be
really
helpful
prior
to
adoption,
because
then
we
have
an
idea
of
what
work
is,
is
remaining
and
sort
of
what
we're
signing
up
to.
D
Certainly,
I
don't
wouldn't
expect
the
document
to
be
so
polished
that
we'd
immediately
go
to
last
call.
So
you
know
I
understand,
there's
there's
going
to
be
more
work
to
be
done,
but
at
least
flagging.
What
that
work
is,
I
think,
would
be
helpful
prior
to
the
adoption
call.
D
Yeah
I'd
like
to
I
completely
support
adopting
as
quickly
as
possible,
which
is
why
I'm
I'm
saying,
let's
flag
the
open
issues,
I'm
happy
to
unlist
once
this.
This
version
is
posted,
put
comments
out
there.
Anything
that
I
think
is
missing.
Obviously,
you've
flagged
a
couple
things
like
the
dla
part.
I
think
we're
missing.
You
know
how
we
tie
into
the
rest
of
that
net
and
normal
traffic
engineering
and
normal
layering
concepts.
I'm
happy
to
put
that
on.
D
You
know
in
in
email-
and
you
know
be
more
specific
as
what
I
think
is-
should
be
identified.
B
Okay,
that's
great,
but
I
don't
think
that
should
prevent.
D
Adoption-
and
I
I
think
we
differ
here-
I
I
think
if
this
doesn't
show
the
direction
we're
headed,
then
you
know
personally,
I
wouldn't
support
adoption
without
flagging
those
things.
Okay,.
B
So
I
have
a
suggestion
with
my
chair
hat
on
how
about
the
chairs
pascal
puts
out
the
updated
document
as
soon
as
he
can,
and
four
weeks
after
that,
we
have
a
call
for
adoption,
so
that
gives
everyone
four
weeks
to
read,
review
and
decide
whether
this
is
the
correct
direction
for
the
working
group
to
be
taking
its
work.
Whether
this
document
is
even
if
it's
just
even
if
it's
far
from
perfect
in
a
text
sense
is
the.
B
Is
the
technology
and
approach
correct
that
that
would
be
my
criteria
for
deciding
and
after
four
weeks
we
can,
we
can
make
an
adoption
call.
Does
that
work
for
pascal
and
does
that
work
for
the
working
group.
I
Well,
since
I
was
named,
it
certainly
works
and
what
also
works
is
during
those
four
weeks
lowered.
You
joined
the
document
and
helped
to
contribute
to
species
that
I've
been
missing
because
I
pretty
went
as
far
as
I
knew
and
for
that
net
I
could
add
a
little
bit,
but
you
know
for
tea
and
everything
I
mean
if
lu
would
be
so
much
better.
I
So
if
the
two
of
you
can
can
help
on
this
document
in
this
document
you
know
for
during
those
four
weeks,
then
we
would
have
something
a
lot
more
mature
to
to
give
to
the
group
in
four
weeks.
C
I
D
L
D
I
I'm
sorry
eve.
I
was
not
too
clear
what
lou
told
us.
There
are
two
pieces
where
we
need
work.
One
is
this
architecture
document
where
we
we
probably
want
to
see
how
this
fits
into
the
rest
of
the
the
framework
of
the
atf
like.
What's
the
what's
that
net,
I
have
some
text
a
little
bit
of
text
about
that
net,
that
there's
a
new
text
that
will
be
published
today.
I
You
will
find
positioning
this
work
versus
the
the
the
data
planning
that
net,
but
it's
I'm
sure
luke
can
do
a
lot
better
and
improve
it.
Now,
there's
also
discussion
on
how
that
fits
with
the
the
existing
tooling
like
like
how
would
we
play
with
dilip
or
how
would
we
play
with
other
things
and
and
that
that
has
to
be
split
between
this
new
document
that
we
don't
have,
for
which
I
just
have
a
placeholder.
I
You
know
the
gap,
analysis
and
blah
and
the
integration
of
those
technologies
into
the
architecture
which
would
be
here
so
so,
and
we
need
all
this,
so
you
just
want
to
make
to
to
your
right
orders
to
to
structure
things
and
say
this
goes
there.
This
goes
there.
A
B
So
watching
time
I
think.
B
B
B
F
Okay,
so
hi
everybody,
I'm
carlos
bernardos,
presenting
on
behalf
of
my
co-authors,
the
of
the
use
case
draft
today
in
this
meeting
I
just
wanted
to
do
a
very
brief
presentation,
just
summarizing
what
we
have
and
mostly
requesting
some
some
help
input
from
from
the
working
group.
So
currently
we
have
eight
use
cases
in
the
document
that
are
described.
They
are
the
same
ones
that
were
described
in
the
in
the
previous
situation:
aeronautical
communications,
amusement
parks,
wires
for
industrial
applications,
probably
on
video
wireless
gaming,
uav,
platooning
and
control
edge.
F
What
is
control
and
emergencies,
and
for
each
of
these
eight
use
cases
we
have.
The
following
structure
is
basically
the
same
for
all,
but
for
the
first
one
that
they.
That
is
just
the
use
case
description,
I
think,
is
called
motivation.
So
I
need
to
basically
modify
that,
but
it's
a
very
minor
thing.
So
for
each
of
them
we
have
initial
description,
motivation
of
the
use
case
in
general.
F
Without
going
into
all
the
raw
details,
then
we
go
into
the
specifics
that
are
relevant
for
for
raw
the
challenges
that
this
each
of
the
use
cases
brings
or
poses
regarding
reliability
and
availability
in,
whereas
scenarios
then
a
very
short
subsection
on
the
need
for
wireless,
which
is
pretty
obvious
in
most
of
the
cases,
but
still
is
there
and
then
the
key
section,
in
my
opinion,
for
each
of
the
use
cases,
that
is
the
requirements
that,
as
the
chairs
mentioned
before
these
use
cases
is
not
only
kind
of
filling
the
gap
of
documenting
the
use
cases,
but
also
trying
to
identify
and
enumerate
the
different
requirements
for
the
raw
solutions
that
are
required.
F
So
these
are
the.
This
is
the
current
structure,
and
with
that
in
mind,
this
is
the
key
slide
from
my
side.
Now
this
is
a
working
group
document.
So
basically,
I'm
I'm
here
to
request
input
from
all
of
you
and
I
have
a
set
of
questions.
Of
course,
there
may
be
other
questions
that
I
missed.
There
may
be
other
feedback
that
you
want
to
provide,
and
that
will
be
always
welcome
and
very
much
appreciated,
but
from
our
side
these
are
the
main
questions
that
we
have.
F
First,
one
are
the
use
cases
rather
than
representative.
So
are
this?
Do
you
think
that
we
are
missing
any
use
case?
Do
you
think
that
there
are
some
use
cases
that
are
not
representative
enough
for
the
raw
scenarios?
So
this
is
a
first
question
that
we
would
like
to
get
feedback
on
on
the
main
list.
F
The
second
question
is
basically
related
to
to
the
former
one.
Are
we
missing
anything
that
you
think
we
should
be
documenting,
then,
is
a
structure
that
I
briefly
presented
before
for
each
of
these
cases
appropriate?
Do
you
think
that
maybe
we
need
to
remove
some
things
like?
Maybe
the
the
need
for
wireless
is
too
obvious
and
it's
not
needed,
or
maybe
you
want
to
structure
the
requirements
in
a
different
way.
F
F
So
for
that
we
I
we
have
already
started
some
informal
discussion
with
the
current
authors
of
architecture
document,
so
that
is
not
yet
itf,
but
when
it
itf
document
working
group
document.
So
what
do
we
need
in
the
use
cases
to
help,
then
that
document
do
its
its
job?
That's
a
key
question
that
we
have.
So
what
should
we
cover
that?
Maybe
it's
not
properly
covered
on
the
cover
at
all,
yet
in
the
use
cases
document.
F
So
those
are
the
questions
that
we
would
like
to
get
feedback
from
from
the
working
group
to
help
us
working
into
the
next
iteration
in
the
next
version,
and
that's
it
from
from
my
side
if
rick.
A
A
Probably
we
need
to
reach
out
to
others
in
those
areas
just
to
look
at
them,
for
you
know
kind
of
answer
your
your
question
about.
Are
they
representative
and
relevant?
Are
they
not
so
much?
Is
there
a
use
case
missing,
but
are
the
ones
that
you
have
there?
You
know
captured
well
enough,
so
that
that
was
one
thought
from
a
review
standpoint.
F
Okay,
that's
a
good
point.
So
I'll
try
to
contact
people
from
from
each
of
the
use
case
scenarios
they
were,
or
people
were
involved
for
sure
at
the
when
we
were
doing
it.
For
example,
the
last
one
that
we
added
the
text
was
suggested
by
one
guy
that
was
working
on
on
the
topic,
but
I
will
reach
out
to
people
on
each
of
the
use
cases
and
ask
for
feedback.
I
will
do
that.
Yes,.
B
So
carlos
I
will.
I
will
extend
your
previous
comment,
which
is
this
is
a
working
group
document,
so
working
group
please
reach
out
to
any
subject
matter
experts
you
might
know.
So
if
you
work
with
someone
who
knows
a
lot
about
gaming
at
an
internet
scale,
could
you
ask
them
to
look
at
the
use
cases
on
internet
gaming?
B
Same
applies
to
obviously
I
can
reach
out
to
some
smes
on
uav
swarming,
but
you
know,
can
you
just
have
a
look
at
this
document
review
it
and,
and
if
you
think
you
know
someone
or
or
are
a
subject
matter
expert
on
some
of
these,
please
have
a
have
a
good
look
from
my
perspective.
We
don't
need
a
huge
drill
down
for
every
use
case
becoming.
You
know,
100
page
detailed
essay
about
that
use
case.
We
just
need
to
ensure
that
we
are
capturing
relevant
things
and
our
assumptions
are
correct
rather
than
incorrect.
B
That's
all
with
my
chair
hat
on.
I
think
this
is.
This
is
a
good
document.
It's
focused,
let's
just
get
the
reviews
in
and
make
sure
it's
that
everyone.
B
To
rework
some
of
the
aeronautical
communications
section
in
there
alexandra
petrescu
has
mentioned
about
the
uav
platooning
use
case.
One
of
the
use
cases
is
the
drone
show
using
thousands
of
simultaneous
flying
drones
yeah,
but
unfortunately
these
communicate
only
went
on
the
ground.
Do
we
know
when
these
drones
will
communicate
amongst
them
in
flight?
Okay,
so
without
disappearing
down
a
big
uav
platooning
discussion,
the
aeronautical
use
cases
are
extremely
varied
from
tiny
devices
flocking
to
commercial
aircraft
moving
at
continental
scale
to
let's
ignore
the
whole
military
environment.
B
So,
yes,
we
could
write
a
huge
use
case
just
about
uav
just
about
one
particular
detail
of
uav
swarming.
So
I
think
from
my
perspective,
as
long
as
we
capture
some
of
the
general
purpose
text
without
spending
a
year
working
on
this
document,
we'll
have
would
have
done.
The
right
thing,
pascal,
is
in
the
queue
go
ahead.
Pascal.
I
Yes,
I
just
wanted
to
to
suggest
maybe
some
we
need
a
link
between
those
use.
Cases
which
we
show
or
here
is
where
it
applies
here
is
where
it
applies,
and
the
architecture
where
we
have
basically
selected
two
problems
that
we
are
solving
like
the
excess
and
then
the
the
mesh,
if,
if
there
was
a
way
to
kind
of
glue
those
two
and
and
I
saw,
I
would
see
the
the
conclusion
of
the
use
case
document
as,
as
you
know,
trying
to
extract.
I
B
I
I
completely
agree
pascal.
I
think
that
also
means
a
solid
use
cases
document,
so
the
architecture
document
could
say
referring
to
the
use
cases
rfc
whatever
it
ends
up
being
section
two
and
section
three.
These
are
the
use
cases
we
will
be
addressing
in
this
framework
means
we
can
recharge
a
raw
in
the
future
and
address
different
use
cases
that
are
out
of
scope
for
what
we're
proposing
now
and
the
next
generation
of
smart
ietf
contributors
can
can
solve
the
suite
of
problems
that
we
choose
not
to
solve.
I
Yes,
the
use
cases
at
some
point.
You
need
to
be
turned
into
something
more
abstract
and
more
generic
than
this
plane.
So
so,
for
instance,
you
know
the
need
for
for
other
two
for
multiple
access
is
at
the
same
time
and
that
that's
the
piece
that
I
would
like
to
see
extracted
like
abstract
it
to
a
level
where
we
can
take
it
over.
On
the
other
side.
Now
we
have
two
cases,
two
two
abstractions
that
we
use
like
the
access
and
the
mesh.
I
Are
there
other
abstractions
in
these
documents
that
we
are
not
capturing
in
the
architecture,
and
then
we
decide
whether
we
do
capture
them
or
not,
and
we
do
process
them
or
not
or,
like
you
said
in
the
future,
I
will
do
that.
But
right
now
we
just
explain
the
cases,
but
that's
not
really
turned
into
this
abstraction
of
a
primary
access.
H
F
F
Yeah
yeah,
I
agree
with
that.
Basically,
this
is
what
I
want
to
to
start.
Turning
the
the
requirement
section
at
the
end:
try
to
really
use
that
abstraction
language,
let's
just
call
it
that
way
to
to
be
homogeneous
and
to
make
the
link
with
the
architecture.
So
I
agree
with
that.
F
So
let
me
let
us
try
to
do
a
first
iteration
in
towards
that
direction,
together
with
the
other
feedback
that
we
can
get
in
and
including
the
document,
and
then
we
can
reach
out
to
you
guys
and
and
get
some
comments
from
your
site,
the
architecture,
authors
and
and
try
to
to
see
whether
the
next
version
start
going
into
the
direction
that
you
pointed
out.
I
fully
agree
with
that.
A
Yes,
I
saw
we
saw
that,
thank
you
very
much
given
the
time
or
I
think
we're
done
carlos.
A
Okay,
great,
I
think
next
up
is.
B
A
B
A
And
you
need
to
you
need
to
turn
on
your
mic
as
well.
E
G
Let
me
hear
you
all
right
yeah,
so
I
have
the
same
problem
as
pascal,
but
I
think
I
hope
you
can
see
it's
okay
for
now
yeah,
so
so
welcome
and
thanks
for
joining
for
the
little
update
about
our
aldex
draft.
So
since
last
ietf
there
were
a
couple
of
changes.
So
the
last
time
we
presented
the
version
04
of
the
pre-adopted
draft,
and
now
we
got
it
adopted
and
already
sent
five
updates.
So
we
got
a
huge
amount
of
feedback.
G
So
thank
you
a
lot
for
all
the
comments,
very
valuable
and
here's
the
note.
Well,
I
think
we
covered
that
yeah.
So
this
is
now
where
we're
at
looks
like
that
and
here
the
changes
that
appeared.
So
I
said,
oh.
A
A
G
Okay,
there
we
go
perfect
yeah,
so
the
most
important
part
is
here.
You
can
see
all
the
changes,
so
we
added
about
10
pages
to
the
document
and
we
covered
mostly
the
required
language,
so
the
requirement
language.
So
we
already
changed
all
the
ietfk
keywords
and
then
we
extended
the
terminology,
because
there
is
a
huge
amount
of
abbreviations
and
yeah
terminology
helps
here
then
most
important,
and
because
we
got
a
very
helpful
comment
was
what
are
the
requirements
to
aldex.
G
So
what
is
the
ecosystem
in
which
aldex
will
have
to
be
deployed?
How
does
it
look
like
what
are
the
characteristics
of
that
ecosystem,
so
their
requirements
to
aldex
so
ldx
had
to
be
developed
with
a
certain
mindset
so
to
speak,
and
we
list
them
here.
Then
we
went
really
deep
about
real
reliability
and
availability,
and
I'm
going
to
cover
this
and
talk
as
well
and
then,
lastly,
a
security
consideration.
G
So
we
had
to
rework
the
entire
security
considerations,
page
and
yeah
added
a
ton
of
stuff
here,
because
there
were
some
some
recent
updates
regarding
to
that,
and
also
because
we
had
to
aside
from
aeronautical
sources,
we
included
some
of
the
tables
found
and
they
do
350a,
which
tells
about
the
requirements
for
cptlc
communication
or
adsc
communication,
so
aeronautical
based
communication.
What
are
the
requirements
for
there
and
since
ldex
will
probably
be
used
to
support
these
message
formats?
G
We
had
to
have
a
look
in
there
and
also
add
that
to
the
draft.
So
this
is
all
what
happened
during
the
last
months
here
and
let's
go
a
little
bit
deeper
in
each
section.
First,
chapter:
six
requirements
to
ldex
yeah.
What
is
the
application
area
in
general?
Well,
we
want
to
have
a
data
link
that
can
communicate
information
related
to
the
flight,
safety
and
regularity,
meaning
that
whatever
air
traffic
control,
message
or
traffic
services
or
aeronautical
operational
control
or
any
other
data,
that's
relevant
here
for
flight
safety
and
regularity.
G
That's
been
sent
over
the
link
has
to
be
taken
into
account
and
there
are
some
pretty
severe
requirements
to
that.
As
you
mentioned
before,
message,
errors
have
to
be
taken
care
of
so
that
you
have
a
really
high
reliability
and
yeah
requirements
to
aldex.
Also,
the
challenges
are
that,
because
flying
around
the
world
is
actually
happening
worldwide.
G
Guess
what
and
there's
heavy
regulation
regarding
to
that
and
also
spectrum
scarcity,
because
there
is
a
regulated
and
dedicated
spectrum
available
for
aeronautical
communications,
for
instance,
here
in
the
l-band,
and
the
problem
now
is
that
we
have
a
huge
amount
of
legacy
systems
since
the
30s
or
1930s
in
that
spectrum
and
and
blocking
opportunities
for
new
systems
to
come
in,
for
instance,
here
for
aldex
the
well
most
challenging
thing
was
to
get
the
communication
system
into
a
band
where
the
distance
measuring
equipment-
that's
dme,
are
still
sending
out
radio
beacons
with
the
magnitude
more
power
than
aldex
is
able
to
communicate.
G
So
you
had
to
work
in
between
of
those
bursts,
and
that
means
that
you
have
to
be
smart
to
actually
get
a
little
bit
of
spectrum
there
in
order
to
send
data
and
yeah.
That's
because
data
links
here
in
this
environment
may
only
use
aviation
license
spectrum
and,
as
I
said
before,
it's
pretty
scarce
now
also.
We
have
not
enough
bandwidth
on
terrestrial
data
links.
G
So
if
you
remember
back
in
1978,
the
first
acre
system
was
designed
for
aeronautical
communications,
with
the
use
case
in
mind
that
crews
on
aircraft
had
to
tell
them
whether
they
were
airborne
or
not
so
tell
the
ground,
because
they
were
paid
differently
and
for
that
system.
Acres
was
originally
invented,
covering
2.4
kilobits
of
data.
G
In
90s
there
were
video,
the
vdl
mode
2,
so
the
vhf
data
link
mode
2
was
invented
with
35k
bits
of
data.
Now
aldex
brings
about
2.4
megabits
to
the
table.
So
if
you
think
about
this
evolution,
we're
getting
there
yeah,
then,
because
there's
a
ton
of
different
non
vr
of
specific
data
links,
obviously
4g,
5g
and
and
all
that
stuff.
But
the
problem
is,
for
instance,
5g.
You
can't
really
use
5g
because
you
have
huge
ranges
to
be
covered
and
5g
is
not
designed
for
huge
ranges.
G
4G
you
could
use,
but
the
problem
is
that
it's
just
designed
with
a
different
use
case
in
mind.
So
it's
really
not
applicable
here
and
also
the
security
issues
exist
for
those
data
links
that
way
and
then
for
atf.
It's
probably
most
important
to
remember
that
the
aeronautical
ip
internet
works.
So
there
are
plans
to
integrate
ip
here
into
the
internet.
Work
and
the
internet
should
be
separated
completely.
So
there
shouldn't
be
an
opportunity
from
the
internet
actually
to
access
than
the
avionic
specific
ip
address
range
and
simply
put
in
some
messages.
There
then.
G
Secondly,
objective
of
aldex.
As
we
said,
we
wanted
to
replace
legacy
using
proprietary
acres,
as
I
mentioned
before
this
acres
technology
with
industry,
standard
ip
technology
and
provide
a
next
generation
terrestrial
data
link
designed
to
support
ip
and
provides
a
much
higher
bandwidth.
As
I
said
before.
G
As
of
now,
there's
one
other
data
link
for
terminal
maneuving
areas
and
for
airports
that
is
already
in
use.
G
That's
aeromax
and
aldex
is
then
designed
for
continental
on
route
traffic,
so
appliance
actually
cruise
of
a
continent,
and
this
is
now
or
where
we
want
to
place
zelda
x
and
then
the
requirements
for
aldex
is
this
terrestrial
high
throughput
data
link
and
the
interoperability,
because,
first
of
all,
the
different
new
systems
that
are
coming
into
this
ecosystem,
such
as
aeromax,
as
I
mentioned
before,
or
satellite
data
links
or
ldx,
they
have
to
work
as
a
multi-link
technology
and
the
other
interoperability
is.
G
This
ground
network
has
to
be
connected,
obviously,
with
the
data
link
to
to
the
plane
all
right
about
reliability
and
availability.
So
that's
chip,
eight.
Now
as
the
development
of
ldac
started
a
couple
of
years
ago.
Most
of
this
stuff
is
not
something
new,
but
it's
very
important
to
remember,
because
it
tells
about
a
very
robust
system
design.
G
So
first
we
have
ofdm
based
frequency
division,
duplex
system,
and
it's
deployed
in
this
aeronautical
communications,
restricted,
l
band
and
we
only
have
500
kilohertz
bandwidth,
and
this
is
also
why
we
only
have
this
2.4
megabits
top,
because
if
you
only
have
500
kilohertz
as
pretty
little,
you
can
do.
I
mean
if
you
have
lte
20
megahertz
channels
assigned.
G
Obviously
the
data
rate
could
go
way
higher,
but
the
problem
is
really
the
the
spectrum
scarcity
here
then
another
thing
the
the
guard
times
are
said
to
be
able
to
operate
in
a
200
nautical,
while
range
forward
link
physical
layer
continuous.
So
that
means,
if,
if
the
ground
station
sends
to
an
aircraft,
then
this
ground
station
can
send
at
any
time.
G
But
if
an
aircraft
actually
wants
to
respond,
it
has
to
request
resources
in
bursts
and
send
data
into
bursts,
and
then
the
user
data
uses
adaptive
coding
and
modulation
so,
depending
on
the
channel
characteristics
and
the
quality
more
data
can
be
sent.
But
control
data
is
usually
transmitting
the
most
robust
coding,
modulation,
then
the
neck
layers.
On
the
right
hand,
side
you
see
the
frame
structure.
What
we
see
here
is
a
very
fixed
frame
structure,
so
we
have
super
frames
of
240
milliseconds
magnitude.
G
We
have
a
broadcast
channel
at
the
beginning
of
each
forward
link
so
that
ground
stations
can
exist,
can
announce
their
existence
into
the
world
and
we
have
a
random
access
channel
in
the
reverse
link
where
aircraft
can
request
to
join
a
cell
and
in
between
we
have
multi-frames
and
at
the
bottom
of
the
page
you
can
see
the
multi-frame
is
split
into
data
frames,
so
that's
the
data
channel
dch
and
into
two
different
control
channels
where
resources
can
be
requested
and
allocated,
and
with
this
static
frame
structure
design.
G
It's
a
very,
very
robust
design,
because
you
know
when
each
pilot
symbol
will
have
to
appear.
You
know
the
time
synchronization
rather
well,
and
it's
also
important
to
remember
that
the
entire
resource
management
is
handled
by
the
ground
station.
So
even
if
an
ldxl
is
full
too
many
aircraft
in
a
cell
or
something
it
can
request
a
handover,
so
the
resource,
scheduling
and
management
is
entirely
handled
by
the
ground
station.
G
G
With
that
we
can
achieve
low,
latency
and
low
overhead
without
losing
reliability.
We
also
ensure
the
correct
order
of
packet
delivery.
We
exclude
duplicates,
we
can
identify
lost,
fragments
and
then
with
and
that's
important
deterministic
timers
into
the
medium
access
frame
and
then
initiate
retransmission.
Thus
we
get
fixed
times
of
when
we
could
expect
a
retransmission
to
be
done
successfully
and
we
have
a
priority
mechanism
within
aldex
that
ensures
that
most
important
message
arrive
timely
before
lower
important
message.
G
Yeah
now,
moving
on
to
the
security
considerations,
I
should
have
requested
20
minutes
because
it's
a
lot
of
updates.
So
the
problem
here
is,
as
I
mentioned
before,
akers
was
designed
in
1978
and
since
then
a
lot
have
has
happened,
and,
for
instance,
now
we
have
software
defined
radios.
G
This
year
there
was
a
defcon,
the
aerospace
village,
where,
with
a
300
device,
it
was
shown
how
to
do
dubious
stuff,
and
so
this
changed
that
landscape
is
becoming
more
important
because,
as
I
said
before,
there
are
open
stack
implementations
of
stuff
on
on
github.
We
have
software
defined
radius
nowadays.
So
if
you
want
to
attack
communication
for
an
aircraft,
it's
nowadays
it's
relatively
easy,
and
so
we
have
to
take
security
very
very
seriously
and
we
have
to
embed
security
features
within
nail
decks
already,
and
we
have
to
think
about
that.
G
We
don't
have
too
much
bandwidth.
So
whatever
we
do,
we
shouldn't
just
basically
fill
the
entire
communication
band
with
with
security
data,
and
then
we
have
another
thing
going
on
and
that's
basically
that
the
human
as
a
control
instance
is
going
to
be
taken
out
gradually
out
of
the
loop
so
meaning
we
have
fully
automatic
flights.
G
We
have
drones
landing
automatically
and
so
on.
We
have
4d
trajectories,
so
virtual
points
in
the
air
that
an
aircraft
can
follow
and
so
on
and
all
these
things
have
to
be
at
least
integrity
protected,
so
that
nobody
can
inject
messages
and
so
on
so
strong
cyber
cyber
security
measures
are
a
must
for
aldex
to
become
adopted
by
the
international
civil
aviation
organization.
G
So
here's
is
the
listing
of
lx
security
considerations,
so
it
shall
protect
availability
and
continuity
of
service.
It
shall
protect
the
integrity
and
authenticity
of
messages
in
transit.
It
should
provide
confidentiality
of
messages
and
transit.
It's
important
to
note
that
there's
a
should,
because
we
have
different
messages
on
the
link
and
depending
on
whether
it's
privacy
relevant
or
not.
We
need
confidential
confidentiality
or
sometimes
it
can
even
be
a
problem.
G
If
that
message
has
to
appear,
for
instance,
for
all
pilots
in
the
vicinity
and
everybody
has
to
be
able
to
read
it,
then
it's
only.
It
should
then
should
provide
non-repudiation
for
necessary
messages
in
transit.
So
if
there's
something
that
is
very
important
and
you
shouldn't
be
able
to
repudiate
from
it,
then
you
need
it.
Obviously,
we
have
to
have
mutual
authentication
of
communication
entities,
authorize
the
permitted
actions
of
users
and
deny
actions
else,
and
we
have
to
have
in
the
capability
to
prevent
the
propagation
of
intrusion.
G
So
if
one
ldx
link
from
one
ground
station
to
an
aircraft
has
some
problems,
it
shouldn't
spread
from
that
and
yeah
with
that,
we
gave
a
very
detailed,
I
think,
a
very
detailed
overview
of
the
architectural
details
in
section
10,
5
and
told
about
the
aldex
entities
for
the
security
mode,
and
we
talked
about
trust
about
pkis
in
in
that
environment,
about
entity,
identification
about
authentication,
key
negotiation
and
then
the
message
and
transit
confidentiality,
integrity
and
authenticity.
G
Then
we
moved
on
to
how
this
would
actually
be
deployed
and
how
different
algorithms
come
into
play
and
protocols
and
yeah.
We
started
again
with
the
trust
ejection,
so
we
talked
about,
for
instance,
the
arrow
max
pki,
because
there
is
currently
the
plant.
As
I
said
before,
to
integrate
different
aeronautical
communications
technology
and
the
security
behind
them
into
into
one
system.
G
Then
we
have
the
identity
management
based
on
the
aircraft
identities.
The
problem
is:
each
aircraft
has
an
as
a
relatively
unique
iko
address,
but
the
problem
is
this:
24
bit
addresses
have
been
cloned
before
already.
So,
how
do
you
actually
identify
an
aircraft,
then
certificates
stored
in
the
entities
allowing
then
mutual
authentication
key
exchange
procedures,
and
then
we
need
to
have
a
key
derivation
mechanism
for
perfect
forward
secrecy.
G
That's
probably
more
also
based
on
the
key
exchange
procedure,
for
instance
using
duffy
helmet
here,
and
we
have
to
protect
user
and
control,
plane,
message
and
trend
and
transit,
integrity
and
confidentiality.
Most
important
actually
is
the
control
message,
because
if
resource
allocations
don't
happen
anymore,
somebody
has
successfully
broken
the
system.
So
we
have
to
be
very
careful
in
how
to
protect
the
control
message.
Part
here,
yeah
and
those
were
the
major
updates.
So
thanks
for
my
side,
are
there
any
questions
shoot
so.
B
Rick
here
just
jumping
in
quickly,
because
I,
the
question
has
come
up
before
on-
why?
Why
are
we
handling
this
in
raw
or
the
ietf?
So
the
critical
thing
is
actually
on
this
slide.
It's
the
ldx
is
a
by
the
sound
of
it.
I'm
not
an
rf
expert,
a
a
sensible
proposal
to
keep
aircraft
aircraft
with
the
tower
communications
working
successfully.
B
The
important
thing
I
think
that
niels
mentioned
is
at
a
certain
point.
These
ip
packets
may
not
flow
to
the
internet,
but
will
be
flowing
to
the
ground
segment
and
to
other
command
control
systems
existing
on
the
ground
using
alternate
technologies,
but
the
reliability
and
the
determinism
of
that
complete
end-to-end
path
is
important.
B
I
I
really
love
this
picture
and
thank
you
niels
for
this
great
presentation.
I
was
just
wondering:
do
we
have
a
case
where,
for
instance,
the
plane
on
the
top
would
use
one
or
the
two
of
the
planes
which
are
the
lower
level
here
to
relate
to
the
tower
like
like?
Do
we
ever
mesh
them
or
is
it
not
something?
You
have
thought
to
depley
yet
because
raw
would
also
give
you
that.
G
Yeah,
so
I
can
answer
that
question
real,
quick.
G
What
I
presented
now
is
the
ldx
air
to
ground
communication
link,
because
it's
much
more
mature,
but
is
also
currently
this
effort
going
on
in
iko,
also
at
the
german
aerospace
center
to
have
the
system
details
of
an
aldex
air-to-air
layer
available
and
then
yes,
something
like
an
aircraft
leaves
the
london
airspace
but
wants
to
send
a
message
to
something
and
washing
and
then
there's
a
huge
mesh
networks
of
aircraft
relaying
this
message
onto
the
final
destination
washing
this
is
going
to
happen,
and
so
for
that
it
just
takes
a
couple
of
a
little
bit
of
time
until
the
file,
layer
and
mac
layer
procedures
are
clearly
defined.
B
Can
I
add,
speaking
personally
that
use
case
is
obviously
being
explored
by
various
aeronautical
companies
again
not
always
happening
at
layer
2.
So
again,
that's
the
use
case
from
for
raw.
So
you
may
get
the
aircraft
to
aircraft
handover
happening
at
the
ip
layer
rather
than
at
the
link
layer
for
simple
reasons
that
the
aircraft
may
be
carrying
different
manufacturers,
radios,
a
number
of
different
security
domains,
etc.
A
A
We
have
one
more
presentation
and
I
think
because
we've
had
so
much
good
discussion.
Fabrice
the
floor
is
yours
and
you
have
you
know
we
we're
coming
up
on
the
hour
so,
but
you
have
your
15
minutes
and
maybe
a
little
wiggle
room
beyond.
E
C
M
Okay,
let's
start,
I
will
try
to
keep
it
short
because
we
are
short
in
time.
Well,.
A
No,
you
have
your
15
minutes,
so
it's
all
there.
A
M
After
the
plantation,
I
would
just
try
to
present
what
we
updated
in
the
draft.
So
basically,
as
a
remainder,
the
version
was
going
all
the
aspects
of
oem
wireless
and
determinist
networks,
and
we
have
decided
to
split
the
document
in
the
date
net
version
server.
So
that's
everything
which
is
generic
for
that
net
cases
and
in
the
version
3
we
try
to
focus
only
on
the
specific
widow
networks,
and
now
we
moved,
hopefully
all
the
generic
aspects
to
the
date
net
version.
And
now
this
our
version
is
focused
uniquely
on
wireless
networks.
M
So
I
I
will
present
shortly
what
we
have
done
up
to
now.
We've
introduced
the
terminology
section
trying
to
detach
or
what
is
expect
which
where
but
who?
I
am
maintenance
set.
Point
active
passive,
hybrid
measurements,
controlling
the
data
plane.
So
all
what
is
generic
enough
to
be
put
in
the
paper
craft,
and
here
we
focused
on
the
control
techniques
that
are
used
in
war
for
wires,
so,
for
instance,
for
biggie
biking,
because
we
have
a
very
high
medium
access
cost.
So
we
piggyback
some
control
information,
normal
packets,
about
inbound
and
half
toughbone
monitoring.
M
So,
without
and
in
the
control
plane,
but
with
the
databases
on
that,
what
are
the
messenger
and
the
defect
and
the
difference
with
force
temporary
versus
permanent
faults
for
one
network?
It
has
not
changed
a
lot
for
the
sections
which
is
specific
to
defining
what
why
why
networks
are
specific.
So
that's
the
concept
of
a
link,
abstraction
that
doesn't
hold
anymore
in
wireless
network,
because
we
have
link
asymmetry
because
we
have
some
different
characteristics
and
external
interference.
M
We
define
also
that
broadcast
transmissions
have
an
impact
on
the
rom
plane
because
we
may
use
some
other
packets
to
infer
something,
and
we
also
have
a
deep
change
in
the
forwarding
process,
since
we
may
have
complex
layer
2
for
running
such
as
any
cast
or
this
kind
of
stuff
for
the
operation
part.
The
objective
of
that
is
to
keep
the
network
up
and
running,
so
we
have
a
connective
verification,
basically,
that's
something
which
is
quite
common,
but
we
we
have
the
specificity
of
any
cast.
M
That
makes
that
the
number
of
possibilities
is
increasing
very
fast,
so
we
have
different
probabilities
for
each
receiver,
so
that's
very
complicated
and
actually,
when
we
take
a
look
at
the
root
tracing,
so
the
identifying
the
root
that
has
been
used
for
a
given
packet,
that's
is
much
more
complicated
because
we
have
a
major
topology.
So
we
have
multiple
forwarders
at
each
up
to
increase
the
availability
and
variability.
So
that's
much
more
complicated
to
trace
all
the
possibilities
and
the
force
are
very
common
in
wireless
because
we
have
link
quality
variations.
M
So
we
have
very
large
viability
here,
and
so
it
has
to
be
android
properly
to
limit
the
bandwidth
consumption,
because
else
we
have
a
huge
amount
of
control
traffic
to
transmit,
and
sometimes
the
wireless
networks
have
a
low
bitrate.
So
it
has
to
be
considered
properly
to
compress
the
volume
of
data
for
information
that
has
to
be
sent
so
that
it
may
be
scalable
and
acceptable
in
this
situation,
and
last
part
we
have
also
modified.
M
Quite
slightly
is
the
maintenance
part,
because
we
have
to
achieve
predictive
maintenance
and
reconfiguration
in
our
network,
so
typically
to
adapt
them
to
reach
the
variability
algorithm
control
plane
is
quite
complicated
because
we
have
wireless
networks,
wires
links,
so
some
packets
may
be
lost,
so
we
have
to
define
a
method,
a
technique
so
that
we
can
recover
from
this.
M
Packet
classes
so
either
end
to
end
up
by
all
protest
missions.
It
has
to
be
discussed
properly
and
we
have
also
to
take
care
of
a
dynamic
behavior
of
the
network
so
because
the
network
is
changing
continuously,
so
we
have
some
faults
which
are
just
transient
and
the
network
is
well
configured
for
this
situation.
M
So
the
next
step
is
what
we
achieved
up
to
now.
Do
we
have
some
missing
points
in
our
documents?
Do
we
have
some?
Do
you
have
some
critics
suggestions
from
a
working
job,
so
we
are
very
any
suggestion.
Contribution
is
welcome,
and
last
but
not
least,
also,
should
we
have
a
working
goal
but
option
for
this
draft
or
not.
Is
it
of
interest
for
working
group?
So
that's
the
open
question
from
myself
and
from
the
hotels.
B
Thank
you
very
much,
so
I'm
just
checking
our
charter
a
second
because
I
think
oam
is
a
charter
item.
So
your
working
group
adoption
call
is
valid.
Let
me
just
I've
got
lost
in
the
data
tracker.
A
B
So
so
my
my
question,
therefore,
is:
we
need
an
oam
document.
We
have
an
oam
individual
draft,
therefore
working
group,
you
need
to
review
this.
So
authors
are
you?
Are
you
asking
for
adoption,
or
I
mean,
do
you
think
this
is
ready
for
adoption,
or
are
you
looking
for
more
feedback?
First.
M
B
Okay
understood
so,
I
might
suggest
working
group
have
it's.
This
document
is
available
on
the
data
tracker
read
it
give
the
author's
feedback,
because,
although
they're
not
asking
now,
I
can
imagine
maybe
after
the
next
ietf
they
might
be
ready
to
ask
for
adoption.
So
please
help
okay.
A
I
think
it's
not
a
question
just
to
comment
on
my
part.
In
addition
to
sort
of
rejiggering
the
milestones
you
know
in
much
the
same
way,
we
need
to
rejigger
them
to
account
for
the
fact
that
we
don't
have
a
separate
requirement
stock
we've
got
a
technology
draft.
Instead,
the
we
probably
need
to
also
add
a
milestone
around
oam,
that's
a
little
further
out,
and
we
can
definitely
use
your
input
for
breeze
about
and
authors
about,
sort
of
a
time
frame.
B
So,
just
as
a
heads
up
for
the
for
the
working
group,
even
I
are
looking
to
just
align
the
charter
milestones
with
what
we're
actually
working
on
it's
a
bit
of
admin.
But
of
course
we
will
inform
the
working
group
of
what
we're
proposing
before
we
actually
make
the
decisions.
A
Right
and-
and
it's
also
that
it's
as
I
was
saying
to
rick,
the
oam
work
is
or
the
need
for
oam
is
mentioned
in
the
charter,
even
though
it
wasn't
initially,
it's
not
in
the
initial
set
of
milestones,
so
we
just
need
to
align
them.
B
So
we
have
look
at
that.
We
have
nine
minutes
exactly
for
open
mic,
it's
almost
as
though
we
planned
it.
If,
if
no
one
has
any
further
questions
for
fabrics,
thank
you
very
much
to
all
our
presenters
and
yeah.
The
queue
is
open
for
for
general
discussion.
B
Yeah
the
q
feature
is
is,
is
is
fine,
otherwise
I
shall
sit
quietly
and
drink.
My
coffee,
because
we
have,
we
have
meat
echo
for
another
10
minutes.
I
Hello,
yes,
if
we
have
a
minute
or
two,
I
would
like
to
come
back
to
the
architecture
and
the
plan
to
proceed.
I
So
we
we
kind
of
gave
ourselves
like
four
weeks
I
just
published
05
as
I,
as
I
said,
I
would,
and
what
I
would
love
to
see
happen
now,
is
share
the
github
with
lou
and
rick,
invite
you
on
the
github
and
start
working
on
the
on
the
changes
that
that
both
of
you
have
suggested
and
and
for
that,
since
we
have
a
very,
very
tight
time,
I
guess
we
would
need
to
to
have
a
few
sessions
between
authors
to
to
agree
on
what
gets
in
and
and
then
we
would
notify
the
group
that
were
already
basically.
B
Well,
the
reason
I
said
four
weeks
is
because
I
have
learned
from
experience
that
when
chairs
say
we
will
ask
in
12
weeks,
then
it
gets
forgotten.
So
if
you,
if
you
think
four
weeks
is
too
soon
that's
fine,
we
can.
We
can
leave
it
for
longer.
I
You
know,
if
you
ask
me,
if
you
ask
me
what
we
would
do
is
adopt
the
damn
thing
and,
as
part
of
the
adoption
procedure,
you
chairs
would
ask
me
to
invite
the
two
new
authors.
So
when
I
publish
zero
zero,
the
only
change
would
be
adding
others,
so
changing
reshuffling,
the
authors
and
from
there
we
would
form
a
kind
of
design,
team
or
just
the
authors,
but
it
could
be
a
design
team
which
would
be
wider
than
that.
I
I
don't
know
to
actually
do
what
lou
and
rick
have
asked
now,
since
it's
flow
and
risk
riku
know
what
they
want.
It
could
also
be
done
just
between
the
authors
copying
the
mailing
list
on
what
progress
is,
but
I
I
don't
see
a
good
reason
if
we
know
you
know
if,
if
we
know
where
we're
going
to
wait
for
four
weeks,
I
mean,
but
the
work
happens
as
a
work
document.
B
Okay,
so
so
so
my
suggestion
for
the
four
weeks
was
not
about
rate
of
work
or
additional
authors.
It
was
simply
because
you
because
the
current
draft
wasn't
available
until
this
morning
or
today,
there
had
been
no
opportunity
for
the
working
group
to
read
the
latest
version
before
making
a
decision
on
adoption.
B
So
the
four
weeks
was,
purely
so.
The
working
group
participants
get
a
chance
to
read
the
draft
you
have
just
published
and
consider
whether
this
is
the
correct
direction
for
the
architecture
and
framework
for
for
raw.
H
I
Today,
but
if
you're
saying
hey,
we
give
you
in
four
weeks
it's
just
like
even
too
much.
If,
if
the
considering
the
tight
in
the
schedule
we
have
and
and
the
fact
that
you
and
lou
identified
some
more
work,
that
needs
to
be
done,
so
we
could
do
it
in
the
personal
submission.
But
I
mean
why
not
do
it.
B
B
B
D
We
like
have
two
week:
cutoffs
you're,
you
just
published
it
today,
it's
in
the
middle,
it's
just
the
start
of
the
ietf
week.
It's
even
though
we're
virtual,
it's
still
a
busy
week.
I
don't
think
it's
reasonable
this,
you
know
to
say
I
published
it
five
minutes
ago.
Can
we
adopt
it?
Let's
get
and
the
four
weeks
is
sort
of
reasonable.
Given
you
know
a
week
for
the
ietf
to
take
place
next
week,
I
know
there's
a
whole
bunch
of
people.
D
You
know
I
know
we're
not
traveling,
but
maybe
we're
taking
some
vacation
time
next
week.
It's
a
popular
type
of
that,
so
you
know
real
work
happening
in
in
after
that
is.
He
seemed
sort
of
reasonable
to
me
and
I
figured
that's
part
of
the
for
the
the
four-week
comment.
I
don't
think
we'll
say
I
published
it
today.
Can
we
adopt
it
today.
D
B
N
I
Right
but
be
clear,
I
never
said
we
adopted
today
right.
I
said
we,
we
just
discuss
it
on
the
mailing
list.
That's
what
the
call
for
adoption
years
and
we
take
the
time
it
needs
right,
and
if
you
say
it's
four
weeks,
it's
right
now.
Yes,
I'm
anxious
that
it's
too
close
to
christmas.
B
A
A
Obviously
it's
going
to
be
hard
to
do
that
this
week
so
and
it
made
me
hard
to
do
it
for
people
in
the
us
next
week
because
of
the
thanksgiving
holiday,
and
but
I
do
think
that,
sometime
before
the
end
of
the
year
before
the
christmas
holiday,
the
december
holidays
is
perfectly
reasonable
and
if
people
can
do
it
sooner
great,
so
let's
take
it
to
the
list
and
and
set
our
expectations
for
some
time
in
early
december,
and
if
it
has
to
be
mid-december
great
as
long
as
it's
we
we
aim
for
this
year.
I
B
A
B
Okay,
so
we
are
in
the
last
minute.
A
Thank
you,
everyone
for
staying
awake
and
having
such
a
rich
conversation
in
the
audio
and
in
the
chat
session
and
ethan.
As
always.
Thank
you
for
all
of
your
note-taking.
B
Thank
you
very
much
note
takers
ethan,
whoever
thank
you
very
much
for
getting
up
early
or
staying
up
late
or
being
at
a
sensible
time
because
you
live
in
asia
and
we
we
might
do
an
interim,
have
no
idea
as
yet.
Otherwise
we
will
see
you
all
at
or
speak
to
all
the
ietf,
110
and
or
on
the
mailing
list.
Thank
you
very
much
for
attending.
B
Thanks
guys,
we'll
thanks
eve
and
we'll
shut
it
down
last
time,
miteko
just
died
instantly,
but
it
still
seems
to
be
open.