►
From YouTube: IETF113-RAW-20220321-0900
Description
RAW meeting session at IETF113
2022/03/21 0900
https://datatracker.ietf.org/meeting/113/proceedings/
C
D
I've
seen
the
time-
let's
let's,
let's
start
so.
D
Excellent
so
good
morning,
everybody
it
is
morning,
local
time.
This
is
raw,
reliable
and
available
wireless.
So
we
are
doing
a
full,
hybrid
experiment
here
by
having
the
chairs
both
remote
and
karina
and
carlos
standing
in
being
our
in-room
delegates.
So
thank
you
very
much
to
both
of
them
for
trying
it.
I
think
we
have
more
chairs
and
delegates
that
we
have
attendees
in
person
but
celebi.
Hopefully
this
will
change
over
time.
So
can
I
eve?
Can
I
have
the
next
slide
please,
or
can
I
just
take
control.
B
A
B
D
Much
so
ietf
note.
Well,
I
do
hope
you
are
familiar
with
the
noteworld
at
the
moment
having
attended
a
few
of
these
meetings
before
if
you
are
unfamiliar.
This
is
your
rights,
so
important
things,
contributions
covered
by
patents
and
patent
applications,
participation.
You
are
agreeing
to
be
recorded,
there's
also
the
personal
information
handling
by
the
ietf
and
your
agreement
to
behave
respectively,
respectfully
in
association
with
others.
So
please
read
this
information
in
depth
at
your
leisure
if
you
are
unfamiliar
with
it.
D
Otherwise,
please
be
aware
that
this
meeting,
like
any
other
working
group
meeting,
operates
under
the
ietf
note.
Well,
and
here
are
the
exact
bcps
which
cover
the
the
fine
details.
So
there's
a
record
here
so
ietf113.
This
is
a
hybrid
meeting
which
is
exciting.
D
I
can
see
a
lot
of
people
are
participating
remotely,
but
if
you
are
on
site-
and
I
do
have
a
view
of
who's
in
the
room,
there
is
an
on-site
tool
so
that
we
can
integrate
the
meeting
queue
with
the
remote
queue
and
we'll
see
how
well
that
goes.
I
mean
meet
echo
I
think,
has
turned
into
a
really
elegant
tool
over
the
last
couple
of
years.
So
I'm
confident
that
this
will
work
well.
D
Key
things
is
in-session
participants.
Please
keep
your
audio
and
video
off
if
not
using
the
on-site
version,
not
100
sure
what
that
means,
but
that
I
assume
is
to
reduce
echo
from
the
room,
as
you
can
tell
we're
in
quite
a
large
echoey
room
in
vienna,
but
it's
not
destroying
the
audio
too
much.
For
me,
I
apologize
if
anyone
else
is
having
terrible
feedback.
D
Right,
administrative,
yeah,
so
yep.
This
is
obviously
on
meat.
Echo,
I'm
assuming
everyone
is
on
meat
echo,
although
I
suppose
you
could
be
connecting
via
jabba,
but
there
is
the
url
for
the
meat
echo
automatic
blue
sheets,
so
the
days
of
pen
and
paper
have
passed
or
are
there
blue
sheets
in
the
room,
carlos
and
karina?
D
No,
so
we
seem
to
have
lost
kodi
md,
but
we
now
have
hedge
dock
built
into
the
meet
echo
ui.
So
we
would
like
to
do
collaborative
notes.
If
there
is
someone
who
is
willing
to
act
as
an
interactive
note
taker.
That
would
be
great,
but
please
everybody
join
in
to
make
sure
a
any
spellings
of
names
are
correct
because
there
are
a
combination
of
different
languages
and
different
names.
So
please
make
sure
that
that
whoever
is
taking
notes
has
got
your
name
right.
D
That's
very
handy
and
also
double
check
that
the
point
you
were
trying
to
make
was
captured
correctly.
So
anything
you
can
do
in
that
way
would
be
great.
So
the
mating
list,
as
usual,
is
raw
at
iatf.org.
You
should
please
subscribe
to
that.
If
you're
interested
in
the
proceedings
of
raw
and
the
meeting
materials
for
this
session
so
that
it's
the
slides
and
the
agenda
and
so
on,
are
all
at
the
url
at
the
bottom
right
I'll
hand
over
to
eve.
B
Oh
well,
I
was
going
to
say
that,
due
to
the
hour
where
I
live,
it
is
about
2
a.m.
I'm
likely
to
be
quite
silent
during
the
meeting
and
I
will
be
taking
notes
so
please
join
me.
I
see
that
there
are
a
few
others
on
here.
So
thank
you
very
much.
B
Our
agenda
is
quite
full.
Today
we
are
going
to
hear
from
nils
on
the
status
of
the
ldx
draft,
which
is
wending
its
way
through
review,
and
we
also
just
had
the
use
cases
draft
submitted
and
carlos
will
give
us
an
update
after
it
reached
working
goose
group
last
column
was
also
submitted
to
for
for
formal
review.
B
Pascal
will
give
us
an
update
on
the
architecture
draft
which,
after
the
last
itf,
was
separated
from
the
framework
draft,
and
we
will
hear
about
both
of
their
status
and
then
we
have
some
an
update
on
the
oam
support
draft,
which
of
course
has
its
mirror
drafts
in
the
debt
networking
group
as
well.
We
will
hear
from
forbids
on
the
status
of
that
and
carlos
will
come
back
to
us
to
speak
about
a
new
draft
that
he
has
submitted
for
consideration
on
multi-domain
extensions.
B
D
Thanks
steve,
if
he
is
available,
should
we
go
straight
on,
fell
back
or
does
anyone
wish
to
pass
the
agenda
just
very
quickly
checking
the
queue.
D
If
you're
available
or
excellent,
I
believe
we're
going
to
be
the
magic
of
if
you
do
request,
to
share
slides.
Oh
we're
trying
to
make
this
slide
thing
work
so
pass
slide
control.
D
So
I'm
talking
to
myself
now,
while
I
try
and
click
buttons,
which
is
a
little
unprofessional
so
niels,
you
should
have
control
of
slides.
E
D
E
All
right
good
morning,
everyone
I'll
be
relatively
brief
today,
but
I
want
to
talk
a
little
bit
about
the
changes
that
we
did
from
the
last
version
09
to
the
version
10.
Now,
thanks
to
john
scott,
we
really
received
some
great
feedback
that
we
incorporated
in
the
draft,
and
I
think
the
draft
is
just
and
the
pros
have
been
uploaded
the
version
10..
E
It's
a
note
well,
and
here
are
the
changes
so
from
the
version
09
to
the
version
10.
The
outline
basically
remained
the
same.
We
did
some
changes
in
chapter
three
with
the
motivation
use
cases,
then
we
adapted
some
lines
in
the
requirements
section
and
I
think
the
the
biggest
change
happened
in
the
reference
section,
since
we
removed
a
lot
from
the
normative
or
basically
everything
from
the
normative
to
informative
references.
E
E
So
in
the
motivation
use
cases,
we
weren't
clear
enough
about
the
current
security
concept
that
is
in
place.
So
if
we
look
at
aeronautical
communications
today
and
we're
talking
about
terrestrial
based
long-range
communications,
there's
just
one
system
in
place
really
that's
currently
rolled
out.
E
It's
called
the
video
number
two,
that's
the
vhf
data
link
mode
too,
and
it
was
rolled
out
in
the
90s
about
that,
and
there
are
really
no
cyber
security
measures
on
the
link
in
itself,
and
so
the
entire
security
concept
relies
on
phraseology,
well-trained
personnel
pilot
and
air
traffic
controller,
really
knowing
each
other,
but
there's
no
security
measures,
as
we
would
define
it
here
and
essentially
had
to
clarify
that,
and
that
is
one
of
the
big
differences
between
the
current
version
of
aeronautical
communications
and
the
one
we're
proposing
here
with
ldx.
E
The
second
one
is
about
the
separation
of
safety
based
communications
and
entertainment,
or
in-flight
entertainment,
based
communications,
and
this
can
so
so
there's
a
scenario
that
can
happen,
for
instance,
the
flight
crew
or
the
pilots.
They
have
a
limited
data
link
available,
meaning
they
have
around
10
kilobits
in
in
up
and
down
stream,
while
a
passenger
can
watch
netflix
in
plain
basically,
but
those
are
different
domains
right.
E
So
one
domain
is
for
communicating
safety
critical
stuff,
so
basically
high
reliability
and
availability
are
key,
so
the
links
are
designed
with
more
robustness
in
mind
and,
on
the
other
hand,
it's
just
about
throughput,
and
this
is
why
we
have
those
two
concepts
and
both
of
them
obviously
must
be
strictly
separated,
and
this
also
happens
with
aldex
as
well.
D
E
All
right
so
that
covers
chapter
three
in
chapter
six
with
the
requirements
we
made
clear
again
that
there's
a
huge
change
currently
happening
with
aeronautical
communications.
So
until
now
most
of
the
stuff
was
communicated
by
a
voice
and
there's
a
protocol
from
the
70s
called
a
cars.
Then
in
the
90s
there
was
the
80
in
osi
and
since
the
2010,
the
entire
idea
is
to
run
traffic,
so
aeronautical
telecommunications
network
traffic
via
an
id
based
network,
and
it's
also
why
we're
here
with
the
ietf
and
the
envisioned
network.
E
So
it's
not
installed
in
place,
except
for
some
experimental
airports,
is
that
you
have
an
ipv6
based
network
for
aeronautical
communications,
but
you
want
to
have
again
separation
of
consensus.
So
if
you
want
to
have
the
aeronautical
ip
internet
so
basically
for
routing
the
atm
traffic
and
obviously
you
want
to
have
the
the
customer
internet
as
separated
as
much
as
possible
so
that
you
don't
you're
not
able
to
switch
from
one
to
the
other
and
cause
shenanigans.
E
The
second
part
was
about
the
rollout.
So
I
think
everyone
is
aware
that,
with
the
pandemic,
everything
has
scheduled
a
little
later
than
was
anticipated,
so
the
entire
ruler
was
initially
planned
for
2024
and
now
we're
on
2025-26.
E
Yeah
last
thing
that
we
changed
again
with
the
references
with
with
a
little
bit
of
back
and
forth
and
discussions,
we
basically
adapted
the
document
to
such
a
state
that
if
you
read
the
entire
document
that
you'll
be
able
to
understand
what
aldex
is
what
it
does
and
you
don't
really
need
additional
information
to
grasp
the
concept.
If
you
want
to
go
deeper,
such
as
what
kind
of
modulation
schemes
are
done,
how
does
the
file
protocol
look
like
then?
E
Obviously,
we
point
to
other
references,
but
it's
not
necessary
to
read
them
to
fully
understand
the
concept
of
it,
and
I
think
that
covers
basically
all
the
changes.
Obviously,
we
changed
knits
and
bits
here
and
there
some
some
rewritten
some
sentences
to
make
them
better,
understandable
and
yeah.
At
this
stage.
I
just
want
to
thank
john
for
the
really
really
the
feedback
and
yeah
from
there.
D
G
Yeah
so
I
I
went
and
looked
at
the
preprint
and
it
looked
like
everything
was
well
covered.
Thank
you
very
much
and
and
thanks
for
writing
an
easy
to
read
document
by
the
way.
I
know
that's
not
easy,
anyway
yeah,
I
think
we're
ready.
So
you
know
so
sometime
this
week
I
will
hit
the
button
to
start
the
ietf
last
call
and
we'll
be
on
our
way.
D
Excellent
thanks
john.
So
that's
that's
good.
It
looks
like
we
might
have
our
first
raw
rfc
and
it
might
be
ldx
but
yeah
fingers
crossed.
Thank
you
very
much
niels.
So
thank
you
since
then.
I
have
closed
the
agenda,
so
I
can't
tell
you
what's
happening
next.
So
next
up
we've
got
if
the
oh
karina
you're
in
the
queue
go
for
it.
G
Oh,
that's
a
good
question,
I'm
not
sure
if
there's
a
convention
for
that,
I'm
comfortable
with
you
either
removing
the
normative
references
heading
or
leaving
it
empty
either
one
is
okay.
The
the
rfc
editor
will
fix
it
to
match,
whatever
the
their
preferred
style
is
once
it
gets
into
edit.
I
guess
my
my
instinct
would
be
to.
G
Actually,
there's
an
argument
either
way,
so
my
first
instinct
would
be
to
go
ahead
and
leave
it
in
sort
of
as
a
you
know.
This
space
intentionally
left
blank,
but
really
do
as
you
prefer.
D
Karina
my
my
advice
would
be
the
rfc
editors
are
very
good
at
what
they
do
in
terms
of
editing
so
leave
the
heading.
There
say
this
section
intentionally
left
blank
and
they
will
fix
it
and
they
will
fix
it
with
you,
they're
very
good
at
it.
So
don't
worry
too
much
about
that
sort
of
thing.
As
long
as
the
content
is
good,
they'll
they'll
really
help
you
with
the
rest.
A
D
D
Thanks
guys,
so
next
up
we
have
carlos
with
the
use
cases
draft
and
as
carlos
is
in
the
chair.
I'm
just
gonna
get
out
of
the
way
and
let
him
to
do
the
thing.
H
H
So
this
is
the
outline
just
for,
for
those
that
may
not
be
familiar
with
the
draft.
There
are
several
use
cases
described,
aeronautical
communications,
amusement
parks,
wireless
for
industrial
applications,
probably
on
video
wireless
gaming,
uav
and
b2b
platoonian
control
edge,
robotics
control
and
emergencies,
and
for
each
of
the
drafts
we
have
different
sections
analyzing
the
motivation
for
why
we
need
the
use
case,
the
need
for
wireless,
for
that
particular
use
case
and
kind
of
the
requirements
for
for
raw.
H
We
also
added
a
subsection
for
the
non-latency
critical
considerations,
because
raw
is
not
only
about
latency,
maybe
about
latency,
of
course,
but
it
may
be
also
about
resiliency
in
some
scenarios,
where
the
latency
is
not
that
critical.
So
we
believed,
based
on
some
comments
from
pascal,
that
was
a
that
was
a
important
thing
to
cover
in
the
draft,
and
we
basically
adapted
the
structure
to
to
highlight
that
point
as
well.
H
So
by
doing
that,
we
also
did
some
editorial
fixes
and
improvements
along
the
way
and
in
terms
of
next
steps.
Well
now
it's
it
was
publication
requested.
So
it's
at
the
asc
and
we're
basically
waiting
for
comments
at
that
at
that
stage,
and
then
we
will
try
our
best
to
to
address
the
comments,
so
not
really
much
to
what.
At
this
point
any
questions
comments.
D
I
was
just
going
to
add
a
thank
you
for
getting
the
document
to
the
state
it's
in
at
the
moment,
and
thank
you
to
the
reviewers.
I
think
obviously,
charney's
is
in
the
depth
of
previewing
ldx
at
the
moment,
and
so
this
is
next
in
his
queue
when
he
has
the
cycles.
So
thank
you
very
much.
D
Excellent,
so
next
up,
we
have
pascal,
who
is
speaking
about
the
architecture
and
the
framework
documents
and
the
split
between
the
two
and
so
he's
got
quite
a
big
time
slot
for
this.
Basically,
it's
pascal
knows
what
you're
doing
so.
Take
the
time
to
split
it
up,
as
you
like,
go
ahead.
C
Okay,
I
hope
you
can
hear
me,
I'm
sharing
the
architecture
slides
and
if
it
doesn't
consume
more
space,
I
can't
send
the
video
out.
C
I
guess
there
we
go
guys
yes,
so
this
is
about
the
the
raw
architecture
document,
which
was
split
between
architecture
and
framework,
as
we
said
so
I
won't
go
back
to
this
slide,
which
is
basically
summarizing
what
we
expect
to
do
in
very
short,
it's
it's
a
matter
of
balancing
the
use
of
energy
and
spectrum,
the
more
energetic
spectrum
you
use,
the
more
reliability
you
get
on
your
transmissions,
but
on
the
other
hand,
you
have
constrained
energy
and
constrained
bandwidth
in
the
wireless
spectrum.
C
So
you
cannot
push
too
far
on
either
energy
bandwidth.
So
we
have
to
find
engineered
methods
to
to
optimize
effectively
the
balance
between
how
much
reliability
and
variability
we
get
and
how
much
energy
and
bandwidth
spectrum.
Basically
we
stand.
We
spend
getting
that
reliability.
So
that's
that's
a
generic
concept
for
common
context
forum.
C
Now
the
initial
document
had
two
main
pieces,
which
we
kind
of
split
into
architecture
and
framework.
One
is
is
forward-looking,
it's
basically
giving
the
the
broad
building
blocks,
and
that
includes
terminology,
because
if
you
don't
have
a
crisp
terminology,
you
cannot
go
anywhere
because
we
don't
even
understand
each
other.
So
so
we
need.
C
We
need
to
have
a
very
crisp
energy
in
which
we
can
build,
and
we
we
also
need
to
say
hey
here,
is
there
are
the
objects
we
are
manipulating
and-
and
here
is
what
we
are
trying
to
achieve,
but
without
giving
here
is
why
you
take
that
draft
and
we
are
using
that
protocol
because
we
don't
even
know
yet
so
clearly
we
position
ourselves
as
spin-off
or
maybe
hopefully,
one
day
you
spin
in
of
that
net,
focusing
on
wireless
and
reliability,
but
exactly
which,
which
drafts
rfcs
will
will
be
proposed
and
to
achieve
role.
C
C
The
framework,
on
the
other
hand,
is
to
be
our
journal.
If
you
like,
I
mean
following
our
progress.
The
more
we
focus
on
there
is
the
technology
that
we're
going
to
use
this
draft
this
rfcs,
those
will
be
how
we
effectively
build
our
solution,
and
so
the
other
idea
is
that
the
framework
is
to
be
read
by
people
who
bought
the
work
in
between,
so
they
can
see
where
we
are
and
it
will
be
published
at
the
very
end.
C
C
So
yeah
we
have.
We
hope
we
are
close
to
workgroup,
let's
call
it
the
architecture
and
effectively
for
the
framework.
We
want
to
keep
it
alive
until
the
very
end
of
the
of
the
work.
Now.
The
the
first
thing
we
need
to
really
agree
about,
as
I
said,
is
the
terminology
and,
and
we
realize
trying
to
dig
into
what
we
want
to
achieve
that
there
might
be
a
gap
and
I
just
reviewed
an
excellent
review.
Thank
you
so
much
lou,
an
email
by
lou
that
was
posted
this
morning
on
the
mailing
list.
C
I
mean
at
least
alpha.
These
commands
are
really
related
to
you
know,
goal
to
terminology,
and
then
the
rest
is
obviously
the
goal
and
the
context,
but
the
basically
the
terminology
will
be
very,
very
critical
to
us.
On
the
one
hand
we
want
to
to
use
you
know
as
much
common
terminology
as
the
rest
of
the
ietf,
so
we
don't
want
to
involve
a
different
term
for
something
that
exists,
which
is
kind
of
a
quantum
and
valuable
track.
C
On
the
other
hand,
when
things
don't
match,
we
want
to
be
able
to
differentiate
and
say,
hey
really.
Our
understanding
of
this
is
that,
and
in
particular
we
we
have
this
problem
with
path.
C
I've
been
digging
the
idf
a
lot
of
the
term
path
and
that
that
really
troubles
me
most
of
the
path
has
been
used
by
many
many
working
groups
with
ietf
and
iota
and
the
term
usually
references,
not
a
a
graph
really,
but
more
like
an
experience
like
here
is
the
path
that
this
packet
has
been
following
and
that
kind
of
yields.
C
C
It's
actually
many
of
them,
because
the
packet
may
be
duplicated
and
a
packet.
We
may
not
keep
its
integrity.
If
we
took
some
network
coding
and
we
flood
a
small
graph
from
a
to
b
with
different
network
credit
fragments,
then
yeah
the
the
packet
will
not
even
experience
one
path,
it's
pieces
of
the
packet
or
by-products
of
the
packet
fragmentation
and
coding
will
follow
different
paths.
C
C
So
so
the
big
graph
that
that
exists
and
may
or
may
not
be
fully
or
partially
is,
is
not
an
experience.
It's
a
potential.
It's
it's!
What
you
may
use
it's
the
subset
of
the
overall
network
that
is
available
to
you
at
the
ingress
to
to
effectively
propagate
that
information
all
the
way
to
the
destination.
So
we
want
to
make
a
difference
between
that
potential
and
an
actual
experience,
and
that's
why
we
have
this
concept
of
track
now.
I
just
saw
this
morning
the
the
the
feedback
from
lou.
C
How
is
that
different
from
from
a
basically
a
tea
path,
a
protection
path
for
traffic
engineering?
We
need
more
discussion
with
lou
and
see
you
know
how
the
terms
overlap
and
if,
if
track
is
completely
within
the
concept
of
of
t-pass
and
protection
path.
And
honestly,
I
don't
know
I've
not
dug
into
that
and
contribution
on
that
term
and
etc.
I
mean
that
would
be
great,
but
for
now
we
have
the
definition
that
I
have
copied
here.
C
It's
basically
defined
as
an
ios3
abstraction,
basically
a
graph,
and
that
goes
from
a
point
a
to
point
b
with
that
net
edges,
that
net
nodes
at
the
edges
and
serial
path
between
the
edges
operating
as
segments
that
join
the
edges.
So
the
vertices
are
serial
path
operating
at,
as
I
said
that
the
dead
next
player
could
be
actually
at
the
four
okay.
I
I
need
to
check
that
term
because
for
me
the
vertices
are
stereo
and
they
could
effectively
operate
at
the
detonate
forming
subliminal.
C
So
that
might
be
a
typo,
but
the
the
when
you
do
any
replication
elimination
at
the
edges,
those
those
will
be
relayed
out.
So
they
will.
They
will
go
all
the
way
to
service.
Okay,.
C
Oh
effectively,
that's
that's
what
I'm
okay,
that
I
want
confused
with
it's
an
edge,
but
yes,
so
so
actually
the
text
is
correct,
so
the
notice
vertices
the
places
where
you
can
effectively
fork.
They
are
directly
a
detected
surface
and
then
the
the
edges,
the
hops.
It
can
be
a
multi-hop
that
net
transit
path.
In
that
case,
it's
really
serial
between
the
edges.
It's
going
to
be
a
serial
set
of
nodes.
So
I'm
sorry,
it's
just
like
english
confusion
between
vertices
and
h.
I
can't
choose
to
do
those
terms.
C
C
You
know
what
the
what
the
network
layer
operates
on,
how
to
get
from
a
to
b
etc
from
what
is
being
transported
within
this,
this
pipe
initially,
for
instance,
in
that
network,
when
we
looked
at
ipv6,
we
did
not
want
to
introduce
too
many
headers
and
stuff.
So
we
basically
said
we
identified
the
flow,
which
is
an
application
layer
construct
with
the
five
or
six
double
depending
on
v4
v6.
C
C
Using
that
basically
means
that
we
do
the
network
operation,
so
we
process
the
water
based
on
the
color
of
the
water
or
whatever,
but
at
the
network
layer
it's
we
can
have
a
lot
more
power
if
we
effectively
use
our
own
network
layer
objects
that
I
call
the
pipes
and
android
pipe
stuff,
and
then
we
put
the
water
on
the
pipe
at
the
ingress
and
it
goes
out
of
the
grass
and
this
way
you
can
put
multiple
floors,
for
instance,
inside
inside
a
single
pipe.
C
Then
you
can
merge
multiple
pipes
to
a
bigger,
pipe
and
separate
those
flows
when
you
reach
this
nation,
etc.
So,
basically
there
is
this
desire
to
separate
the
piping,
which
would
be
the
track
from
from
the
applications
and
the
network
layer
construct
from
from
the
upper
layer
signaling,
which
is
reflected
by
the
factor.
C
So
how
we
do
it
exactly
is
is
not
really
said
and
that's
going
to
be
the
framework,
and
that
could
be
something
which
really
happens
at
that
net.
But
but
it's
a
goal
for
us
to
to
be
able
to
transport
multiple
flows
in
the
same
track
and
signal
the
front
treatment
at
the
network
layer
as
the
track
as
opposed
to
the
flows
themselves
and
keep
the
flow.
The
application
object
separate
from
the
network
object
so
separating
signaling.
We
would
work
on
the
float.
Oh
alright,
I
see
you
have
your
hands
wrapped.
D
Sorry
I
didn't
mean
to
interrupt
too
much
pascal,
but
this
is
where
crossover
into
debt
net
applies
now
so
far.
I
don't
see
that
you've
defined
anything.
That's
particularly
different
from
the
definitions
in
debt
net,
which
does
raise
and
I'm
sort
of
hoping
lou
is
going
to
jump
in
and
correct
me.
Sorry,
I'm
going
to
cough.
D
Sorry,
I
I
I'm
a
little
wary
about
defining
new
terms
that
should
be
very
similar
to
the
terms
that
already
exist
in
internet.
I
understand
we're
going
to
build
into
perio
functions,
etc,
but
how
how
or
why
is
this
different?
It's
maybe
my
lack
of
understanding.
C
That
that
would
be
the
discussion
on
the
mailing
list
on
on
loose
email
right.
C
How
much
try
can
I
see
that
who
is
joining,
but
this
was
just
this
morning,
so
we
could
not
have
a
thread
on
it,
but
basically
we
we
will
have
this
this
track
versus
t
protection
path,
discussion
and
see
if
we
can
convert
track
into
t
protection
or
if,
if,
if
we
want
to
be
more
specific
into
exactly
what
works
about
and
then
we'll
give
the
voice
to.
I
No
sorry,
I
guess
I
need
more
coffee
rick.
I
think
you're
you're
right
on
the
I
agree
with
the
comment.
Is
that
there's
a
lot
here?
That's
similar
and
there's
just
some
new
terminology
that
if
we
can
align
we'll
be
in
good
shape,
so
largely
what
pascal
said.
I
think
another
question
is:
are
we
really
limited
just
to
ipv6
yeah.
I
Rick
brought
it
up,
so
he
asked
for
me
to
comment
so
I
commented
I'll
wait
to
the
end.
Thanks.
C
Yeah,
I
I
I
put
up
your
email
actually
luke
and
I
wish,
at
the
end
of
this
presentation,
to
go
through.
It
have
four
items
and
I
would
like
to
to
make
sure
that
they
are
all
discussed,
but
yes,
and-
and
the
answer
is
certainly
not
I
mean
I
have
personally-
I
have
no
idea
that
it's
it's
it's.
I
understand
it's
a
mistake.
I
I
can
wait.
C
It's
only
because
rick
asked
okay,
okay,
so
so,
let's
move
on
yeah,
so
the
basically
the
architecture
focuses
on
on
one
item
that
joins
to
another
point
of
look.
What
is
raw,
basically
right
now,
this
architecture
focuses
on
just
this
udalu.
C
Is
that
all
that
relative
on
the
variable
could
mean?
Certainly
not
so
if
we
want
to
make
the
term
raw
generic
enough
to
really
mean
reliable
and
available
wireless?
Probably
we
need
to
to
say
that
this
architecture
focuses
on
one
aspect
of
making
a
wireless
relay
board
available
and
that
aspect
this
particular
architecture,
is
really
focusing
on
the
huda
loop
and
then
probably
to
answer
that
other
part
of
of
luke's
review.
C
What
we
are
doing
right
now
is
probably
not
you
know
the
overarching
architecture
of
anything
that
could
be.
You
know
that
could
make
wireless
really
more
available,
but
really
this
this
uda
loop
and
the
psc
that
we
are
building
to
to
complete
the
loop.
C
So
maybe
we
need
to
to
or
something
when
you
say
the
raw
architecture.
We
should
basically
say
this
architecture
or
something
because
it's
not
everything
that
you
could
do
for
a
labor
wireless.
It's
it's
very
specifically
handling
this,
this
loop,
so
the
determiner
I
mean
I've,
put
a
link
here,
it's
it's
40
or
50
years
old.
It
probably
started
in
the
military.
If
I
like
the
history
of
it,
it's
really.
This
loop
of
you
know
observing
a
fact,
and
that's
really
where
the
oem
comes
in.
C
Orienting
is
more
like
applying
intelligence,
and
you
know
the
what
you
learned
from
the
past,
for
instance,
to
to
say.
Oh
based
on
that
observation
there
is,
there
is
the
sort
of
thing
it
should
be
doing
and
and
in
our
case
probably,
if
we
have
a
pc
and
that's
another
question,
if
we
have
a
pc
computing,
the
the
track,
then
the
pc
could
also
come
with
some
recommendations
on
how
to
use
it.
C
That
would
that
would
be
what
orientation
would
mean
for
us.
I
think
some
some
intelligence
of
how
to
to
use
the
subset
of
the
truck
for
a
particular
packet
because
of
the
particular
condition
of
this
time,
and
the
decision
is:
is
our
plc
engine
basically
making
a
decision
based
on
the
observation
and
the
orientation
you
compile.
C
Those
two
you
match
them,
and
you
say
oh
here
is
what
they
should
be
doing
and
and
then
the
the
action
is
the
actual
signaling,
how
you
copy
the
packets
and
multiple
paths
and
how
you
signal
that.
So
that's
that's
pretty
much
the
the
focus
of
this
document,
which
is
called
raw
architecture,
like
you
said,
but
we
need
to
to
figure
out
inside
the
document.
How
would
you
say
the
raw
architecture?
C
What
we
need
to
do
exactly,
and
that's
that
smooth
point
so
more
under
the
loop
I
mean
you've
seen
that
number
of
times
it's
in
the
architecture,
but
basically,
obviously
with
oem
oreos
based
on
you,
know,
pc
metal
information
about
the
graph
decide,
and
that
would
be
the
psc
decision
and
act
and
that's
how
we
use
the
terpario
which
which
extend
the
pre
of
data,
that
net
features.
C
So
robert
says
that
not
we
have
interesting
use
cases
where
actually
some
pieces
of
the
path
are
not
necessarily
deterministic
in
terms
of
fully
bounded
latency.
For
instance,
when
you
look
at
the
access
network
and
we
focus
on
the
first
half,
which
can
be
wireless
5g,
wi-fi
some
things
and
multiple
technologies,
we
don't
have
control
on
the
rest
of
the
way
and
it
might
be
very,
very
different.
C
But
at
some
point
we
need
to
to
make
a
decision
on
depending
on
cards,
by
not
reliability
and
so
far
to
provide
for
the
service
level
objective
associated
to
this
back-end
and
that's
still
a
raw
decision.
C
So
there
is
a
little
bit
of
non-overlap
as
long
as
that
naturally
requires
that
every
every
node
underway
is
deterministic
and
that
requirement
comes
from
it
comes
with
the
body
latency,
so
reliable
and
variable
does
not
necessarily
mean
bonding
latencies
many
times
it
will.
But
it's
reliable
means.
You
have
an
objective
and
you
need
it
if
that
objective,
that
objective
has
bodybuilders.
You
need
to
beat
that
if
that
objective
has
you
know
so
much
of
nine,
so
many
notes
in
the
row
etc.
C
But
you
have
enough
buffer
for
the
latency
that
really
you
don't
need
to
go
into
the
gory
aspects
of
of
that
net
and
tsn.
For
instance,
you
know
the
back
end
of
wireless
access
can
be
considered
relatable
enough
and
low
latency
enough.
C
Then
then
you're
done
okay,
so
you
know
right
basically
splitting
some
functions
of
the
pce,
because
in
our
cases
that
would
be
translated,
pushing
the
reaction
to
the
network
and
basically
you
can
see
the
pc
as
the
brain
and
then
there
will
be
loose
discussion
on
whether
there's
always
a
pc
and
yes,
it's
an
architecture.
We
need
to
to
decide
that.
C
Is
there
always
a
pc
or
not,
probably
not,
but
we
need
to
rely
on
that
on
this
email
and
then
the
psc,
which
really
exports
the
the
data
plane,
short-term
solutions
selection
from
the
pc,
and
there
is
how
the
takes
place.
So
the
architecture
shows
those
confidence
and
places
them
and
shows
their
relationship.
C
C
I
don't
know
if
it's
fair,
because
now
we
say:
oh
it's
still,
if
it's
now,
but
there's,
no,
no
real
family,
but
the
leap
itself
is
a
family
also.
So
it
seems
to
me
that
using
dilip
as
the
term
is
broad
enough,
just
like
using
oam
is
broad
enough,
and
we
I
mean
if
that,
if
I'm
wrong
on
that,
then
please
give
me
a
term,
but
then
compasses
ddp
and
its
family.
But
that's
probably
the
only
case
where
I
effectively
list
in
a
specific
protocol
kind
of.
C
So
the
status
of
the
document,
so
within
the
split
right
after
itf
on
12.
Since
then,
we
have
two
iterations
one
for
fabric
review,
so
many
many
signs
fabrics.
C
So
there
were
a
number
of
points
which
were
transmitted,
reformulation,
clarification
and
then
there
was
they've
got
a
country
review
and
yes,
there's
more
pretty
special
route
of
loose
issues
as
well.
How
do
you
position
things
versus
statement?
C
My
personal
view
is:
is
we
are
kind
of
a
spinning
spin
off
of
that
net
with
an
extension
focused
on
one
specific
aspect
and
with
the
hope
that
at
some
point
the
work
goes
back
into
into
that
next?
But
but
we
can
have
done
this
study
and
I
hope
it
still
fits
as
we
do
it.
We
we
effectively
need
to
to
realize
where
we
have
some
tension,
and
that
includes
a
path
where
you
don't
effectively
have
the
net
nodes
all
the
way
through.
C
That
can
be
attention
the
definition
of
track,
we'll
see
if
that
we
can
fold
that
back
in,
but
even
if
it,
if
it
stays
as
a
terror.
Maybe
that
can
adapt
it.
I
don't
know,
then,
then
the
the
concept
of
truck
is
is
already
present
in
two
other
working
groups.
I
mean
that
six
station
and
raw
by
the
way
to
mean
pretty
much
what
we
mean
here
and
then
yes,
the
scope
and
that's
that's
again,
a
question
so
first
by
dave
and
then
as
well.
C
For
instance,
lou
asks
about
ipv6,
and
maybe
that's
when
we
can
discuss
that
right
now
there
is
a
sentence
somewhere
which
which
points
at
ipv6
extensions.
Do
we
leave
it
to
ipv6
or
do
we
want
to
encompass
more
stuff?
And
I
have
absolutely
no
idea
that
we
we
should
limit
to
ipv6
it's
just
that.
I
have
no
idea
either
and
how
we
could
do
that
outside
of
ipv6.
C
So
so
I'm
not
happy
to
read
the
term
ipv6
from
from
the
sentence
that
lewis
pointed
out
now.
I
would
be
also
happy
to
to
find
some
to
have
some
contribution
explaining
how
we
can
do
something
else.
H
So
pascal
one
question:
where
do
you
see
potential
control
playing
extensions
for,
for
I
mean
for
the
pc,
the
the
pse
doing
all
this
learning
and
taking
decisions?
Do
you
foresee
any
control
plane
extensions
need
to
be
done
in
the
future,
either
indented
or
raw,
or
how
do
you
see
that
that
part
just
to
provide
some
background
on?
Why
I'm
making
that
question
I'm
working
on
some
potential
research
projects
that
are
looking
into
how
to
enable
ai
based
decisions
in
a
raw
network
in
a
multi-technology
raw
network?
C
Okay,
so
I
see
that
trick
and
join
with
you.
I
will
give
you
my
entire
video
request
to
add
stuff.
So
the
way
it's
described
right
now,
the
intelligence,
the
learning,
the
time
series
and
everything
would
reside
in
the
central
controller,
and
then
we
have
to
lose
question.
Is
it
always
a
central
controller,
but
the
way
it's
written
right
now
and
happy
to
modify
that,
but
it
says
there
is
a
central
controller
that
does
learning
based
on
statistical
information
like
long-term
information,
etc.
So
you
can
learn
your
time
series
you
can.
C
So
it's
all
statistics
and
ar
is
really
statistics.
So
that's
why
it's
that
it
fits
now.
This
experience
can
be
translated
in
new
control,
plain
element,
as
you
say,
as
you're
saying,
whereby
the
pce
will
feed
the
psc,
so
the
psc,
what
sees
a
real-time
event
like
this
link
is
flapping
can
make
instantly
a
decision
based
on
all
the
experience
that
was
digested
by
the
pc,
so
the
pc
would
basically
say
in
that
case
you
do
that.
C
That
tells
you,
the
data,
you
know,
transform
the
experience
in
something
which
is
immediately
actually
by
immediately
actuated
by
the
psc.
That's
that's
why
what
we
mean
by
orient,
so
the
whole
goal
in
role
in
the
raw
architecture
is
effectively
doing
this.
Learning
that
you
talk
about
beyond
feeding
that
learning
into
the
d,
which
is
the
decision
by
the
plc.
C
C
And
if
you
distribute
it,
then
you
need
some
signaling
in.
It
would
be
a
data
principle
for
control
whereby
the
intent
of
the
ingress
will
be
propagated
to
the
that
net
relay,
so
they
can
make
appropriate
action
based
on
what
the
ingress
intends
to
do.
D
I
think
I
sort
of
agree
with
carlos
on
this
and
yes,
I
know
I
have
been
promising
you
a
review
on
this
architecture
document
and
I
need
to
to
get
it
done.
It's
the
logical
architecture,
I
think,
is
good
in
terms
of
the
the
explicit
separation
between
the
pce
element
and
the
pse
element
and
lou,
and
I
have
are
having
a
small
discussion
about
whether
an
exact
pce
implementation
is
required
or
not,
and
my
argument
would
be
as
a
logical
separation
of
responsibility.
D
D
Awareness
protocol-
you
know,
dlapp,
is
an
example
of
that
and
understanding
that
there
is
that
southbound
communication
with
the
underlying
layer
two
and
there
is
a
well
there's
northbound
out
of
the
layer
two
into
the
pse,
and
there
may
well
be
some
southbound
communication
from
the
pse
back
into
the
layer
2
to
say
I
have
understood
how
that,
and
this
is
where
the
track
concept
needs
to
be
properly
defined.
I
understand
the
observed
flows,
the
the
tracks
of
the
data.
D
I
understand
the
communication
that
the
policy
that
is
being
set
by
the
pce
and
therefore
I
need
you
layer,
two,
I'm
I'm
operating
as
the
pse
at
the
moment
that
diagram
here
to
make
this
change
in
order
to
achieve
the
policy
that
is
being
determined,
and
I
think
the
content
is
all
there.
I
think
it
just
needs
a
little
bit
of
clarification
in
the
document
and
I
think
we
have
to
use
the
new
svg
content,
because
these
diagrams
are
getting
so
complicated.
D
C
Yeah,
so
so,
basically,
we
we
probably
can
improve
the
pc
to
psc
relationship
with
the
orient
and
the
capture
of
data,
and
maybe
the
oaf
flow
flies
directly
from
the
the
nodes
to
the
pc
or
it's
aggregated
by
the
by
the
increase.
I
don't
know
I
mean
we
need
to
keep
it
yeah.
I.
D
Would
I
I
would,
I
would
recommend-
and
I
don't
want
to
get
too
far
into
this,
because
I
should
just
do
this
as
a
proper
review,
but
I
think
we
can
separate
the
the
logical
concepts
of
a
pse
talks
to
the
layer
below
and
commun.
D
You
know
there's
a
bi-directional
communication
there
separate
that
from-
and
here
is
some
of
the
actual
mechanics
for
doing
that:
eg
d-lep,
oam,
passive,
active
blah,
blah
blah
and
and
sort
of
separating
the
detail
from
the
the
big
concept,
because
the
I
think
in
an
architecture
having
that
big
concept
is
really
good.
Nothing
to
stop
us
drilling
into
more
detail.
But
if
we
separate
that,
then
I
think
it
would
be
more
obvious
to
people
like
carlos
to
say.
I
One
is
the
sort
of
determination
of
which
tracks
are
available,
and
then
the
other
is
the
selection
on
a
per
packet
basis
of
which
track
is
used
or,
and
that
may
be
one
or
more
and
those
are
concepts
that
exist
already
in
sort
of
more
general
traffic
engineering
where,
instead
of
track,
if
we
call
it
a
protection
segment
or
protection
path,
depending
on
the
extent
of
it
that
that
happens
at
one
time
scale
and
then
the
the
selection
of
which
protection
function
is
being
used,
whether
you're
doing
one
for
one
one
for
n
or
one
plus
one
or
one
plus
n.
I
Even
that
is
that's
a
different
time
scale
and
and
happens
at
a
different
place
really
in
the
architecture,
and
I
think,
if
we
start
shifting
over
to
those
sort
of
older
terms,
we
can
leverage
those
concepts
and
that
separation
and
that'll
really
help
clarify
the
distinction
of
what
you're
thinking
of
belongs
in
a
pce.
What
belongs
in
the
track
identification
part
and
what
which
belongs
in
the
track.
Selection.
I
Part
and
again,
you
know
those
those
sort
of
would
be
a
loose
path,
the
the
the
protection
segments
and
then
the
the
actual
protection
switch
function.
So
I
I
think,
there's
some
some
terminology.
We
can
leverage
that'll,
really
help
clean
up
the
the
concepts
here
and
make
it.
So
we
can
delineate
the
different
concepts
and
and
clearly
articulate
the
different
functions
that
are
that
are
possible
and
and
can
be
filled
in
in
the
raw
future.
C
D
So
I
I
think
we've
got
to
a
good
place
actually
where
we
have
an
an
architecture
which
is
it's
a
good
draft,
but
we
can
now
look
as
lou
said,
for
alignment
with
net
or
tease
or
existing
definitions
of
paths
and
tracks,
and
I
totally
agree
with
you
that
there
is
a
difference
between
the
historical
path
that
the
package
traversed
and
the
future
path
you
which
pack
you
wish
packets
to
follow.
D
They
are
two
very
different
concepts
and
we
need
to
make
sure
that
terminology
is
accurate,
but
if
we
can
reuse
something
existing,
then
we're
going
to
be
much
more
on
charter
than
if
we
totally
reinvent
new
concepts.
So
I'm
all
in
favor
of
just
doing
that
kind
of
gap,
analysis
and
making
sure,
particularly
with
people
like
lou,
to
advise
to
say.
Actually
this
is
the
same
concept
to
make
sure
we're
aligned.
C
C
D
Okay,
so
I'm
watching
the
clock
tick
down
and
I
think
I'm
going
to
call
that
your
time.
Pascal,
if
that's
okay,
oh.
C
D
So,
just
just
to
cover
the
framework
we
are,
we
held
an
interim
meeting
just
to
discuss
these
two
documents.
It
was,
it
wasn't
hugely
well
attended.
It
was
attended
by
carlos
pascal,
even
myself.
I
think
we
we
published
some
minutes
of
it.
We
will
continue
to
have
these
meetings
if
particularly
well,
where
there
is
still
discussion
around
the
architecture
document.
D
The
architecture
document
should
be
an
early
document
that
we
push
through
the
working
group,
which
contains
informational
information,
describing
how
raw
will
the
problem
that
raw
will
tackle
and
how
it
will
tackle
it,
whereas
the
framework
is
very
much
a
living
document
which
we
don't
intend
to
publish
until
pretty
much
the
end
of
this
charter
cycle
of
the
working
group.
D
So
we
can
almost
use
it
as
a
peer-reviewed
notepad
of
how
these
how
the
architectural
concepts
are
being
implemented
and
how
we're
tying
all
these
things
together,
without
forcing
us
to
get
it
absolutely
firm.
Until
this
charter
cycle
of
the
working
group
is
is
complete,
which
should
be
reasonably
prompt
because
the
iab
do
not
like
working
groups
running
and
running
and
running
without
a
regular
recharge,
lou
you're
in
the
queue
go
ahead.
D
It
wasn't
it
wasn't
an
interim
on
this
document,
it
was
a
well
no,
it
wasn't.
It
was
an
interim
meeting.
It
was
held
over
ietf
webex,
we
announced
it.
I
tried
to
look,
but
it.
B
No,
it
was
not
announced
as
an
interim
meeting
per
se.
It
was.
It
was
announced
as
the
beginning
of
a
series
of
regular
meetings
to
discuss,
architecture
and
framework,
and
I
think
the
error
was
probably
mine
that
I
didn't
give
the
subject
line
quite
a
crisp
enough
name
to
identify
it
as
such
and
in
the
future.
We'll
do
that.
I
Yeah,
that's
actually,
where
is
going
more
than
the
past
as
the
going
forward
is,
is
an
intro
might
a
formal
intro
might
be
a
really
good
idea,
since
there
are
some
big
questions
here,
and
maybe
you
use
that
to
kick
off
these
other
meetings.
I
I
I
did
miss
that
meeting
unintentionally.
I
Sorry
about
that,
and
but
I
think
an
interim
will
will
force
more
people's
attention
and
maybe
get
some
wider
attendance
and
then
then
maybe
move
on
to
less
formal
meetings
so
rick.
While
you
may
have
spoken
there.
I
think
it's
a
great
idea.
D
Yeah,
I'm
sorry
again,
the
miss
speaking
was
was
trying
to
work
out
the
correct
terminology
between
a
a
formal
virtual
interim
meeting
and
a
get
open
get
together
published
on
the
mailing
list
about
a
document
so
yeah.
I
I
take
your
point
about
a
formal
interim.
I
think
that's
probably
a
really
good
idea
go
on.
Pascal.
C
D
Right,
I
am,
I
am
conscious
that
we
are
now
actually
we've
got
a
little
bit
of
time,
but
if
that's
everything
on
these
two
documents.
C
D
We
don't
actually
have
a
tight
agenda,
so
do
you
want
to
take
five
minutes
on
the
framework
document?
They're
quite
happy.
C
So
yeah,
as
we
said,
we
we
split
between
the
architecture,
which
are
the
building
blocks
of
here's.
What
we
want
to
achieve
and
the
framework
which
is
the
future
post-mortem
and
as
of
now,
it's
the
journal,
the
live
journal
of
what
we
think
we
are
doing
and
how
we
think
we're
doing
it,
and
the
sort
of
thing
that
we
want-
and
we
need
is
explaining-
which
use
case
we're
serving,
and
that's
that's
when,
for
instance,
that
was
one
of
the
questions
by
dave
is
doing.
C
So
how
do
we
signal
the
the
the
tracks
for
now
their
tracks.
C
Are
you
using
a
source
rod
by
the
ingress
which
will
basically
tag
the
packets
for
that
behavior,
or
would
we
support
a
distributed
plc
and
I
guess
the
same
will
apply
to
the
pc
it
wants
to
the
pcb.
To
answer
those
questions
I
mean:
how
do
we
implement
the
pce?
Is
it
really
a
centralized
box?
Is
it
a
distributed
function
in
the
network?
C
How
do
we
signal
the
orientation?
That's
the
question
by
carlos.
So
how
does
the
orient
piece
operate
so
all
the
protocols
and
and
the
protocol
elements
which,
which
will
be
added
to
support,
opens,
we
need
to
basically
point
at
them
very
as
we
elaborate
and
if
we
change
our
minds
as
we
work
on,
then
we
need
to
update
this
document
as
well.
C
So
it's
really
the
expectation
is
it's
the
live
pointer
on
the
things
we
use
and
we
think
we're
going
to
use
and
when
we're
done-
and
we
think
we
have
a
workable
solution,
then
we
basically
close
the
shop
and
this
document
publishes
us
here
is
how
it
works
next
slide.
Please,
oh
it's
me
please!
Yes,
so
that's
why
it's
again!
It's
it's!
It's
the
dave!
C
So
I
obeyed
myself
as
you
can
see
that
that's
the
assignment.
This
is
the
just
one
use
case.
We
have
many
multi
multiple
use
cases
we
have
mesh
we
have,
but,
but
here
yes,
this
is
especially
there
to
illustrate
the
fact
that
we
cover
the
wireless
access,
where
only
the
only
monitored
network
is
the
first
half
the
radio
access
network.
It
can
be
wi-fi
5g
whatever
and
the
internet
is,
is
best
effort,
hopefully
good
enough.
If
it's
your
your
copyright
or
factory
network.
C
C
Part
of
what
we
will
have
to
to
document
is
how
effectively
we
signal
the
flows
and
that's
basically,
the
architecture.
So
we
don't
have
to
do
anything
about
that,
so
the
flows.
We
know
that
that
framework
is
very
clear,
but
how
we
signal
the
path
on
which
we
place
that
flow,
how
we
extract,
how
we
split
that
the
track
into
the
actual
experience
of
the
packet
or
the
package
fragments,
which
is
what
we
call
the
subtract,
so
it's
tracks
within
tracks
that
go
end-to-end
between
a
ingress
and
egress.
C
So
that
is
the
road
map
that
we
decided
long
long
ago.
So
we
have
to
select
appropriate
radios
and
and
effective
use
cases
and
with
the
progress
we've
done,
the
index
document
and
the
others
are
coming,
and
the
use
case
that
carlos
just
presented,
which
is
already
pushed
for
ietf
score,
we're
in
very
good
shape.
So
I
can,
I
can
say
we
we
checked.
C
This
thing
now
next
is
is
to
to
basically
decide
how
we
signal
the
the
the
tracks
and
how
we
do
the
adaptation,
and
then
we
have
to
talk
about
the
iom
there
now,
depending
on
what
the
group
wants
to
work
on,
we
probably
want
to
have,
and
that
was
called
canon's
question
again.
We
probably
want
to
have
a
new
item
here,
which
is
about
the
orient.
For
me,
the
orient
was
autoscope
mostly
I
mean
it's.
C
The
pc
to
pse
control
play
skeleton
and
how
really
that
piece
of
the
loop
happens
is
not
part
of
the
framework.
Well,
it
has
not
been
documented,
it
doesn't
have
its
peace
in
the
framework.
But
if
the
group
wants
to
to
include
that
in
the
discussion,
then
yes,
we
need
to
have
a
framework
section
on
on
the
orient
piece
so
basically
which
data,
how
it
fixed
to
the
controller
and
how
the
controller
fits
its
its
orientation
back
into
the
psc.
C
So
it's
not
sufficiently
expressed
in
the
framework
as
it
stands
and
then
again,
since
we
we
are,
we
expect
to
use
a
lot
of
work
which,
which
is
being
done
elsewhere.
We
had
this
list
forever.
I
see
that
peace
is
not
probably
enough
mentioned,
though
it
was
at
the
their
very
initial
meetings.
So
probably
we
need
to
add
these
in
that
list.
C
I
didn't
speak
about
authorship,
but
pretty
much.
It
was
the
first
slide
with
for
now
it's
it's
slow
and
I
and
then
it
was
just
me
when
I
did
the
split
I
was
expected
to
work
on
the
architecture,
so
the
authorship
of
this
and
of
the
architecture
are
subject
to
change.
Obviously,.
C
I
C
I
C
D
Thanks
pascal,
I
don't
think
we
have
any
questions.
I
have
one
point.
I
didn't
bother
to
jump
to
the
queue
because
we
kind
of
jumped
to
the
end.
I
think
talking
about
the
pse.
Oh
my
god,
my
dog
is
molting
everywhere,
the
the
psep
ce
communication
control
plane
to
me.
That
smacks
of
netconf.
D
C
Happy
could
be
that
now
at
some
point
we
need
to
point
on
the
solution
so
either
we
say
it
does
not
exist
yet
to
do
it,
proprietary,
which
is
pretty
much
what
we
have
right
now.
You
do
your
own
proprietary
young
models
and
what
or
representing
the
communication
in
both
directions,
or
we
kind
of
decide
that
we
want
to
provide
some
hints,
and
then
I
mean
that's
just
not
done
right
now.
D
I
I
see
that,
as
stretching
the
scope
of
the
working
group
to
worry
about
that
communication,
I
think
we
can
describe
in
the
architecture
the
nature
of
that
information.
So
that's
the
the
policy
that
is
arriving
and
we
can
talk
in
terms
of
of
track,
etc,
but
how
that
information
is
carried.
I
don't
think
it's
in
scope
for
the
working
group
at
the
moment
to
start
developing
proprietary
protein.
Well,
not
customized
protocols
to
carry
that
information.
D
Yes,
if
somebody
is
excited
in
writing
a
yang
model
that
sketches
out
how
that
information
is
carried,
then
that
obviously
says
you
know
you
can
use
netconf
to
discuss
that
that
young
model
it
that
could
be
if
we
feel
that
we
have
to
define
that.
That
would
be
an
obvious
next
step,
but
I
don't
think
we
should
burn
too
many
cycles
on
that
at
the
moment.
D
Okay,
so
moving
on
next,
we
have
fabrice
talking
about
om
support.
I
have,
I
will
click
the
magic
grant,
preloaded
slides,
oh
sure,
to
be
able
to
have
that,
and
I
will
give
you
permission
to
control
your
slides,
no
I've
given
that
to
eve
I've
given
that
to
the
wrong
person,
because
your
name
moved
around
there
we
go
february,
so
you
should
be
able
to
steer
those
using
the.
J
Yeah
largely
sufficient,
I
will
just
present
the
update
so
here
just
to
have
a
remainder
about
the
chronology
of
draft.
Initially
we
had
everything
together
in
the
oim
draft
and
it
was
split
in
something
which
is
related
to
date
net
in
general,
so
all
the
generic
aspects
of
weim
has
been
moved
and
we
focus
in
this
novel
argument
only
on
the
om
specs,
which
are
very
specific
to
all.
J
So
thanks
to
chevy
for
his
proofreading
last
year,
we
have
made
a
few
modifications.
I
will
present
now.
So
first
of
all,
we
introduced
another
section
about
the
recommendation
we
are
listing
in
this
section.
So
typically
we
are
listing
the
num,
the
specific
metrics
that
needs
to
be
supported
by
the
om
nodes.
So
typically
we
focus
up
to
no
on
the
packet.
There
was
show
adventuring
latency
and
the
maximum
consecutive
failures
that
must
be
exposed
by
all
the
nodes.
J
Sorry-
and
we
need
to
also
have
some
methods
to
aggregate
the
statistics
to
compress
everything
in
the
later,
and
we
must
also
which
will
support
word
tracing
with
hybrid
way
in
this
novel
draft.
J
We
we
are
specifically
the
the
piggybacking
problem,
specifically
so
piggybacking.
That's
inserting
some
additional
information
in
existing
packets,
so
we
we
typically
had
some
industrial
control
readers
in
wireless.
It
may
be
also
interesting
to
put
the
packets
back
to
back
in
the
same
test
slot,
because
in
wireless
networks,
and
particularly
for
schedule
networks,
we
have
a
cost
for
a
medium
access
and
the
time
slot
is
fixed.
So
we
will
waste
the
bond
wave.
J
So
the
interest
of
this
kind
of
schedule
networks
is
to
put
the
impacts
of
the
om
information
in
the
space
of
the
temple
time
slot,
which
is
not
used.
So
that's
the
image
of
having
control
information
for
free,
so
for
free,
which
means
only
that
we
have
some
bandwidth
which
is
wasted.
However,
we
we
are
keeping
on
having
some
large
energy
consumption,
because
the
transmitter
and
the
receiver
are
obviously
awake
for
a
longer
time.
J
So
yeah
we
just
reduced
the
cost
of
any
medium
access
with
this
piggybacking
technique
and
just
to
be
clear
about
that,
we
clearly
classify
the
different
way
so
active
passive
and
hybrid
active.
We
are
sending
some
probes
with
test
packets
with
passive.
We
just
use
database
information
and
with
hybrid
om,
we
have
a
mix.
So
typically
we
may
use
some
counter
values
or
you
may
piggyback
some
information,
and
we
would
just
like
to
insist
on
the
fact
that
piggybacking
and
ym
techniques
are
probably
orthogonal
in
the
sense
fans.
That's
a
negative
or
impacted.
J
That's
a
probe,
maybe
trustee
transmitted
heroin,
so
we
should
have
in
that
case
we
must
have,
in
that
case
dedicated
resources
or
we
may
encueve
the
prop
so
that
it
can
be
piggybacked
with
another
data
point
when
we
have
enough
space
in
at
a
given
time
slots.
So
so
we
are,
we
are
kind
of
stealing
the
the
resources
that
are
used
for
the
data,
the
data
flows.
So
basically
that's
just
to
be
clear
about
this
classification
between
oem
and
piggybacking.
J
B
Thank
you
very
much
for
the
update
and
also
for
the
ongoing
work
on
the
draft.
It's
great
to
hear
the
specifics.
B
Okay,
good,
thank
you
to
be
continued
on
the
mailing
list.
Okay,
I
think
we
are
going
to
move
now
to
the
last
presentation,
which
is
the
multi-domain
extensions
presentation
carlos
back
to
you.
Would
you
like
me
to
grab
the
slides
or
do
you
want
to
bring
them
up.
B
H
Thanks,
so
this
is
a
a
new
draft
that
is
on
multi-domain
extensions,
and
the
purpose
of
this
document
is
at
this
stage
is
mainly
to
present
a
problem
that
is
not
currently
under
the
scope
of
the
working
group.
As
far
as
we
understand,
but
to
see
whether
this
potential
problem
may
be
of
interest
and
then
to
identify
gaps
and
things
that
we
may
need
to
consider
for
this
problem
to
be
to
be
addressed.
H
So,
as
I
mentioned,
the
current
scope
of
the
working
group
is,
although
I
don't
think
explicitly
mentioned,
but
my
underlying
assumption
is
focus
on
on
single
domain
single
administrative
domain,
although
that
may
translate
also
to
technological
domains.
If
we
make
a
like
a
one-to-one
mapping
technology
to
administrative
domain,
or
even
if
we
don't,
there
may
be
a
scenario
where
multiple
technological
domains
may
involve
this
kind
of
multi-domain
gaps.
H
For
example,
we
may
have
hosts
connected
to
different
broad
domains
that
they
need
to
communicate
to
each
other
one
host
to
another
host
traversing
two
different
domains
and
one
example
is
maybe
large
factories
where
may
have
the
different
networks,
organizing
domains
because
of
scalability
and
this
kind
of
things-
and
there
may
be
particular
situations
in
which
we
still
need
to
connect
one
node
in
one
domain
to
another
node
in
another
domain,
and
we
want
that
connection
to
be
provided
with
some
reliability
availability
warranties.
H
H
So
this
is
one
example
using
the
ascii
art
that
is
in
the
draft.
That
is
not
very
simple
to
to
show,
but
we
have
two
domains,
one
at
the
top
and
one
at
the
bottom.
We
assume
that
each
domain
has
an
associated
pce
for
the
path
computation
and
then
we
have
different
row
notes.
We
are
assuming
the
distributed
pse
model
where
each
node
may
be
potentially
a
plc,
an
english
node.
Then
we
have
another
domain
at
the
bottom,
with
another
pce
and
different
nodes,
and
we
have
these
two
domains
interconnected.
H
H
So
we
have
some
discussion
in
the
document
again.
This
is
just
to
foster
the
discussion
in
the
working
group
and
to
see
whether
this
there
is
an
interest,
but
the
the
first
idea
that
we
thought
it
could
be
a
way
of
enabling
this
is
that
we
have
the
english
node
in
the
first
domain,
where
we
get
the
request,
we
want
to
have
a
communication
between
host
one
and
host
two
and
the
ingress.
The
pse,
in
that
domain
will
request
to
the
pc
in
that
domain.
H
The
different
pscs
involved
in
the
other
domain
in
the
second
domain
and
some
kind
of
a
split
of
sla.
That
needs
to
be
one
and
t
on
each
of
the
domains,
because
then
we
foresee,
but
this
again
one
initial
discussion-
that
its
domain
will
keep
track
of
monitoring
and
ensuring
that
the
slash
on
each
of
the
different
tracks,
a
domain
sorry
will
be
maintained
somehow
with
lim
mechanisms
that
may
need
to
be
cooperating
somehow
so
in
step
number
five.
H
The
english
pc
pse
in
the
first
domain
will
communicate
with
the
psc's
in
the
english
pss
in
the
other
domain,
to
basically
communicate
the
tracks
that
are
involved
and
to
enable
those
psis
to
have
some
to
start
doing
these
domain
specific
oein
mechanisms
at
each
of
the
domains,
and
at
this
point
each
of
the
involved
pscs
will
be
able
to
compute
the
the
paths
or
the
at
the
the
pse
runtime
and
the
oem
mechanisms
will
be
in
place.
H
H
D
Hi,
carlos
it's
rick
I'll
turn,
my
video
on.
I
thank
you
very
much
for
this
work.
This
is
this
is,
I
think,
is
it
really
important?
So
I
I
really
have
have
a
question
and
a
statement,
so
lou
has
put
a
a
link
in
the
chat
to
a
generic
multi-domain
problem
statement
which
is
coming
from
the
tease
working
group.
Yes,
it
is
so
I
I
recommend
people
to
have
a
look
at
that
for
reference.
D
The
other
question
is
the
architecture
as
presented
by
pascal,
just
earlier,
as
as
it
is
written,
has
a
single
pce
communicating
with
one
or
more
pses.
B
May
I
comment
just
briefly
I:
whenever
we
have
talked
about
raw
and
whenever
we
have
made
reference
to
the
debt
net
agenda
and
charter,
there
is
the
specific
wording
in
the
charter
about
coordinated
domains.
B
And
although
it
hasn't
been
a
topic
of
discussion,
it
is
described
that
way
in
the
debt
net
charter.
So
and
maybe
that's
a
good
segue
over
to
lou.
I
I
was
just
going
to
say
that
the
architecture
I
think
already
allows
for
it
where,
in
particular,
the
text
that
talks
about
going
over
non-raw,
aware,
which
I
would
translate
to
non-debt
net
aware
domains.
It
basically
turns
you
into
a
multi-domain
problem.
B
So
I
think
we're
all
in
agreement
that
it
is,
although
it.
I
B
I
B
Yes,
yes,
if
not
focused
on
it,
it
the
problem
description
already
references
it
both
directions.
D
So
I
expressed
my
question
with
chair:
hat
on
is,
is
carlos?
Are
you?
Are
you
requesting
working
group
adoption
for
this,
or
do
you
want
to
get
some
review
comments
and
burn
a
few
cycles
on
it?
First
and
then,
what's
your
feeling.
H
At
this
point,
I
wanted
to
have
some
feedback,
not
really
thinking
of
adoption
or
anything
that
that
may
come
later
if
there
is
interest,
so
that
was
my
own.
My
own
purpose
was
to
foster
discussion
on
this
point
and
of
course,
if
there
is
interest
yes
at
this
point
in
time,
and
we
of
course
are
open
to
get
more
people
joining
the
draft,
the
more
the
better
I
mean
the
more
people
interested
the
better.
So
yeah,
no,
no,
no
question
at
this
point.
D
Okay,
thank
you
eve.
You
still
have
your
oh!
No!
You
don't
you're
just
in
the
in
the
chair
section.
So
are
there
any
more
questions
on
this
topic.
D
No
okay,
so
we
actually
have
half
an
hour
of
the
session
left.
D
So
really
this
is
this
is
an
open
mic
opportunity
if
anyone
wishes
to
raise
anything
that
they
think
might
be
of
interest
to
the
group
in
general
stand
up
and
tell
us
that
we
are
going
in
completely
the
wrong
direction
and
we
ought
to
be
looking
at
whatever
some
other
working
group
is
currently
working
on
in
classic
ietf
style
or,
if
there's
something
we
have
missed
in
what
we've
presented
or
documented
so
far
or
stand
up
and
promote
something
exciting
that's
happening
in
another
working
group
that
we
ought
to
be
aware
of.
D
Well,
people
consider
that
one
thing
I
will
add,
so
I
think
this
came
out
in
one
of
the
earlier
presentations,
I
think
from
pascal
talking
about
radio
specific
properties
to
be
discussed
as
part
of
the
link
awareness
or
the
oam
feedback
between
the
link
layer
and
the
pse
component.
D
I
know
there
are
at
least
one
extension
to
delap
being
proposed
in
the
man,
a
working
group
which
I
believe
is
meeting
in
the
next
session
this
morning
to
do
with
specific
things,
such
as
channel
assignment
frequency
bandwidth,
some
really
very
radio
link
layer,
specific
properties
that
could
be
announced
via
a
dlap
protocol
session.
If
anyone
is
interested
in
further
direction
that
the
d-lab
is
going
in,
that's
in
many
otherwise
anyone
else.
D
If
there
is
nothing
else,
may
I
suggest
that
those
of
you
who
have
booked
out
the
two
hours
today
for
raw
take
this
opportunity
to
go
away
and
do
the
some
of
these
reviews
that
you
have
promised?
I
know
I
shall
be
because
the
ietf
revolves
around
good
quality
review,
and
I
know
the
authors
of
the
various
drafts
in
this
working
group
deserve
good
quality
review
because
they
they
have
put
a
lot
of
effort
into
these
documents.
B
And
I
also
want
to
thank
both
karina
and
carlos
for
their
very
much
appreciated
help.
That's
great
and.
I
D
I
am
very
jealous
of
those
of
you
sat
in
the
room.
I
wish
I
had
been
able
to
meet
you
in
person
this
time
around
as
a
rough
intention
from
the
chairs.
We
intend
to
be
in
person
in
at
the
atf-114,
which
would
be
very
nice
to
meet
you
all
again
and
speak
to
you
again
after
two
and
a
half
years
of
of
isolation,
but
we've.
D
No,
even
I
have
never
met
in
person
we
have.
We
have
chaired
this
working
group
for
two
and
a
half
years
without
meeting
in
person,
so
that's
an
all
credit
to
to
the
internet,
but
it
would
actually
be
quite
nice
to
meet
on
that
note.
If
there
is
nothing
else,
I
think
we
should
probably
close
this
meeting
early.
D
There
we
go
and
we
are
giving
everybody
half
an
hour
to
go
away
and
quietly
read
some
raw
documents
and
add
comment
to
the
mailing
list:
no
objection
from
our
a.d,
which
is
always
good,
so
in
which
case.
Thank
you
all
very
much
extra.
Thank
you
from
me
as
well
to
carina
and
carlos
for
for
being
our
chair
delegates
in
the
room.
Luckily,
we
didn't
have
a
mad
rush
to
the
mic
and
everyone
behaved
and
meet.
Echo.
Did
us
proud?
So
thank
you
very
much.
D
I'm
going
to
call
this
a
stop
and
speak
to
you
all
on
the
list
and
in
person,
and
we
will
probably
if
we
arrange
a
virtual
interim,
we
will
publicize
it
in
advance
and
properly
on
the
mailing
list.
So
please
keep
an
eye
open
for
that
for
a
bit
more
of
a
deep
dive
into
architecture
and
possibly
a
little
bit
of
multi-domain.
B
Even
if
we
don't
schedule
an
interim,
we
may
we'll
do
a
better
job.
This
next
time
of
creating
a
subject
line
that
announces
a
regular,
regularly
held
series
of
meetings
to
discuss
those
documents.
D
Yeah
indeed,
okay,
thanks
all,
in
which
case
I
think
we
should
probably
close
the
meeting.
J
D
D
Yeah,
thank
you
very
much,
everybody
and
authors.
We
may
just
have
to
leave
this
room
open
with
nobody
in
it
me
techo.
We
have
no
idea
how
to
close
the
how
to
close
the
meeting.
D
Okay,
perfect,
thank
you,
corinna,
in
which
case
I'm
going
to
leave
you
to
it
and
make
myself
a
cup
of
coffee.
Thank
you
very
much.
Everybody.