►
From YouTube: IETF112-RAW-20211109-1200
Description
RAW meeting session at IETF112
2021/11/09 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Great
well
welcome
everyone,
particularly
those
of
you
who
might
be
in
time
zones
where
this
is
an
unusual
hour
to
be
awake
and
speaking,
welcome
to
the
working
group.
That's
focused
on
reliable
and
available
wireless,
otherwise
known
as
raw
I'm
eve,
schuler
and
who
you
heard
before
was
my
co-chair
rick
taylor
and
it's
tuesday
november
9th,
and
this
is
the
idf
112.
A
we're
going
to
get
going
now,
if
you
could
advance
the
slide,
but
one
slide
I'd
like
to
just
review
a
few
items
that
we
should
note
well
in
the
tradition
of
the
ietf
and
start
out
by
stating
that
you
know
there's
a
whole
collection
of
policies
that
the
ietf
has
established,
and
this
basically
will
review
some
of
them
at
a
high
level.
And,
most
importantly,
there
are
you
know,
policies
on
whole
range
of
top
topics
here
and,
of
course,
by
participating
in
the
ietf.
A
One,
that's
quite
important
is,
of
course,
if
you
are
aware
of
any
ietf
contribution,
that's
covered
by
patents
or
patent
applications
owned
or
controlled
by
you
or
your
sponsor-
that
that's
a
quite
important
topic
in
fact
to
disclose
earlier
than
later,
and
the
ietf
goes
to
great
lengths
to
identify
what
is
meant
by
a
contribution
and
what
is
meant
by
participation
and
as
a
participant
in
our
attendee
to
an
ietf
activity.
You
also
acknowledge
that
any
written
audio,
video
and
photographic
records
or
communications
of
meetings
are
going
to
be
made
public.
A
Yet,
on
the,
on
the
other
hand,
all
of
your
personal
information
that
you
provide
will
be
handled
according
to
the
privacy
policies
of
the
ietf,
and
I
I
personally
believe
that
this
last
bullet
is
perhaps
the
most
important
item
to
note
well,
is
that
we
really
encourage
participants
and
attendees
to
agree
to
be
respectful
to
one
another
as
part
of
this
community.
A
Of
course,
if
you
have
any
questions
there,
we
have
links
included
in
our
slides.
Of
course,
since
covid
began,
we
have
been
conducting
these
meetings
strictly
online
and
just
to
remind
you
that
these
sessions
are
recorded.
A
This
one
as
well,
and
that
you
know
once
you
basically
begin
speaking
and
participating
that
in
some
ways
you
have
agreed
to
you
know
once
you
unmute
your
mic
and
or
and
or
turn
on
your
video
that
that
you
are
in
agreement
with
the
policies
of
the
itf
for
these
meetings.
A
Please
keep
your
audio
muted
and
your
video
off
when
you're,
not
presenting
or
speaking
and
when
you're
speaking,
please
introduce
yourself,
although
it's
lovely,
to
see
that
meat
echo
does
integrate,
identify
identification
underneath
your
video
and
underneath
your
audio
when
you
are
participating.
So
let's
get
to
the
next
slide.
A
As
you
can
see,
there
are
a
whole
range
of
policies
should
you
have
any
questions
and
I
definitely
encourage
you
if
you
have
not
read
them
before
to
investigate
them
at
some
point.
Sooner
than
later,
there's
an
ombudsman
for
the
ietf
and,
of
course,
as
working
group
chairs
and
ads.
We
also
are
happy
to
advise.
A
The
I
think
how
you
had
it
before
was
a
little
better
in
terms
of
the
presentation
right
yeah.
Thank
you
very
much.
The
the
great
news
also
is
meat.
Echo
integrates
not
only
the
blue
sheets,
but
additionally,
the
chat
or
what
used
to
be
considered.
You
know
I
am
or
jabber,
and
so
we
encourage
you
to
make
use
of
that
capability.
A
The
other
nice
attribute
is
that
there
are
live
minutes,
meaning
that
they
are
shared
and
we
encourage
you
to
collaborate.
In
fact,
if
there
is
someone
who
would
like
to
offer
their
services
to
lead
the
minute
taking,
we
would
welcome
hearing
from
you
I'll
just
pause
here
for
a
moment
to
see.
If
there's
somebody
who
would
like,
like
the
honors.
B
I
will
add
at
this
point
that
normally
or
up
until
this
point,
ethan
has
always
done
a
fantastic
job
of
doing
that
and
unfortunately
he
can't
make
it
this
time.
So
don't
expect
the
vast
quality
good
quality
minutes
that
we've
had
previously,
unless
you're
willing
to
to
help
create
them.
A
And
I'm
sure
you
will
do
as
fabulous
a
job,
but
yes,
we
have
been
really
blessed.
So
if
ethan
is
on,
we
just
our
gratitude
for
many
sessions
of
itf
note-taking
and
of
course,
so
if
you
click
on
the
cody
md
integrated,
I'm
trying
to
see
there.
It
is
it's
the
fourth
button
at
the
top.
It's
integrated
note-taking
tool
along
the
top
banner
you
can
switch
to
to
the
view
and
edit
away
please.
A
A
Quite
a
few
documents
the
we
will
hear
from
pascal
both
about
the
technologies
draft
and
the
architecture
draft
and
followed
by
a
draft
that
he
has
recently
submitted
an
individual
contribution
which
has
aired
in
the
debt
net
working
group
on
ipv6
options.
A
And
we
will
hear
a
summary
of
the
latest
changes
to
the
use
cases
document
by
carlos
bernardos
and
followed
by
an
update
on
ldac's
document
by
niels,
morrow
and
hopefully
we'll
have
quite
a
bit
of
time
for
open
mic.
B
A
B
So
we,
as
eve
said,
we've
got
a
bunch
of
documents
that
are
now
their
status
has
changed
since
the
ietf111,
so
ldax
is
currently
in
the
iesg
review,
and
I
know
some
edits
have
been
requested,
and
I
know
the
author
team
has
made
some
changes.
So
niels
will
go
through,
hopefully
some
of
the
changes
and
why
they
were
made
and
whether
they
were
substantive
or
not.
I
don't
believe
they
were.
Hence
we
are
still
in
iesg
review.
B
Obviously,
for
those
of
you
less
familiar
with
the
way
a
document
moves
through
a
working
group
and
through
into
the
iesg
and
off
to
become
an
rfc
eventually,
editorial
changes.
Requests
for
comment
from
to
come
out
of
the
iesg
review
are
normally
handled
at
that
stage.
If
there
is
a
substantive
problem,
that
means
the
document
actually
needs
to
to
really
go
back
to
be
chewed
over
by
the
working
group.
B
Then
it
will
drop
back
to
being
a
normal
working
group
document,
but
as
we
understand
it
at
the
moment,
the
comments
reviewed
as
part
of
the
comments
received
as
part
of
the
isg
review
for
ldx
have
been
clarification
or
minor
updates
when
niels.
If
you
have
not
read
the
latest
update
of
the
ldx
document,
please
pay
attention
to
nielsen's
presentation
about
what
has
changed
if
you,
as
a
member
of
the
working
group,
think
that
the
change
is
substantive
and
needs
to
be
properly
looked
at
by
the
working
group.
B
That
is
your
chance
really
to
raise
that
at
the
mic
and
say
and
say
otherwise.
The
working
group
documents
we
have
at
the
moment
is
in
no
particular
order.
The
architecture
document
which
pascal's
going
to
talk
about
oam
support
for
raw
technologies
and
the
use
cases
document
they
are
still
not
ready
for
isg.
B
B
That
document
has
yet
to
be
renamed,
but
it
has
been
officially
adopted
when
it's
renamed.
It
will
be
draft
ietf
raw
industrial
requirements
where
there
was
some
discussion
about
crossover
between
that
document
and
the
use
cases
document.
Some
content
may
boil
off
into
use
cases.
There
may
be
some
flow
in
the
other
direction
as
well,
but
that's
the
point
of
a
working
group
document,
so
that's
that's
perfectly
normal.
B
Carlos
bernardo
still
has
his
mech
and
his
joint
selection
raw
mech
drafts,
which,
as
of
the
last
ietf,
he
was
still
working
on.
I'm
not
sure
if
there's
been
any
updates,
I'm
sure
carlos
can
answer
that
annoyingly
while
presenting.
I
can't
see
the
jabber
chat
in
case
carl
eve
shout
if
someone
is
if
carlos
has
got
a
comment
about
that,
but
otherwise
we're
we're
not
really
looking
at
these
at
the
moment,
because
carlos
is
still
working
on
them.
As
far
as
I'm
aware.
B
So
this
is
the
status
of
the
milestones
as
they
stood
at
the
last
ietf
meeting.
A
Yeah
I
accidentally
removed
carlos
from
the
from
the
meeting
queue.
Please
put
yourself
back
in.
That
was
not
my
intent.
Yes,
and
now
I'm
trying
to
figure
out.
Oh
here,
you
are
go
ahead.
Carlos.
C
B
But
you're
not
asking
for
working
group
adoption
yet
do
you
still
want
to
do
a
little
bit
more
personal
work
on
it?
First?
Is
that
right?
Yes,
okay,
that's
fine!
That's
fine!
So
the
the
milestones
as
they
stood
at
the
last
ietf.
Look
like
this
on
the
screen,
so
everything
green
actually
were
new
additions
to
the
milestones
from
what
stood
before
the
last
ietf
meeting.
The
little
ticks
obviously
mean.
We've
met
that
milestone,
which
is
great.
The
ones
with
a
red
date
are
things
which
are
slipping
either.
B
We
haven't
even
created
the
document.
Nobody
has
put
forward
a
personal
draft
to
even
begin
adoption,
for
example,
the
the
last
item
on
the
list,
which
is
a
charter
item
for
an
evaluation
of
existing
itf
tech
and
a
gap
analysis
document
with
good
reason.
The
other
ones
are
dates
we
assigned
at
the
last
ietf
thinking.
Oh,
we
might
have
this
ready,
but
obviously
it
is
now
november
and
they're
not
ready.
B
So
one
of
the
discussions-
I
think
it's
probably
worth
having
in
the
working
group,
particularly
as
we
get
a
presentation
on
most
of
these
documents,
is
to
discuss
when
we
should
set
a
tentative
date
for
when
we
think
these
documents
might
be
ready.
B
I
understand
it
will
be
a
guess,
but
a
guess
is
better
than
having
a
milestone.
That
is
blatantly
wrong.
If
you
look
at
the
milestones
on
the
data
tracker
you'll
see
that
some
of
there
are
more
on
this
list
than
there
are
officially
signed
off
by
john
scudder
rad
reason
being
is
that
john
quite
rightly
looked
at
some
of
the
dates
proposed
at
the
last
ietf
meeting
and
the
current
date
and
raised
the
question
of
whether
we
were
being
a
bit
ambitious
or
whether
the
dates
were
just
unrealistic.
B
So
I
would
like
to
think
collectively
we
can
answer
his
questions
and
if
we
can
assign
a
slightly
better
estimate
on
when
these
documents
are
going
to
be
expected
to
be
ready,
then
we
can
adjust
the
date
on
the
milestone
on
the
data.
Tracker
and
john
can,
hopefully
click
the
accept
button.
I
don't
think
and
john
feel
free
to
step
forwards
and
tell
us
we're
wrong,
but
I
don't
think
there's
any
question
of
whether
the
milestone
is
valid
or
not.
B
B
So
we're
not
hearing
about
the
industrial
requirements
because
having
spoken
offline
with
the
industrial
requirements
or
the
team,
they
want
to
do
a
bit
of
work.
They've
had
a
busy
summer
and
haven't
had
a
chance
to
to
work
much
on
it.
So,
in
my
opinion,
with
my
chair
hat
on,
I
think
it
will
be
after
the
use
cases
document.
B
So
if
we
can
get
a
good
date
for
the
use
cases
document
or
a
guess
for
a
date
for
the
use
cases
document,
I
would
be
happy
to
add
two
three
months
to
that
and
then
say
the
industrial
requirements
document
is
probably
ready
at
that
point,
any
comment
from
the
floor
on
that
as
a
as
a
way
forwards,
just
check
the
chat
as
well.
B
Yeah
just
spotted
that
brilliant,
thank
you,
john,
so
I'm
clicking
next
in
the
wrong
window.
Sorry,
okay!
So
pretty
much
on
time
over
to
the
presentations
on
drafts.
Now
I
know
pascal
you've
got
a
clash
today
and
you
are
jumping
between
raw
and
somewhere
else.
So
it's
up
to
you
to
keep
an
eye
on
the
time,
but
please
please
please.
E
D
G
E
So,
yes,
let's
start
by
the
architecture,
please
next
slide.
E
So,
as
you
know,
this
document
covers
two
things
by
the
title:
it
has
architecture
and
framework
and
that's
kind
of
a
a
bit
confusing,
because
the
architecture
is
something
that
you
you
do
at
the
beginning.
Here
is
what
I
want
to
build
and
your
your
other
main
directions
and
how
it's
going
to
work-
and
the
framework
is
more
here-
is
what
we
built
and
here
are
the
components
that
we
put
together
and
how
they
are
assembled.
E
And
so
the
architecture
piece
is
really
something
that
you
do
ahead
of
time
and
the
framework
is
more
something
you
do
whether
at
the
end
and
because
this
document
has
both
it's
very
hard
to
say
that
we
are
going
to
ship
it
very
early,
because
we
don't
really
know,
for
instance,
the
answers
of
how
exactly
oem
is
gonna
work.
E
So
if,
if
really
we
we
care
about
producing
the
architecture
and
shipping
it
early
because,
as
you
said,
we
should
ship
this
month,
then
I
was
wondering
if
we
would
consider
actually
splitting
into
architecture
on
the
one
hand
and
framework
which
would
we
would
deliver
pretty
much
when
we
closed
the
working
goal.
E
As
you
know,
here
is
what
we
did.
The
result
works
there
all
the
components
here.
You
know,
data
came
from
here
there
that
net
and-
and
here
is
how
they
assemble,
because
I
just
don't
see
that
we
can
shape
architecture
and
framework.
You
know
before
very
late
in
the
process.
So
so
that's
basically
a
question
to
you
rick
and
eve
just
so.
B
Looking
looking
at
the
charter,
I
actually
agree
with
you
because,
as
you
as
you
say,
the
architecture
has
to
to
precede
the
the
framework
logically
and
the
charter.
As
I
read
it
and
understand
it
is
in
this
phase
of
the
working
group's
lifetime.
B
We
should
be
exploring
the
problem
space
defining
what
we
see
the
problems
to
be
analyzing,
the
available
technologies
that
exist
within
the
ietf
and
at
the
link
layers
and
oh
and
that's
pretty
much
it
and,
and
maybe
the
framework
as
a
proposal
of
how
we
could
proceed
kind
of
covers
the
end
of
this
working
group
cycle
and
would
be
a
great
starting
point
if,
when
we
recharter.
E
It's
already
structured
pretty
much
that
way.
I
already
restructured
at
the
previous
publication
to
resize
start
with
architecture
and
then
put
the
framework
as
the
second
piece.
So
splitting
should
be
easy.
Rather,
though,
the
question
really
will
be
with
lou.
You
know,
lou
wants
to
to
to
do
some
important
changes
and
we'll
have
to
see
how
luana
can
collaborate
to
to
get
make
that
happen
following
you
know
what
lou
wants
to
achieve,
but
as
we
do
that
I
mean
splitting
document
is
no
big
worry.
E
B
Very
quickly
before
I
let
lou
jump
in,
I
would
I
don't
see
a
given
that
the
working
group
kind
of
owns
the
the
complete
document.
I
don't
see
any
reason
to
reject
the
framework
parts
and
push
it
back
to
you
as
a
personal
draft.
Why
not
just
keep
it
adopted
it?
We
seem
to
that's
too
much
process.
I,
unless
somebody
think
well,
even
if
somebody
does
think,
there's
a
problem
it.
The
text
has
already
been
adopted,
even
if
we
split
the
text
into
two
documents,
so.
A
Right,
it
seems
like
an
unnecessary
step.
I
think
we
should
assume
it's
already
adopted.
However,
I
can
see
that
there
are
a
couple
people
in
the
queue
lou.
Would
you
like
to
go
ahead
and
comment.
A
H
H
That's
really
important
when
you
have
one
set
of
technology
or
one
set
of
operators
supporting
another
set
of
operators.
For
example,
if
we
were
running
debt
net
over
a
5g
network,
we
wouldn't
necessarily
expect,
unless
you're
the
5g
operator,
that
you
would
be
able
to
have
full
access
to
the
5g
network.
You
know
there
was
a
liaison
from
what
was
it
a
year
ago
or
more
where
the
three
gpe
said.
H
Here's
here
are
the
type
of
parameters
you
can
expect
across
a
5g
service,
interface
and
and
those
would
not
facilitate
or
support
this
type
of
raw
architecture
that's
being
shown
here.
So
it's
really
the
comment
that
I
made
a
while
ago
and
I
think
resonated
with
others-
is
we
really
need
to
bring
in
the
concept
of
multi-layer
and
part
of
that
is
supporting
use
of
dlap
to
support
that
and
if
there's
others
who
want
to
work
on
it,
I
think
we
should.
H
E
H
E
To
this
sure,
that's
that's
perfect.
I
mean
I've
seen
that
that
there
is
something
that
they
they
do
very
well
on
the
case
in
the
case
of
oam,
for
instance,
they
they
have
this
periodic
meeting
where
anybody
can
join.
So
it
doesn't
look
like
a
tiger
team
or
something
anybody
can
join,
but
still
it's
a
dedicated
periodic
meeting
organized
by
that
net,
so
you
see
janos
in
particular,
attending
the
oaf
one
and
and
we
do
great
progress
and
oem
thanks
to
this
organization.
E
So
if
you
don't
mind
having
raw,
you
know
being
shepherding
this
kind
of
activity
as
well
for
the
cross
layer
or
the
architecture
or
the
cross
layer
piece
of
the
architecture,
I
really
think
we
could
progress
a
lot
more
than
you
know
the
way
we
do
it
today.
B
Yeah,
so
that's
definitely
something
the
chairs
can
can
arrange.
I
mean
we
have
the
facility
to
set
up.
Interims
are
really
cheap,
so
being
able
to
set
up
meet
echo.
You
know
once
every
two
three
weeks
or
whatever
a
sprint
needs
to
be
to
just
have
a
a
quick,
focused
meeting
on.
How
are
we
going
in
the
right
direction?
How
are
people
doing
that's
something
we
can
do
really
easily,
so
I
will
make
a
note
and
take
an
action.
I
B
Meetings,
okay,
so,
in
which
case
we'll
we'll
take
an
action
to
try
and
set
up
a
webex
for
for
and
and
publish
the
the
link
on
the
the
webex
or
teams
or
zoom
or
whatever,
and
publish
the
link
on
the
mailing
list
so
that
it's
open
and
it's
and
it's
public.
It
will
we'll
work
out
an
elegant
way
of
doing
it.
Luke
good
point.
A
The
net
group
role
models
that
very
well
and
we
should
follow
suit.
We
have
a
couple
others
in
the
queue
abdul
salam.
If
you'd
like
to
speak
up,
please
take
the
floor.
F
Yeah
good
morning,
my
suggestion
is
to
not
split
it
now
the
document
this
draft,
as
adopted
it's
good
to
when
we
review
it
to
be
having
the
architecture
and
the
frame
framework
together
as
we
adopted
it.
So
actually
it's
also
the
second
draft
or
the
zero
one.
So
and-
and
let's
say,
if
we
get
to
draft
number
five
or
six,
we
can
then
split
yeah.
But
now
I
think
it's
it's
a
good
good
stage
that
we
see
them
together
while
reviewing
them,
and
it's
already
only
40
pages.
F
So
I
think
it's
it's
okay.
We
can
do
it
together
and
then
in
the
future,
maybe,
but
it's
to
the
working
group
to
split
if
almost
they
agree
to
split
and
but
I
think
for
me-
I
I
don't
agree
now
to
to
split
the
two
documents
yeah.
Thank
you.
B
Thanks
for
signing,
that's
a
that's
a
good
point,
maybe
if
it's
good,
particularly
if,
if
we're
going
to
try
and
really
get
some
cycles
on
this,
to
just
keep
all
the
content
together
for
now
and
then
maybe
prior
to
iesg,
remove
one
section,
I
I
I
it's
a
it's
a
valid
point.
Thank
you.
E
Not
too
late
right
because
at
some
point
we
want
to
make
sure
that
the
documents
in
isolation
are
complete.
So
if
we
want
to
keep
them
packaged
together
right
now,
we
can.
We
can
make
two
major
sections,
you
know
and
say
this
is
the
architecture.
This
is
the
framework.
It's
pretty
much
the
way
it's
organized
anyway,
but
if
we
want
to
progress
the
architecture
and
focus
on
it,
we
don't
want
to
get
too
much
distracted
by
the
framework
piece.
E
So
when
we'll
ask
reviews
and
stuff
and
early
reviews
at
that
time,
the
split
must
have
happened,
because
otherwise
people
will
comment
and
on
the
whole
thing
and
delay,
you
know
it's
gonna,
it's
gonna
progress
at
the
speed
of
the
weakest
link.
So
if
we
separate
them
once
we
separate
it
will
be
much
faster
for
the
p
stand.
That
is,
you
know
priority
and
the
other
one
will
be
stuck,
which
is
as
expected.
E
E
B
Okay,
so
so
can
I
make
a
request
you.
You
say
that
the
the
document
is
pretty
much
in
two
sections.
If,
if
you,
if
on
the
next
revision,
you
can
put
an
explicit
section
break
between
the
architecture
and
and
the
framework
to
pretty
much
say
from
now
on
is
the
framework.
This
will
go
elsewhere
and
then
then
the
splits
can
be
made
fairly
quickly.
It's
just
to
sort
of
do
an
interim
step
on
there,
particularly
if
we
start
to
have
some
some
sort
of
focused
meetings
to
talk
about
that
document,
then
yeah.
E
B
And
actually,
I'm
now
arguing
against
abj
salam's
point.
If
both
documents
are
working
group
documents
and
available
through
the
data
tracker
for
review
and
comment,
then
it's
one.
Click
to
move
between
one
document
and
the
other,
so
so
perhaps
just
keeping
it
in
one
document
for
convenience
is
is
not
as
convenient
as
we
think.
Okay,.
I
Thank
you.
I
have
a.
I
guess
two
comments
on
the
question,
so
I
I
fully
agree
with
the
comment
made
by
lou
that
that
the
the
archers
architecture
should
should
follow
the
layering
model
and
and
and
capable
of
supporting
all
the
raw
technologies
we
have
in
the
in
the
in
the
raw
technologies
draft.
Actually-
and
I
understand
it's-
it's
work
to
be
done
and
I
agree
that
focus
discussions
could
be.
It
could
be
helpful,
moving
it
along
and
the
other
other
one
is
it's
a
question.
I
Actually,
I
am
a
bit
uncertain
on
the
aspects
of
the
framework
and
the
architecture,
because
in
my
understanding
of
the
charter
and
as
you
just
explained
rick,
I
I
fully
agree
that
the
working
group
would
be
developing
solutions
if
and
and
when
charters
and
it's
sort
of
the
exploration
of
technologies
and
what
is
available
requirements
and
so
on.
I
At
this
stage-
and
I
I
don't
know-
which
one
is
more
of
a
solution-
the
framework
or
the
architecture-
and
I
don't
know
if
we
split-
which
what
would
be
the
order
but
both
of
them
stepping
into
our
solution
and
for
now
it's
maybe
better,
not
to
split,
as
you
just
said,
or
multiple
people.
But
I
I
even
even
if
we
wanted
to
split,
I
am
not
sure
on
the
order
like
so
so
I
guess
the
one
that
is
less
of
a
solution
would
be
first
but
yeah.
B
So,
from
my
perspective,
I
think
we
can
argue
about
the
meaning
of
the
word
framework
and
the
meaning
of
the
word
architecture.
I
think
that
the
natural
split
for
me
is
between
a
high
level,
description
of
an
approach
to
solving
it
and
the
detailed
solution
proposal.
B
So
anything
which
really
looks
at
we
will
do
this
like
this
should
probably
be
a
later
document
and
any
text
which
says
the
problem
to
be
solved
could
be
done
like
this
is
probably
the
architecture
framework.
B
E
And
exactly
what
I
was
trying
to
say
at
the
very
beginning:
here
is:
what
you
want
to
do
is
what
I'm
used
to
calling
the
architecture
is
there
is
there
are
the
big
objects
without
really
saying
it's,
this
draft,
or
this
rfc
or
anything
like
that?
Whereas
the
framework
really
says
here
is
how
it
works.
E
Oh,
we
made
it
work
and
we
we
pick
this
component
here,
which
happens
to
be
rfc,
blah,
etc,
and
we
assemble
them
together
and
we
set
this
flag
in
that
message
or
whatever,
and
that
gives
you
the
whole
framework
and
how
this
thing
works.
E
B
If
that
is
people's
understanding
of
the
word
framework,
then
I
am.
I
am
fine
with
that,
and
I
think
this
might
also
resolve
one
of
the
questions
that
appeared
on
the
on
the
mailing
list
quite
recently
about
whether
the
document
should
discuss
technologies
that
are
in
progress
in
other
sdos,
such
as
ieee
or
3gpp,
where
we
know
they
are
working
on
time-sensitive
networking
for
802.11,
for
example,
but
it
hasn't
been
standardized
yet
so
should
we
refer
to.
H
B
Should
we
not
because
it's
not
a
standard,
I
think
naturally
that
splits,
so
in
the
architecture
you
one
could
say,
technologies
at
the
link
layer
are
being
developed
and
examined
which
may
enable
this.
But
in
the
framework
document
we
need
text
which
says
to
do
this.
We
use
802.11xy,
which
has
now
been
standard
and
standardized,
so
we
then
solve
the
question
of.
Should
we
have
it?
Should
we
not
have
it
in
this
document?
Where
architecture
we
can
talk
about
the
future
and
framework?
B
We
talk
about
the
fact
as
of
now
as
of
publishation,
and
I
think
that
might
solve
that
problem.
Janos
did
you
have
a
comment?
You've
dropped
out
of
the
queue
I'm
assuming
no
so
go
ahead.
Absalom.
F
My
understanding
of
framework
and
architecture
actually
both
of
them
they
solved
the
problem.
So
it's
mostly
the
architecture
is
more.
We
can
say
like
the
hardware
and
the
software.
Usually
software
uses
the
hardware,
so
the
framework
is
above
the
architecture,
so
anything
in
the
architecture
it
will
affect
the
framework,
but
with
not
the
the
the
way
around.
So
the
framework
comes
after
the
architecture
as
it's
in
the
title,
saying,
architecture
and
a
slash
framework,
so
the
framework
comes
after
architecture
and
its
solution.
F
Both
of
them
are
important
solutions
for
raw
technologies.
B
E
I'm
still
good,
I'm
still
good.
So,
basically,
this
is
the
slide
which
summarizes
what
we
want
to
see
in
the
architecture
so
far,
and
so
basically,
we
we
described
that
there
are
there.
Is
this
what
we
call
udaloop
and
it's
not
the
term
from
itf,
it's
really
quite
an
old
term
which
describes
a
loop
which
observes
orient
based
on
some
previous
knowledge,
and
that
would
be
the
pc.
You
know,
knowing
the
network
and
knowing
the
radios
and
making
high-level
decisions
about
structures.
E
This
side,
which
is
basically
the
the
per
packet
decision
for
which
we
instantiated
this
new
carpet
on
the
plc
that
will
decide
what
we
do
with
this
packet
to
forward
it
in
this
wireless
network
and
act,
which
is
really
now.
Okay,
the
forwarding
plane
action
and
that's
the
use
of
the
barrier
functions.
E
E
It
could
be
operating
on
the
source,
node
and
the
ingress,
in
which
case
you
need
some
form
of
quote-unquote
source
routing
information
in
the
back-end
to
to
to
do
that.
What
was
this
decided
by
the
ingress
along
the
path,
or
it
could
be
more
distributed
decision,
in
which
case
the
pse
or
some
functions
of
the
pse
have
to
be
distributed
inside
the
match.
So
so
we
describe
all
that
and
at
this
level
it's
architecture.
E
If
we
say
here
is
exactly
we
are
going
to
use
segment
routing
and
we
will
have
those
bits.
Then
we
will
have
made
the
decisions
about
exactly
what
can
be
done
at
each
shop
and
that
will
be
the
framework
in
my
book
and
then
we
described
the
the
use
of
the
the
that
net
service
plane
and
how
we
enrich
what
is
typically
do
free
off
in
that
net
to
get
pareo
to
get
more
timing.
E
E
We
were
wondering
as
well
if
there
are
any
sections
that
could
be
missing
and-
and
so
yes,
there
is
the
use
of
dilip
as
we
discussed
there
might
be
high
level
discussions
about
encapsulations,
and
that's
where
my
other
presentation
of
hope
by
heart,
destination,
option
and
source
routing
can
can
be
appropriate,
and
there
was
also
the
the
work
that
jacob
stein
has
introduced
at
that
net
and
raw
and
everywhere
about
providing
timing
information
in
the
bucket.
E
Basically,
if
this
packet
is
scheduled,
then
there
could
be
some
information
as
part
of
this
segment,
routing
source,
routing
type
of
of
information
about
where
this
packet
should
be
in
my
network,
at
which
time
so
so,
when
you
follow
the
package,
you
know
if
you're
ahead
of
time,
delay
blah
blah
blah
so
that
can
that
can
help
pro
deliver
all
the
packets
in
the
due
window
of
time
as
opposed
to
to
accelerate
packets,
which
are
already
in
advance.
E
E
Okay,
okay,
so
well,
the
two
of
the
slides
are
very
much
that
we,
we
kind
of
improved
quite
a
bit
the
the
terminology,
and
that
was
thanks
to
the
oem
discussion
in
particular,
but
also
for
for
terms.
There
is
one
thing
that
throws
us
as
distinguished,
which
is
a
bit
less
clear
in
the
in
the
net
architecture,
which
is
the
distinction
between
the
flow
and
the
path
the
flow
is,
is
basically
in
the
water
image.
E
H
E
Every
molecule
that
goes
through
this
pie
has
the
same
process
so
the
process
the
process
is
per
path,
not
per
flow
meaning.
If
you
mix
multiple
flows
in
in
a
path,
then
all
the
packets
of
all
the
flows
will
be
subject
to
the
same
operations
around
the
path
and
that
that
becomes
useful
when
you,
when
you
want
to
either
merge
path,
I'm
sorry
merge
flows
into
bigger
flow.
E
The
testnet
architecture
says
we
are
placing
flows
on
path.
That's
exactly
what
it's
saying.
If,
if
we
process,
if
we
understand
and
agree
that
we
need
to
process
things
at
the
path
level,
then
we
don't
have
this
problem
of
merging
things
anymore.
It's
just
natural.
We
operate
at
the
path
once
the
ingress
has
placed
a
certain
flow
on
that
path.
E
You
know
the
flow
will
be
processed
as
a
member
of
that
path
and
get
to
the
egress
of
that
path,
with
with
the
same
treatment
as
everybody
else,
and
all
that,
so
we
it's
it's
a
concept
that
we
had
in
in
in
row
since
inception
at
that
net.
That
has
not
been
so
well
discussed,
at
least
in
the
case
of
ipv6.
It's
not
really
available
and
that's
why
I
started
this
this
hub
by
hop
document
that
I
will
be
discussing
after,
but
for
for
this
slide
here.
E
Yes,
we
we
have
basically
defined
the
flow
and
what
we
call
the
track
by
inheritance
to
previous
work
at
the
ietf,
the
track
being
a
special
type
of
path
that
can
fork
and
join.
You
know
I
I've
looked
at
the
terminology
of
path
at
the
atf
and
for
for
many
groups
a
path
has
to
be
serial.
It's
a
then
b,
then
cmd.
E
It
cannot
be
abcd
or
lthr
and
and
maybe
merge
at
a
d
and
split
again.
A
path
is
not
like
that
for
for
many
working
group,
including
irtf
path,
research,
so
yeah,
I
think
using
path
is
a
bit
misleading
and
so
far
in
the
architecture
we
use
the
dumb
track,
which
was
really
defined
for
for
this
next
slide.
Please.
E
And
please
review
please
review
this.
This
definition
because
you'll
see
the
number
of
properties
now
there's
this
concept
of
a
subtract,
which
is
a
subset
of
the
track
that
will
be
used
for
a
given
packet
and
different
packets,
which
are
placed
on
the
same
track,
might
be
due
to
pfc
activity,
might
be
effectively
placed
on
different
subtracts.
B
E
E
E
It's
it's
a
collection
of
paths
and
and
really
some
of
them
super
imposing
on
other
ones.
I
mean
it's,
it's
like.
If
you
look
at
just
you
think
about
a
sausage
or
an
egg
right,
a
knight.
You
can
have
one
path
on
top
one
path
in
the
middle,
then
you
can
have
a
nice
path,
and
so
it's
like
four
path
with
just
an
eight
yeah.
It's
it's.
Some
people
also
define
the
path.
E
As
being
you
know,
the
the
experience
of
this
packet,
whereas
this
packet
being
between
a
and
b
that's
valid,
a
was
maintained
as
a
single
entity,
but
with
that
net
we
we
are
doing
things
like
network
coding,
things
like
replication
elimination,
and
so
it's
even
if
you
wanted
to
trace
the
path
of
a
of
a
packet.
You
realize
that
this
concept
is
gone.
H
Actually
came
in
queued
to
answer
your
comment,
the
I
think
what
you're
describing
it
matches
well
with
the
notion
of
protection
paths.
That's
shown
up
in
traffic
engineering
mpls
net
with
pre-off,
and
it
would
be
really
interesting
to
see
how
it
it
differs
from
that.
Have
you
looked
at
those
that
that
prior
work
related
protection,
restoration
and
trafficking.
E
One
of
the
things
the
things
I'm
aware
of
are
things
like
plstp,
for
instance,
where
you,
you
basically
have
two
non-congruent
paths,
it's
the
most
usual
thing
I'm
used
to
and
those
two
are
effectively
path,
because
there
are
it's
either
sequence
of
bcd
or
sequence
fth,
and
then
you
basically
decide
to
use
the
the
plan
b.
E
When
the
plan
a
shows
issues
and-
and
in
that
case
the
the
sequence
of
things
are
really
path,
I
would
argue
that,
with
that
net
we
already
went
beyond
that
concept
because,
as
soon
as
you
do
replication
and
then
further
elimination
of
a
packet,
how
can
you
say
which
path
that
packet
has
taken?
It's
it's
more.
It
turns
into
quantum
mechanics
right.
The
packet
has
been
through
both
paths.
H
E
The
problem
is,
there
is
a
lot
of
history
with
this
term
path
and
you
just
point
out,
and
so
so
a
lot
of
readers
who
are
not
used
to
what
we
are
doing
might
misunderstand
the
text.
If
we
use
the
top
path,
and
so
we
effectively
have
a
concept
of
serial
path
where
a
packet
comes
in,
gets
out
same
packet
without
a
transformation
and
then
forward
it
hop
by
half
by
half,
and
we
call
that
a
segment
and
the
track
is
actually
a
graph
of
segments.
E
Yeah,
so
so
I
mean
that's
it
for
for
this
architecture,
discussion.
I
think
we,
we
did
a
lot
of
progress,
so
we
agree
that
we
will
split.
We
agree
that
we
have
missing
items
I
listed
some.
I
hope
that
the
mailing
list
will
come
up
with
others,
and
then
we
will
have
those
informal
meetings
where
we'll
refine
everything
that
is
already
in
there
plus
you
know
what's
missing
and
in
particular
we
have
this
objective
of
cross
layer
and
the
delete
discussion
with
with
blue.
E
B
So
currently
we
have
said
november
this
year,
which
is
obviously
wrong.
B
I
don't
think
that
will
be
ready
for
iesg
review
march
next
year.
I
think
one
more
discussion
in
the
it
would
be.
B
I
would
be
very
pleased
if
we
can
get
to
the
state
where,
at
the
next
ietf
the
everyone
involved
in
reviewing
the
current
document,
submitting
changes
contributing
joining
the
informal
meetings
is,
is
happy
and
we
can
then
present
where
we
are
and
perhaps
go
for
iesg
review,
maybe
may
april.
What
do
people
think
is
that
too
ambitious.
E
B
B
B
Okay,
I'm
going
to
say
may
because
that
means
we
should
be
ready
for
last
call
that
gives
us
maybe
a
month
of
last
call
and
then
so
last
call
in
march.
Ietf
last
call
ends
mid
april,
iesg
review.
We
start
yeah,
so,
okay,
I'm
going
to
say,
may
because
april.
I
think
the
first
of
may
so
I'll
say
may
for
architecture.
B
E
E
It's
really
because
we
have
dependencies
right,
I'm
thinking
about
oem,
but
it
might
be
that
the
cross-layer
story
is
a
lot
of
work
as
well,
because
we
have
to
to
review.
You
know
I
don't
I
don't
know
how
deep
we
can
go
depending
on
which
which
technology
we
talk
about.
B
B
So
those
two
need
to
be
in
lockstep,
so
they
they
are
mid-23.
I
think
I'm
just
I'm
terrible
at
estimating.
So
I
will
I'm
going
to
say
mid
2023
for
for
those
just
for
now.
I
may
I
see
it
and
at
abdusalam
you
have
a
comment.
Please
go
ahead.
F
Yes,
I
think
deciding
the
time
is
better
to
be
done
on
the
list,
because
it's
not
easy
and
also
I
will
agree
with
the
authors.
They
are
the
most
expert,
they
can
know
the
timing,
and
everything
said
he.
I
think
we
go
for
the
what
the
authors
say
and
then
we
can
discuss
on
the
list
to
to
to
make
it
easier
to
go
forward.
Thank
you.
B
Yeah,
okay,
so
so
I
will
say
may
for
architecture,
because
I
think
people
think
that
sounds
reasonable
framework.
We
can,
we
can
discuss,
it
will
be
late
later.
I
think
it
is
fine,
so
I
have
a
question
pascal
about
the
technologies
draft.
B
G
A
And
just
so,
you
know
this
segment
we're
we're
running
pretty
late.
We
had
a
lot
of
extra
time,
but
I
think
we're
about
20
minutes
over
for
this
section,
and
I
know.
B
B
B
B
E
Better,
it's
also
normally
a
way
to
fold
the
top,
but
that's
okay.
Okay,
next
to
the
question
marked
up
right,
you
must
have
a
folding
button
which
would
basically
allow
you
to
hide
the
menu
big
difference.
Okay,
so
this
is
drafted,
that's
been
there
forever.
I
did
many
groups
which
do
the
sort
of
thing
we're
doing
like
lp1.
E
Recently
they
tend
to
to
basically
document
the
technologies
they're
working
on
so
as
to
provide
you
know
a
layman
of
what
can
be
achieved
with
those
technologies
and
in
the
case
of
raw
we
we
can
have
selected
wi-fi
six
and
above
5g
and
above
1548
ch
on
which
16
has
been
operating
and
did
a
lot
of
work
and
this
new
technology
airbags
that
we
already
discussed
and
that
niels
will
be
talking
about
a
bit
later.
E
That's
that's
already
passed
last
call,
so
we
basically
collectively
I
mean
this
is
a
huge
number
of
offers
from
all
those
technologies
collectively
and
put
together
this
this
draft,
where
we
we
provide
pretty
much
the
same
level
of
information
for
each
technology,
so
people
can
get
their
mind
and
what
what
can
be
achieved,
in
particular,
whether
they
come
from
and
what
kind
of
deterministic
properties
can
be
achieved
with
those
technologies.
E
And
the
the
recent
the
duck
is
very,
very
stable.
We
we
we
had
this
this
review
by
rocco.
Thank
you.
So
much
welcome
for
this
yeah,
where
actually
rocco,
went
very,
very
deep
into
the
text
and
the
exact
details
of
how
things
are
set
to
make
sure
they
are
really
correct.
And
then
there
was
this
discussion
between
rocco
and
dave
and
and
really
a
lot
of
that
was
beyond
me.
It
was
really
really
the
details
of
what
was
done
and
how
it
was
done.
E
So
after
you
know
the
conclusion
of
that
work,
I'm
really
happy
with
with
the
content
of
the
document
in
general.
Also
thanks
to
chatty
for
our
sixtiesh
text
and
also
I
did
some
realignment
with
the
60s
architecture,
which
is
published
as
rfc
now,
and
the
bottom
line
is
the
now
is
when
we
should
have
submitted
to
asg,
and
I
agree
that
it's
what
we
should
do.
I
mean,
I
think,
we're
ready
for
our
goblet
score,
and
if
we
make
it
two
weeks,
we
can
still
deliver
in
time.
B
Perfect
so
so
this
was
the.
I
was
rereading
the
comments
on
this,
and
the
comment
that
was
really
raised
was
whether
we
should
discuss
it's
the
discussing
standards
in
progress
in
other
sdos
or
so
referring.
E
G
B
B
Tsn
in
802.11
is
a
classic
example,
but
I
don't
think
we
should
refer
to
standards
that
aren't
yet
in
existence
so
calling
out
specific
802.11,
xe
or
whatever
it
is.
I
don't
know
the
numbers.
Well,
letters
is
a
mistake,
but
I
think
it's
perfectly
valid
to
say:
work
is
happening
at
the
time
of
this
document.
B
It
has
not
been
standardized,
but
but
it
is
happening.
I
think
that
is
a
compromise
that
works
without
stating
things
which
aren't
true.
E
B
E
B
I
Yes,
I
I
want
did
the
point
at
first
what
I
wrote
in
my
last
email
that
I
I
would
really
like
to
see
this
on
progressing
and
and
really
happy
for
all
the
the
contributions,
and
I
I
the
I
guess
the
reason
I
wrote
the
similarizing.
This
question
was
that
I
guess
we
we
sort
of
get
into
a
bit
gray
area
as
well.
I
Now,
yes,
it's
understood
that
the
work
is
ongoing,
like
the
dot
11
dgb,
which
will
specify
actually
wi-fi
seven
and
divided
into
sub-work
items
and
so
on,
but
when
it
gets
to
so
it's
absolutely
good
to
refer
to
it.
It's
approved
project
on
where
it
works.
It's
happening
no
question,
but
when
it
comes
to
sort
of
individual
contributions,
like
I
mean
contributions
that
are
at
the
level
of
individual
has
not
adopted
yet
by
the
working
group-
and
I
guess
I
would
say
maybe
in
united
mechanics-
they
are
not
there
in
the
draft.
I
Yet,
like
draft
2.0
of
dgb
is
coming
in
march,
which
will
include
sort
of
the
first,
they
call
it
release
or
package
of
features
and
tsn
is
actually
in
the
second
release.
So
it's
not
even
there
there
in
the
in
the
draft.
It's
it's
hard
to
guess
what
the
working
group
will
actually
approve
or
accept.
So
that's
that's
the
question
mark
and
there
were
a
couple
of
comments
or
aspects.
I
B
Thanks
janice,
so
I
think
really,
as
I
see
it,
there
is
the
the
there
is
a
task
for
rocco
and
for
dave,
and
maybe
something
for
yanosh
there
as
well
to
say
to
review
the
the
the
the
references
to
technologies,
particularly
in
other
seos
that
they
understand.
I
know
yelosh
is
very
deeply
involved
with
ieee
to
say
this
one
is
correct.
This
reference
is
correct.
B
This
reference
is
work
in
progress
and
this
reference
is
still
personal,
so
we
could
say
something
like
there
is
interest
in
it,
because
I
think
it's
obvious
that
there
is
interest,
but
without
saying
oh
and
it
is
happening
because
it
has
not
been
ratified
by
ieee.
I
don't
know
about
the
six
dish
example,
but
it's
probably
worth
just
doing
that
double
check.
I
would
suggest
that's
probably
part
of
the
last
call,
because
it's
a
kind
of
a
validation
pass
rather
than
a
new
content.
B
I
know
I've
just
looked
down
the
attendees
rocco
and
dave
cavalcanti
and
neither
are
involved.
So
I
don't
know
if
anyone
can
reach
out
to
them.
If
we
do
a
four-week
last
call,
I
would
hope
that
that
is
enough
time
for
people
to
look
at
it.
B
A
Okay,
I
think
that
the
four
week
last
call
would
suss
out
the
half
a
dozen
or
so
unresolved
back
and
forth
that
rocco
and
dave
were
having
about
the
precise
wording
of
the
revisions.
A
You
know
and
that's
maybe
half
a
dozen
out
of
many
dozen
that
were
provided,
which
I
thought
was
really
a
great
effort,
so
I'm
in
agreement
with
being
specific
in
the
wording
about
the
maturity
of
the
various
documents
and
the
different
classifications,
whether
they're
adopted
lending
towards
adoption
or
personal.
A
So
I
think
some
of
this
is
a
specificity
issue.
It's
not
a
lack
of
interest,
it's
a
just!
If
we
can
get
everyone
to
agree
on
the
accurate
portrayal
of
the
maturity
that
then
we
can
progress.
This.
B
Eve
if
you
and
I
take
an
action
that
when
we
send
out
the
last
call
message
to
the
mailing
list,
we
explicitly
state
that
we
require
the
references
to
be
reviewed
by
people
who
are
familiar
with
the
sdos
to
which
we
rep,
to
which
we
refer
then.
And
you
and
I
can
send
a
personal
mail
to
rocco
and
dave
saying
you
missed
out.
But
we'd
really
like
you
to
look
at
this
as
well.
And
then
I
think
that
will
be
obvious
to
everyone
involved.
Does
that
sound
reasonable.
J
Yeah,
yes,
I'm
here
yeah
I
mean
I
agree
before
you
discuss.
I
think
most
of
the
comments
related
to
ongoing
projects.
There
is
a
one
or
two
related
to
proprietary
solutions
that
have
been
used
in
wi-fi
six,
which
I
feel
they
should
not
be
there.
They
are
not
in
any
standard,
not
even
any
number
one
project
and
of
course,
then,
and
then
there
is
another
comment
which
is
besides
this
two
main
aspects,
just
as
usual.
B
E
Yes,
we
need
to
qualify
stuff
right,
don't
don't
say
there
is
this
without
saying:
hey
it's
proprietary
or
it's
it's.
You
know,
research
or
whatever
I
mean.
Even
if
there
are
papers
and
research
I
mean
all
this
is
good
to
know,
but
but
it's
it's.
We
need
to
be
very
clear.
That's
that's
the
point
I
mean
yeah.
I
I
I'm
not
sure
on
the
proprietary,
because
I
think
it's
not
not
available
for
the
generic
public.
It's
proprietary
so
like
it's
not
a
reliable,
available
wireless.
If
it
is
not
available
like
if
it
has
made
it
interesting
that
then
then
it's
it's,
it's
everybody
can
buy
it
or
have
sex
or
but
you
you
know
all
the
problems
with
proprietary
vendor
lock.
B
My
point
was
that
the
technologies
document
is
talking
about.
These
are
the
technologies
that
exist
that
are
appearing
that
could
be
used
in
order
to
enable
reliable
available
wireless
as
a
general
review
of
of
the
state
of
the
art.
So
if
there
are
proprietary
solutions
that
shows
that
there
is
interest
in
solving
some
of
the
problems
at
the
link
there,
and
if
they
were
to
become
open
standards,
then
they
could
be
used
by
whatever
raw
technologies
we
develop
at
layer
3..
B
Perhaps
let's
take
this
offline
but
yeah,
I
think
we.
E
E
B
Third
presentation,
yes,
let
me
start,
let
me
stop
sharing
that.
Let
me
find
the
next
share.
My
screen
too
many
clicks
too
many
clicks.
The
title
is,
the
title
is:
must
match
title
and
it's
there?
Can
you
see
that
right.
A
A
B
E
So
basically
I
already
already
discussed
you
know
the
concept
of
path
and
versus
flow
and
the
idea
that
we
should
be
forwarding
the
path
is:
is
the
network
layer
thing,
whereas
the
flow
is
the
upper
layer
thing?
And
so,
since
we
are
network
layer,
we
should
basically
operate
on
the
concept
of
path
where
multiple
application
flows
can
be
mixed
and
extract
it
from
so.
As
you
know,
that
net
has
two
main
sub
layers
that
the
forwarding
sub
layer,
which
well
already
you
you
for
the
packet
and
it's
kind
of
more
dumb
operation.
E
It
has
but
has
to
be,
for
instance,
scheduled,
whereas
the
services
where
you
do
those
higher
level
operations
like
pre-op,
replication,
elimination,
so
most
of
barrio,
but
not
all
of
them,
and
I
looked
at
how
we
could
basically
signal
the
that
net
information.
That's
not
signaled
so
far
that
net
that
that
pretty
much
says,
use
the
flow
and
that's
gonna,
be
it
and
and
then
you
another
flow
is
another
setup
and
another
treatment.
E
So
ipv6
has
three
main
types
of
extension
leaders
the
hub
by
hub,
which
has
to
be
processed
by
every
hub
but
can
be
ignored
the
the
destination
option
which
is
supposed
to
be
processed
by
the
destination
of
the
packet
and-
and
this
basically
is
source
rotator
like
like
segment
transmitter
and
interestingly,
if
you
place
a
destination
option
before
a
rotting
either
the
destination
is,
is
the
next
type
in
the
routing
error,
meaning
that
you
can
have
something
in
destination
option
and
have
it
processed
by
every
node
which
in
the
those
segment,
routing
or
source
right
leader,
meaning
that
you
could
possibly
use
hub
by
hub
for
the
forwarding?
E
Because
the
forwarding
is
has
to
be
observed
at
every
app
necessarily
and
you
could
use
either
by
hub
because
it
can
be
ignored
or
the
combination
of
destination,
option
and
source
writing
to
signal
to
service
supplier.
So
the
draft
basically
discusses
all
this.
The
big
value
is
to
completely
separate
the
application.
You
know
the
flows
from
the
network
operation,
which
allows
you
to
merge
and
in
multiple
flows-
and
you
know
I
am
inside
the
same
path
and
have
the
same
treatment.
E
Can
we
skim
through
the
slide
just
see
if
there
is
one
we'd
like
to
discuss
before
I
left?
Oh
this?
This
just
shows
you
know
the
the
the
packet
and,
as
you
see
the
hub
by
hop
just
just
one
point
on
that
one.
E
E
Next,
please,
okay,
so
forget
it.
But
if
you
want
to
read
out
the
slides
you'll
find
the
requirement
that
we're
looking
at
so
basically,
this
draft
is
well
the
only
one
I'm
aware
of
where
we
effectively
used
the
ipv6
to
to
signal
that
net
stuff
beyond
you
know
the
application
flow,
and
so
that's
why
I
propose
it
to
that
net.
We
need
it
for
raw,
because
we
have
this
concept
of
path
and
we
have
this
concept
of
flow,
and
but
I
I
believe
that
that
that
was
useful
beyond
row.
E
For
instance,
if
you
do
network
coding,
then
you
need
to
know
which
package
you're
in
and
then
which
code
that
is,
and
so,
when
you,
when
you
reorder
you
you,
you
want
to
reorder
for
just
the
packet
thing,
not
for
the
fragments,
but
when,
when
you
eliminate
you
don't
want
to
emit
different
fragments
path
of
shun
is
typically
what
you
expect
for
that
net.
Something
which
has
to
be
observed
at
the
rehab
and
the
lose
path
option
is
more.
You
know.
E
E
I'm
contributing
this
to
that
net
because,
even
if
it
comes
from
you
know
how
we
describe
the
raw
architecture
and
this
separation
of
flow
and
pipe
really,
and
then
we
do
ipv6.
That
net
doesn't
kill
us
well,
they
can
do
a
lot
more
stuff,
but
in
the
case
of
ipv6,
it's
it's
just
some
subpar
versus
nprs.
So
I
wanted
to
to
to
get
you
know
as
much
possibilities
and
possibly
even
a
little
bit
more
with
ipv6
and
with
mpls
the
cool
thing
with
ipv6.
E
Is
you
don't
really
have
to
have
this
explicit
stack
and
you
have
to
wonder
if
you
have
to
go
beyond
the
first
information,
the
stack
to
or
top
of
stack
to
find
this
other
information.
Here
you
can
really
structure
stuff
and
and
since
we
can
have
tlvs,
we
can
really
say:
oh,
the
redundancy
is
expressed
this
way.
B
Okay,
thank
you
very
much,
pascal
I'm
watching
the
clock.
So
I
think
that
should
be
everything
unless
we
have
anyone
in
the
queue
which
I
don't
okay,
so
we
have
45
minutes
left.
We
actually
have
two
presentations,
so
we
have
a
little
bit
of
time
for
a
qa
at
the
end,
q.
A
at
the
end
pascal,
I
know
you've
got
a
conflict,
so
I
we
may
lose
you
for
the
rest
of
the
session,
but
it's
your
choice.
B
So
next
we
have
I've
lost
the
agenda.
A
It's
carlos.
B
C
There
we
go
okay
thanks
so
well,
very
shortly,
because
for
the
sake
of
time,
by
the
way
I
hear
a
lot
of
echo-
I'm
not
sure
it's,
my
only
me,
but
anyway
I'll
try
to
to
do
it.
C
C
C
C
So
with
this
in
in
mind,
we
presented
this
where
we
last
time
in
itf,
111
and
since
then.
Basically,
what
we
have
done
in
the
draft
is
to
fix
a
lot
of
well
a
lot.
Several
editorial
needs
with
some
improvements,
and
then
we
we
had
some
discussions
in
the
last
atm
meetings
about
this,
including
some
discussions
and
texts
about
non-linguistic
critical
communications.
C
C
C
This
is
the
moment
because
we
are
we.
The
authors
believe
that
we
we
are
ready
for
for
working,
going
working
through
glasgow,
so
we
can
either
decide
to
get
some
additional
deep
reviews
before
or
do
that
through
the
working
group.
That's
called
us
a
question
for
the
chairs
to
decide,
because
from
our
side
we
are
ready
for
for
going
working
with
lascaux.
B
Okay,
thank
you,
carlos
my
only
question.
Apart
from
yes,
I
need
to
do
a
good
review
myself,
and
that
applies
to
all
the
other
working
group
members
as
well.
Please,
how
does
the
use
cases
document
align
with
the
the
industrial
requirements,
because
I
know
this
was
a
the
industrial
requirements
sort
of
arrived
after
the
use
cases
document
was
started?
C
B
Okay,
so
yeah,
thank
you.
So
it
sounds
to
me
that
the
the
authors
of
the
use
cases
document
believe
they
have
aligned
and
referred
to
the
industrial
requirements
document
great,
so
yeah
working
group,
some
reviews,
and
I
think
we
will
ask
for
last
call
on
this
eve.
Do
you
have
comment.
K
A
I
mean,
I
think,
the
resolution
of
the
cross
reference
between
the
two
related
documents
has
been
achieved,
and
that
was
the
topic
of
discussion
last
time.
B
Yeah,
having
having
a
normative
reference
between
the
two
will
force
them
to
be
published
in
lockstep,
but
we
can
go
through
the
working
group
last
call
we
can
do
iesg
review
and
so
on
without
having
to
wait
for
the
other
document.
But
that's
that's
a
problem
for
another
day,
so
I'm
conscious
that
we
have
public
holidays
in
various
countries
and
so
on
running
up
to
the
the
winter
break.
B
So
I'm
tempted
to
say
after
this
ietf
meeting
we
will
probably
put
a
four
week
last
call
to
give
people
a
little
bit
of
time
to
to
do.
Some
further
reviews
does.
Is
that
acceptable
to
carlos.
B
Okay,
I
shall
make
an
eve:
does
that
make
sense
to
you
as
well,
because
I
can't
talk
offline.
B
Okay,
I
shall
make
a
note
of
that.
Anyone
else
got
any
comment
or
should
we
move
on
to
the
next
presentation?
Let
me
just
make
a
note.
H
B
We
have
niels
to
give
us
an
update
on
alvex
niels.
Are
you
happy
to
present
grant
pre-loaded
slides
there
we
go.
I
can
click
the
button.
L
Hey
everyone,
so
that's
not
what
I
want
to
do.
Apparently
I
want
to
share
my
screen.
L
B
L
Perfect
all
right
so
welcome
everyone,
it's
good
to
be
back
because
last
time
I
didn't
have
the
chance
to
present
any
updates.
Now
we
have
made
many
updates.
So,
let's
delve
in
we're
currently
at
version
09
of
the
draft.
The
topic
of
the
entire
thing
is
the
album
digital
aeronautical
communication
system
called
in
short,
ldacs.
L
Here's
the
note
well-
and
this
is
now
the
official
title
of
the
entire
thing
with
the
abstract
here.
Please
note
that,
apart
from
reliability
and
availability,
if
ib
connectivity
over
ldax,
we
added
security
here
in
the
in
the
abstract,
because
it
was
one
of
the
major
updates
that
we
did
here.
You
can
see
the
changes
on
the
left
hand,
side
from
the
previous
document
and
right
hand,
side
and
now
the
current
version,
as
you
can
see,
we
streamlined
a
lot.
L
So
the
biggest
thing
that
has
happened
is
basically
that
we
have
seen
some
overlapping
details
and
try
to
merge
them
to
make
reading
through
the
document
as
smooth
and
easy
for
an
audience
as
possible.
So
that
was
probably
the
biggest
thing
that
happened
over
the
course
of
the
last
three
months.
Just
really
having
external
reviews
going
through
the
thing
and
then
saying
hey
if
you
move
that
kind
of
information
there
or
I'm
missing
that
piece
here,
that
was
the
most
important
thing
we
did
also.
L
We
received
feedback
from
the
writing
directorate.
I've
incorporated
that
here
and,
as
you
can
see
so
the
blue
dots,
the
biggest
thing
that
we
changed
is
the
chapter
nine
with
security,
but
also
we
worked
on
the
introduction.
We
worked
on
the
altx
protocol
stack
to
make
it
a
little
bit
more
clear
and
then
also
worked
a
lot
in
the
normative
and
informative
references
and
just
edit
the
latest
publications
on
the
entire
thing.
L
So,
as
I
said
so,
we
address
the
entire
feedback
from
the
writing
directorate
and
we
uploaded
the
version
online.
We
replied
to
thomas
razi
and
I
think
with
that
at
least
the
open
issues
should
be
addressed.
I'm
happy
to
give
some
feedback
on
that
again
references
streamed
at
the
work
and,
as
I
said,
the
biggest
thing
was
reworking
the
elder
security
section.
L
Also,
the
the
thing
was
that
we
wanted
to
add
post
quantum
security
to
the
overall
lx
security
architecture,
because
that
hasn't
been
done
yet.
So
that
is
the
the
overall
picture
now
to
the
single
chapters.
So
we
got
a
lot
of
questions.
What
aldex
actually
is
and
well
aldex
is
a
wireless
communication
system
for
safety,
related
communications
related
to
safety
and
security
of
flight
and
regulator
for
flight,
meaning
that
you
have
several
ground
stations.
You
have
a
radio
in
the
aircraft
and
only
safety.
L
Critical
information
is
transmitted
via
ldac,
so
that
means
prior
to
that
it
was
the
video
mode
2
radio
that
was
done.
That
has
done
this
kind
of
task.
L
Previous,
even
later,
back
everything
was
communicated
by
a
cars,
and
now
ldx
is
from
the
view
of
iko
is
basically
an
an
access
technology
network
access
technology,
basically
just
enabling
the
data
link,
as
I
said,
between
aircraft
and
ground,
with
data
flowing,
for
instance,
between
airlines
and
the
aircraft
or
the
network
operators
and
the
aircraft,
and
because
there
have
been
so
many
changes
in
regulatory
documents.
L
So,
for
instance,
iko
has
worked
on
something
so,
okay,
aka,
the
international
civil
aviation
organization,
has
worked
on
the
document,
989
6
in
the
version
03
specifying
the
aeronautical
telecommunications
network,
that's
the
atn
over
internet
protocols,
infrastructure
and
what
they
did
basically
was
saying
hey
until
now,
the
entire
data
was
transmitted
by
akas,
then
at
osi,
and
now
we
really
want
to
move
it
to
ip
and
in
that
regards
to
ipv6,
and
so
other
regulatory
organizations
such
as
rtca
ring
or
uk,
updated
their
respective
documents
and
also
published
new
ones.
L
That
I
mentioned
here,
because
one
of
the
biggest
questions
that
we
received
is
basically
so
yes
now
we
know
what
aldex
is,
but
what
kind
of
traffic
will
flow
over
it?
So
ldx
will
be
nexus
network
technology
for
the
80
and
ips
plans
off
of
iko,
and
another
question
that
we
received
is
okay,
so
the
current
plan
is
that
ldx
will
rule
out
starting
2024,
probably
to
to
due
to
due
to
covet
it'll,
be
a
little
bit
late,
so
maybe
2026,
maybe
even
2028.
L
But
the
thing
is,
the
initial
rollout
will
start
in
europe
and
then
probably
asia
has
a
large
demands.
The
s
is
so
so
the
faa
is
even
starting
to
integrate
ldex
into
the
the
roadmap,
so
it
will
probably
start
in
europe
then
go
to
asia,
then,
and
then
to
us,
and
maybe
in
10
15
years
it
will
be
available
worldwide.
L
Next
up
was
the
characteristics
of
aldex.
So
first
we
we
said:
okay
from
the
previous
systems,
such
as
video
mode,
two,
which
doesn't
have,
for
instance,
for
instance,
a
message
prioritization.
L
It
doesn't
have
security,
so
we
just
said
what
are
the
new
things?
What
are
the
characteristics?
So
it's
a
very
robust
system
because
in
the
l
band,
so
just
on
the
frequency
band
there's
pretty
little
space
left.
So
it
has
to
be
built
as
an
inline
system,
and
then
we
clarified
again
how
the
entire
sub
network,
but
also
the
protocol
stack
of
lx
works.
L
So
here's
basically
the
idea
that,
via
an
access
router,
then
as
an
a
to
ground
air
to
ground
router,
the
entire
thing
goes
to
the
aeronautical
telecommunications
network
and
via
the
axis
routers,
several
ground
stations.
L
That's
let's
say
over
europe
are
connected
to
that
one
and
their
user
plane
data
is
transmitted
between
a's
and
g's,
then
for
the
protocol
stack,
that
was
basically
just
a
clarification
of
how
the
entire
thing
looks
without
x
and
that
ipv6
will
probably
be
the
traffic
layer
that
ldx
will
serve
now
to
the
biggest
change
security.
L
As
I
said,
ltx
is
regarded
as
a
network
access
technology
in
the
atm
ibs
frame
and
several
documents
pretty
strictly
clarify
what
kind
of
requirements
those
technologies
have
to
have,
such
as
access
protection
mechanisms
such
as
certain
latency
that
it
has
to
support.
For
instance,
there's
a
document,
the
rtc80
350a
that
specifies
for
a
certain
kind
of
message
type
and
those
message
types
is
what
aldex
is
going
to
be
for
in
the
future
that
within
10
seconds,
this
message
has
to
be
delivered.
L
Okay,
the
thing
is
10
seconds
doesn't
look
like
a
lot.
It
does
does
look
like
a
lot
of
time,
but
the
thing
is,
if
you
add,
authentication
procedures,
key
establishment
procedures,
so
basically
the
initial
part
of
the
security
to
it
and
then
after
that
is
done,
then
the
message
has
to
go
through
the
10
seconds
in,
for
instance,
very
worst-case
situations
where
the
link
is
is
very
weak,
so,
for
instance,
you're
at
the
edge
of
a
cell
and
the
bit
error
rate
goes
up
this.
L
This
can
be
a
problem,
so
the
entire
thing
had
to
be
designed
in
with
with
that
in
mind
that
whatever
you
do,
the
10
seconds
is
not
to
be
touched,
and
then
we
presented
in
the
chapter
the
distinction
between
user
and
control
data
protection
of
ldx,
because
there's
pretty
clear
information
on
how
user
data
is
to
be
protected,
for
instance
on
their
safety,
critical
user
data
ats
data
that
mostly
needs
integrity
and
authenticity
protection,
but
then
there's
also
airline
data,
business
data
and
and
obviously
that
needs
to
be
encrypted.
L
So
we
had
to
make
this
distinction
between
those
two
within
the
user
data
space
and
now
for
the
control
data
space.
So
the
entire
thing.
Basically,
what
keeps
ldx
alive
the
most
important
thing
was
that
it's
available
and
nobody
can
actually
modify,
for
instance,
for
instance,
resource
allocations,
because
resource
allocations
isn't
what
makes
aircraft
or
ground
stations
allowed
to
send
user
data.
L
So,
with
those
distinctions
in
mind,
we
clarified
that
pretty
much
now
in
the
security
section,
we
laid
out
an
ldx,
a
public
key
infrastructure
with
corresponding
certificates,
and
then
we
went
over
the
entire
cell
attachment
procedure.
So
the
thing
where
an
aircraft
enters
a
grounds.
L
Basically
an
lx
cells
who
comes
into
the
vicinity
of
a
ground
station,
does
basic
communications
and
and
enablement,
and
that's
during
the
cell
entry
procedure
now
both
can
communicate
and
then
there's
the
possibility
to
do
the
entire
authentication.
Key
establishment
thing
in
a
second
step
called
make
so
mutual
authentication
key
establishment.
L
So
we
clarified
that
also
why
those
two
things
are
separated,
and
then
we
went
on
and
clarified
security
levels
for
ldx
because,
as
a
rollout,
a
time
will,
as
I
said,
be
in,
like
probably
two
three
worst
case.
Five
years,
elliptic
curve
will
probably
be
fine,
so
we
need
to
save
a
lot
of
security
data,
obviously,
because
every
bit
that
you
send
in
in
terms
of
security
data
is
a
bit
that
you
lose
in
terms
of
actual
payload.
L
So
here
the
the
design,
the
most
important
design
goal
is
that
you
have
to
save
on
the
security
data
bandwidth,
meaning
that
elliptic
curve
is
quite
elegant,
also
curve
compression
stuff
like
that.
So
it
can
save
a
lot
of
data.
L
But
then,
when
you
look
at
post
quantum
security,
for
instance,
for
key
encapsulation
or
signatures,
then
you
will
realize
oh
boy,
you
run
into
10
times
the
traffic
even
20
times
the
traffic,
because
even
the
smallest
and
slimmest
lightweight
crypto
in
post
quantum
can
be
quite
a
lot
to
to
transport,
and
so
we
identified
two
schemes
and
mentioned
them
in
the
document.
So
this
is
one
way
forward.
L
Then
again,
on
the
user
data
protection
part,
you
have
the
distinction
between
air
traffic
services,
so
safety,
critical,
stuff
and
airline
operational
control
data
and
the
one
thing
has
to
be
absolutely
integrity,
authenticity
protected
and
the
other
thing
has
to
be
encrypted.
So
we
suggested
two
different
algorithms
to
do
that.
L
Lastly,
to
the
control
channel
part
as
I
get
as
I
said,
this
is
where
the
magic
of
aldex
happens,
because
here,
on
the
left
hand
side
you
can
see
the
superframe
structure
of
ldax
going
for
240
milliseconds
at
the
beginning
of
a
superframe.
You
have
the
broadcast
channel
at
the
top,
and
this
is
where
a
ground
station
basically
says:
hey
I'm
here,
please
talk
to
me
and
the
random
access
channel.
That's
the
one
below
r,
a
c
h.
L
This
is
where
an
aircraft
can
request
access
to
a
cell,
and
the
problem
is
due,
to
other
reasons,
it's
hard
to
put
in
security
here.
So
we
said:
no,
we
don't
want
to
put
security
here,
but
what
when?
Where
security
is
needed?
Absolutely
needed
is
in
the
dedicated
and
common
control
channel
on
the
right
hand,
side.
So
ccch
is
the
common
control
and
dcch,
because
the
common
control
is
where
aircraft
are
told
when
to
send
when
they
are
allowed
to
send
user
data.
L
And
then
the
dedicated
control
aircraft
demand
a
certain
amount
of
user
data
to
be
sent,
and
so
you
have
to
be
sure
that
whoever
is
requesting
resources
here
is
actually
allowed
to
do
that,
and
this
is
why
protection
mechanisms
must
be
in
place
here,
and
so
this
is
what
we
did
with
with
the
security
chapter.
L
We
clarified
all
those
open
points
and
also
added
that
the
entire
thing
is
a
work
in
progress,
so
the
entire
standard
is
obviously
not
done,
but
this
is
what
we
are
laying
out
now
for
review,
because
we
got
some
requests
on
on
how
security
handled
in
detail-
and
this
is
what
we
wanted
to
offer
here
in
the
document-
a
high
level
view
that
helps
understand
the
reader,
the
design
choices
we
made,
and
I
think
that's,
that's
it
from
my
side.
Those
were
the
updates.
L
B
Thank
you
niels.
I
can
answer
what's
next,
we
are
still
waiting
for
other
review
feedback
from
the
other
areas.
So
iesg
review
goes
to
all
the
areas.
Rooting
obviously
are
moving
faster
than
everyone
else
at
the
moment.
So
you
got
your
review
back
from
them
very
quickly.
I
imagine
security.
As
with
all
these
things,
there
are
the
the
various
area.
Reviewers
have
a
queue.
I
imagine.
B
Security
are
going
to
take
their
time
on
this,
because
this
is
complex
and
actually,
in
my
experience,
the
security
area
always
give
really
good
reviews,
but
they
take
their
time.
So
there
will
be
more
reviews
coming
back
from
other
areas
and,
I'm
afraid
to
say
this
does
just
take
a
bit
of
time.
So
a
little
bit
of
patience
does
that
answer
cool
so.
M
So
just
since,
since
I
was
asked
to
comment
also
to
the
extent
that
I
can
kick
those
reviews
along
faster,
I
will
I
will
do
so.
B
Thanks
john,
I
think
for
things
like
ops
and
interior
and
things
like
that
there
it
will
be
a
a
quick
text.
Editorial
read
to
see
whether
they
can
understand
it.
I
can't
see
that
they're
going
to
have
much
operational
comments.
If,
but
I
may
be
wrong,
I
don't
I
don't
know
how
transport
are
going
to
care
too
much.
They
may
say
why
aren't
you
doing
this
in
the
transport
area,
but
that's
a
discussion
for
for
the
ad
and
the
chairs
to
have
with
them,
but
it's
fine
as.
B
I'll
talk
with
those
ideas
about
you
know
expediting
it
yeah,
because
I
I
see
this
as
complex
and
I
it's
they're
gonna
need
a
bit
of
warning
about
this,
because
it's
it's
a
complex
piece
yeah.
Can
I
make
a
request
to
the
working
group?
Of
course,
in
light
of
the
reviews,
the
text
is
changing,
as
I,
as
I
said
before,
can
you
have
a
chance
working
group
members
just
to
have
a
re-read
and
check
that
you're
happy
with
the
changes
that
have
been
happening,
because
this
is
a
working
group
document?
B
B
Yeah
good
work,
guys
it's.
This
is
a
this
is
a
mighty
document,
so
yeah.
Thank
you.
So
thank
you
niels.
I
think
we
have
now
got
to
the
last
20
minutes
of
the
session,
so
really
open,
mic
questions
comment.
B
So,
just
looking
down
my
list
of
notes,
the
chairs
will
set
up
some
informal
interim,
maybe
bi-weekly,
meetings
depending
on
public
holidays,
for
a
chance
to
really
get
on
top
of
the
raw
architecture.
B
We
will
be
updating
some
of
the
milestones
based
on
some
of
the
feedback
we've
had
so
far.
We
will
guess
some
of
the
far
off
ones.
We
will
set
more
realistic
milestones
for
some
of
the
near
ones.
Hopefully
that
will
please
john
and
he
can
then
click
approve
to
some
of
our
updates
working
group
last
call
for
the
technologies
draft.
It
will
be
a
four
week
last
call
with
a
request
for
please
everybody
review
the
references,
particularly
those
of
you
with
influence
or
understanding
of
the
referenced
sdos.
B
The
use
cases
again
we'll
put
a
full
week
on
there,
because
we'll
have
two
working
group
last
calls
happening
at
the
same
time
and
public
holidays
and
to
give
everyone
a
chance
to
review
that
as
well,
but
otherwise
that
looks
pretty
good.
We'll
have
some
documents
from
working
group
last
call:
we've
got
ldax
in
iesg
review.
B
We
should
get
some
rfcs
coming
out
of
this
group
sometime
next
year,
because
the
editors
always
take
a
little
bit
of
time
to
do
it
properly,
which
is
nice,
but
I
think
we
can
be
pleased
as
a
working
group
that
we're
producing
things
or
documents
of
value,
which
is
important,
so
well
done,
but
it
does
rely
on
everyone's
good
reviews
as
well
eve.
Do
you
have
anything
to
add?
I
feel
like
I've
been
talking
for
hours,
no.
A
Entirely
so
I'm
quite
grateful,
but
actually
I
will
express
my
gratitude
as
well
that
things
have
progressed
and
that
the
discussions
have
been
both
respectful
but
very
candid
and
honest,
and
that
we're
working
through
some
of
the
tussles
in
the
discussions
around
drafts
and
and
references
and
things
like
that.
So
thank
you
to
everybody.
B
Oh,
thank
you
eve.
Thank
you
very
much
yeah.
So
we'll
the
chairs
will
take
an
action
to
try
and
produce
some
meeting
notes
that
will
take
a
little
bit
of
delay.
So
john,
when
you
send
us
the
mandatory
email
in
four
days
time
saying.
Please,
update
update
your
minutes
upload
your
minutes.
We
will
be
composing
the
minutes.
Just
for
the
record.
You
will
be
able
to
find
the
video
transcript
of
this
entire
meeting
on
youtube.
At
some
point,
the
ietf
publishes
everything
on
youtube
so.
A
B
Brilliant
okay,
in
which
case
I'm
tempted
to
close
eve,
any
objections.
Yes,.
B
Yeah,
okay!
Well!
Thank
you
very
much
for
your
attendance.
Oh
john
makes
a
comment
in
the
chat
to
say
that
you
can
use
youtube
auto
transcription.
A
B
B
We
will
be
holding
a
meeting
ietf113,
which
is
in
bangkok,
allegedly
in
person.
Kovid
willing
transports
permissions
willing,
may
see
some
of
you
in
person
maybe
attending
virtually,
not
sure
what
my
situation
is,
but
we
plan
to
hold
a
meeting
there.
E
M
B
M
B
Okay,
okay,
I
missed
the
announcement,
obviously,
but
it
would
be
nice
to
meet
again
in
person.
You
know
kovid
restrictions
permitting,
so
we
will
the
key
point
is
we
will
be
holding
a
raw
session
for
ietf
one
one:
three,
where
we
will.
A
We
have
never
met
in
person.
We
had
the
unlucky
situation
that
our
first
ietf
was
the
march
itf
as
covid
hit,
and
so.
B
B
Yes,
because
we
only
did
the
buff
in
person
so
yeah,
the
raw
working
group
has
never
met
in
person
there.
We
go.
That's
a
bit
of
ietf
history
for
people,
so
yeah
fingers
crossed
okay,
I'm
gonna,
I'm
gonna
draw
it
to
a
close
there
and
say.
Thank
you
very
much.
B
And
speak
to
you
later
on
and
the
next
ietf,
if
not
before,
okay.
Thank
you.
I
don't
know
how
to
I
don't
know
how
to
close
the
session
by
the
way.
A
All
the
way
to
the
right
at
the
top
it
says,
leave
the
room.
It
looks
like
a
gas
station
pump,
but
that's.