►
From YouTube: IETF111-RAW-20210727-1900
Description
RAW meeting session at IETF111
2021/07/27 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Excellent,
I
was
just
looking
a
little
bit
surprised
because
I
was
very
close
to
my
very
close
to
my
camera
and
I
filled
the
screen
with
my
face,
which
is
always
a
bit
off-putting.
So
yeah,
I'm
looking
at
the
clock
and
I
think
it's
probably
time
to
start
so
yeah,
hello
I'll
start.
A
Let
me
just
find
some
slides
with
the
normal
administrative
stuff
and
we'll
make
a
start,
which
I
think,
if
I
get
this
right
so
hopefully
is
that
the
only
problem
with
meat
echo
is
when
you're
presenting
the
slides.
You
can't
see
what
everyone's
doing
in
meat
echo
so
meanwhile
I'll
start
with
the
slides
and
then
I'll
hand
over
to
eve
in
a
second,
so
hello,
everyone
session
one
day,
two
tuesday
ietf
one
one
one
online
again
so
be
it
welcome
to
to
raw.
A
I
hope
you
expect
to
be
here,
so
this
is
a
ietf
meeting,
despite
the
fact
that
being
entirely
remote,
so
it
is
therefore
covered
by
the
note.
Well,
if
this
is
your
first
ietf
meeting
or
you
have
never
read
the
note
well,
I
thoroughly
recommend
you
do
so,
as
this
is
an
ietf
meeting,
you
are
agreeing
that
your
representation
can
be
recorded
and
all
your
participation
is
in
the
public.
So
if
you
have
ipr
considerations,
you
need
to
be
very
aware
of
it.
A
A
So
if
you
are
complete,
if
you
are
unfamiliar
with
the
note
well-
or
this
is
news
to
you-
go
and
read
it
before
you
step
to
the
mic
and
make
a
mistake,
this
also
covers
codes
of
conduct.
Behavior,
that
sort
of
thing
the
chairs
should
be
completely
okay
with
it.
So
if
you
have
an
issue
of
course,
there's
an
ombuds
team,
but
also
you
can
approach
the
chairs
and
we
can
try
and
help
where
we
can
or
forward
it
onto
the
ombuds
team
itself.
A
So
enough
of
that,
but
it's
a
serious
topic
to
be
considered,
and
this
is
a
summary
of
the
the
various
detail
of
the
notewell
on
the
second
slide.
So
the
font
is
big
and
you
can
read
it.
It
should
be
noted
that
all
these
slides
are
available
on
the
raw
data
tracker
in
the
meeting
materials.
A
A
So
this
is
the
administrative
at
the
beginning
of
the
session
we'll
get
to
the
agenda
in
a
minute,
so
obviously
we're
in
meet
echo.
I
understand
there
are
also
people
who
may
be
on
the
audio
stream
or
on
jabber
as
well,
but
the
main
audio
visual
content
is
being
done
through
meet
echo.
A
A
I
recommend
everyone
to
double
check
those
minutes,
particularly
after
they've,
made
a
statement
at
the
mic
or
presented
just
to
check.
Whoever
was
taking
some
notes
at
that
point.
Got
their
names
spelt
correctly,
because
we
all
know
how
we
spell
our
own
names.
A
So
we
say
it
quickly
and
move
on,
but
the
poor
person
trying
to
capture
it
in
text
often
just
has
a
guess
and
it's
kind
of
useful-
to
go
back
and
check
your
names
right,
as
I
mentioned
before,
there's
also
a
jabber
for:
what's
it
a
jabber
room
is
what
they
call
it.
So
that's
an
xmpp
url.
A
So
if
you
don't
have
access
to
meet
echo
for
some
reason,
you
can
use
jabber
the
main
work
of
all
the
ietf
working
groups,
and
that
includes
raw,
is
performed
on
the
mailing
list,
because
that
gives
us
a
permanent
record
of
the
discussions
and
god
forbid
arguments
that
occur
as
we
try
and
do
our
work
so
long
questions
something
for
people
to
really
mull
over
and
cogitate
and
respond
in
slow
time.
The
mailing
list
is
the
perfect
place
to
do
it.
A
If
you
are
not
subscribed
to
the
mailing
list
and
you
are
interested
in
in
engaging
with
raw,
please
subscribe,
it's
the
way
you
get
access
to
the
conversation,
that's
ongoing
and
that's
raw
at
ietf.org
links
on
the
page
here,
but
it
it's
fairly
easy
to
to
guess.
Equally,
if
you
have
a
message
for
the
chairs,
you
can
do
raw
hyphen
chairs
at
itf.org,
and
that
will
go
to
even
myself
and
also
to
the
ad,
and
so,
if
you've
got
admin,
issues
or
or
other
troubles,
let
us
know
we're
here
to
help.
A
That's
our
that's
our
role
in
this
whole
thing
and,
as
I
mentioned
earlier,
the
slide,
packs
and
various
bits
and
pieces
are
available
on
the
data
tracker
for
this
session
and
the
urls
at
the
bottom
of
the
screen
now
eve.
If
there's
anyone
in
the
queue,
I
obviously
can't
see
them,
because
I'm
now
looking
at
the
slides,
not
the
screen,
so
shout
and
no
one
in.
B
And
in
fact,
I
just
wanted
to
note
that,
with
this
version
of
need
echo,
you
can
see
all
of
the
materials
by
going
to
the
file
icon
at
the
very
top
of
the
screen,
and
it
will
take
you
over
to
the
data
tracker.
So
you
can
click
on
things
as
we
go
along
as
well.
A
A
Okay,
so
our
agenda
is
fairly
light,
although
it
is
filling
up,
but
that's
good,
because
that
gives
us
plenty
of
opportunity
to
actually
discuss
things
rather
than
you
know
telling
people
that,
rather
than
the
time
schedule,
slipping
and
and
the
people
at
the
end
of
the
the
meeting
having
their
time
cut
short,
we
we
do
actually
have
time
to
to
discuss
things
and
ask
questions.
A
So
this
is
the
intro
I'm
covering
the
administrative
yeah
up
is
about
some
of
the
related
work
and
then
we'll
cover
some
of
the
document
status
and
some
of
the
work,
even
I've
done
with
milestones
and
then
we'll
go
straight
into
presentations
from
various
people,
about
mostly
the
status
of
documents
at
the
moment,
and
then
eve
has
a
a
little
presentation,
she's
put
together
where
she
and
I
and
the
debt
net
co-chairs,
get
together
every
so
often-
and
this
was
one
of
the
topics
of
discussion
between
the
four
of
us
that
we
thought
was
probably
worth
opening
up
to
the
group
to
see
what
the
working
group
thought
and
it
really
it's
it's
an
opinion
gathering
thing
but
I'll.
A
B
Okay
and
let
me
know,
how's
the
mic
volume
great.
B
Okay,
well,
this
is
a
fairly
simple
slide
because
we
just
wanted
to
let
people
know
that,
because
of
the
nature
of
this
work,
because
we're
working
in
the
wireless
domain,
naturally
there's
this
natural
relationship
with
layer,
two
and
with
obviously
ieee
802
kinds
of
developments,
and
there
is
actually
within
the
ietf,
a
coordination
effort,
that's
run
by
the
iab
and
its
counterpart
in
the
I
triple
802
arena,
and
you
can
read
more
about
that
coordination,
which
are,
I
believe,
quarterly
meetings
that
happen.
B
B
Nothing
momentous
has
happened
as
yet,
except
that
their
the
activities
that
are
going
on
here
are
being
tracked,
and
so
it's
the
perfect
kind
of
forum
to
raise
issues
and
concerns
about
the
interactions
between
technologies
that
the
ietf
is
responsible
for
and
technologies
that
the
ieee
are
responsible
for.
In
terms
of
you
know,
these
are
the
these.
Are
the
specification
writing
organizations
across
those
layers
across
that
interface?
B
So
this
is
simply
to
say,
we
are
now
participating
in
those
as
our
the
debt
net
co-chairs
as
well,
and
another
activity
that
launched
back
in
april.
B
For
those
of
you
who
may
not
know
about
the
avenue
alliance,
it
is
an
organization
that
is
responsible
for
certifying
tsn,
c
tsn,
implementations
and,
interestingly,
during
their
plenary,
there
was
a
discussion
that
was
held
about
whether
it
might
make
good
sense
to
launch
a
debt
net
study
group
and
the
with
the
intent
of
understanding
how
all
these
pieces
fit
together
at
the
various
layers.
B
B
So
this
is
merely
to
say
that
this
activity
was
certified
by
the
avenue
alliance
board
and
we,
it
will
probably
launch
sometime
in
the
next
few
months.
B
B
We
have
quite
a
few
documents
that
are
wending
their
way
through
the
system.
We're
really
excited
to
share
that
the
ldax
document
we
recommended
it
for
iesg
review.
It's
been
about
40
days.
Unfortunately,
it's
been
in
the
queue
for
discussion,
so
we
would
definitely
invite
john
to
maybe
comment
on
the
status
of
it
if
he
has
an
update
to
that.
C
My
my
update
is
that
my
cue,
for
various
reasons,
has
gotten
woefully
behind
I'm
acutely
aware
of
it
and
promised
to
do
better
in
the
near
future.
So
yeah
I
was
just.
I
was
just
reviewing
my
queue
and
seeing
that
that
particular
document
is
waiting
for
me.
So.
B
C
Sorry
could
you
what
was
that
directed
to
me?
I
I
clicked
to
mute
myself
and
and
there's
this
unfortunate
meet
echo
pathologies
here
when
you
mute
yourself,
you
lose
audio
for
a
couple
seconds.
B
Oh,
we
were
just
asking
you
about
next
step
is
the
next
step
that
you
review
it,
and
then
it
goes
to
a
potentially
for
discussion
at
a
meeting.
What
what
happens
next.
C
Yeah,
that's
right,
so
so
I
I
will
review
it.
You
haven't
already
gotten
the
writing
area
review
for
it.
Have
you
by
any
chance.
C
Okay,
so
so
I
will,
I
will
also
kick
it
off
for
a
writing
area
and
then
subsequently,
we'll
we'll
put
it
on
the
agenda
for
an
iesg
meeting
and
then
you'll
get
to
enjoy
all
the
other
iesg
numbers
reviews.
B
Actually,
they
are
terrific.
Thank
you
for
that
update
john
you're.
Welcome,
let's
see
so
we
have
a
couple
of
new
working
group
documents,
the
use
cases
and
technologies
documents.
No,
actually
those
have
been
working
group
documents,
our
new
ones,
newly
adopted
are
the
oam
documents
and
the
architecture
documents,
and
we
are
also
heavily
considering
the
the
I
guess.
B
It's
industrial
requirements
document
as
well
for
adoption,
and
so
that
is
something
that
we
should
when
we
get
to
the
discussion
in
the
agenda
about
the
the
generic,
not
generic,
but
the
general
use
cases
document
that
one
of
the
updates
to
it
was
reference
to
the
more
detailed
industrial
requirements
doc,
and
so
why
don't
we
defer
that
discussion
there
until
that
point
about
putting
that
document
up
for
grouping
working
group
adoption
and
it
is,
it
was
our
intent,
and
I
think
we
we
mentioned
it
on
the
mailing
list-
that
we
expect
to
make
some
sort
of
formal
appeal
to
the
working
group
shortly
after
this
meeting.
A
Yeah,
so
the
the
authors
expressed
interest
in
working
group
adoption
the
question.
There
was
some
question
about
overlap
with
the
use
cases.
In
general,
there
was
some
discussion
at
the
last
ietf
about
a
problem
statement
document
or
whether
we
were
just
making
work
for
ourselves
so
yeah.
I
agree.
I
think
that
might
be
worth
a
little
bit
of
discussion
time
at
the
end.
B
Okay,
next
page,
oh
and
of
course,
there's
also
percolating
through
the
system
are
several
documents
regarding
mech
as
well.
A
Milestones
so
yeah,
so
so
even
I
thought
we
would
be
good
chairs
and
try
and
keep
the
the
the
milestones
on
the
data
tracker
in
line
with
what
we're
actually
doing,
because,
of
course,
milestones
are
dutifully
put
in
when
a
working
group
forms
because
they're
an
important
thing
to
go
with
the
charter
and
to
try
and
scope
our
progress.
But,
of
course,
often
beyond
the
starting
of
the
working
group
and
over
this
next
subsequent
years
they
just
kind
of
get
left
and
no
longer
bear
any
resemblance
to
reality.
A
So
we
thought
we
thought
we'd
be
good,
and
so
we
have
updated
the
existing
milestones
to
actually
reflect
the
work,
we're
doing
so
we're
a
little
bit
behind,
but
we
have
added
some
extra
documents
and
I
don't
think
I
don't
think
anyone
needs
to
slap
on
the
wrist
about
this.
We
we
are
making
progress
and
we
are
producing
documents.
So
this
sort
of
captures,
which
milestone
is
very
successful
with
the
dates,
have
been
aligned
with
what
actually
happened.
Well,
so
the
green
ones
are
accurate
dates.
The
red
ones
are
still
aspirational.
A
D
A
What
we
didn't
want
to
do
is
preempt
the
primary
authors
on
some
of
these
working
group
documents
by
saying:
oh,
we
we
as
chairs
think
it's
ready,
so
we're
just
updating
milestones
to
say
we
must
submit
it
now
so
great
to
have
feedback
from
from
the
author
teams
of
these
documents
and
and
we'll
let
them
drive
the
let
them
and
the
working
group
drive
the
actual
delivery
date.
So
to
speak.
So
great,
that's
really
good
news.
B
To
clarify
the
visuals,
the
the
things
in
green
are
things
that
were
not
actually
in
the
the
milestones
as
they
existed
in
the
past.
The
red,
of
course,
is
a
little
bit
of
slippage,
and
the
check
marks
mean
that
these
are
things
that
have
been
done
and
you
can
see
the
replacement
of
various
words,
wordings
and
so
forth,
but
that's
how
you
should
read
this
visually.
A
B
B
B
Acknowledge
that
john
did
recently
become
our
new
ad,
and
this
was
sort
of
a
hats
off
to
him
to
help
him
understand
what
we're
doing.
A
So
yeah
look
at
that
a
little
bit
over
time,
but
I
think
we
should
probably
crack
straight
on
with
the
presentations.
So
as
a
general
point
of
order,
I
have
a
copy
of
everybody's
slides
downloaded
in
my
browser.
A
Eve
does
as
well,
so
if
quite
happy
to
let
you
share
your
own
screen,
whoever's
presenting
and
let
you
drive
your
own
slides,
but
if
you're
unsure
about
making
the
technology
work
or
or
whatever
we're
here
as
a
backup,
so
I
think
first
up
we
have
pascal
talking
about
the
technologies
draft
and
the
architecture
draft
so
pascal
feel
free
to
share.
If
you
want
or
or
eve
or
I
can
share-
and
you
can
shout
next
slide-
please
it's
your
choice.
This
could
be
easier.
If
you
don't
mind,
no
problem
so
eve.
B
D
I
move
the
mic
a
little
bit
okay,
so
I
guess
we
start
with
the
technologies
document
right.
So
what
I
wanted
to
say
about
it
is,
and
then
we'll
see
is
that
it's
been
mostly
stable.
The
worst
that
can
happen
to
it
now
is
next
slide.
Please
is
that
what
we
discussed
is
kind
of
obsolete
and
we
need
to
revamp.
You
know
just
to
talk
about
the
next
generation
for
instance.11ax
as
a
lot
of
focus
and
now
b
has
progressed.
D
Apart
from
that,
the
there
was
very
little
change
in
this
document.
We
we've
we've
discussed
more
the
use
of
different
frequencies,
for
instance
the
six
gig
in
in
wi-fi
and
and
because
of
that
tach
was
also
aligned,
and
thank
you
chevy
for
doing
this,
but
most
of
the
rest,
wi-fi
3gpp
ldax,
has
been
very
stable,
pretty
much
since
we
adopted
document
next
slide.
Please.
D
So
so
I
I
don't
know,
one
thing
we
could
be
doing
is
publishing
and
that's
what
I
suggest
we
do
an
alternate
would
be
to
see.
Okay,
since
we
started
this
document
two
years
ago.
How
much
of
this
technology
changed
to
a
point
that
we
need
to
rewrite
the
document?
D
Maybe
the
authors
could
could
look
at
that
as
part
of
the
war
group?
Let's
go
maybe
say:
oh,
we
need
to
update
this.
I
don't
know
just
because
technology
has
evolved,
but
I
think
content-wise
we
are
there
and
yes,
apart
from
modernization
to
the
argument,
there's
nothing
much
I
can
see
we
can
add
to
this
document.
D
C
A
Yeah,
I
can
see
the
same
email
to
the
list,
so
I
think
rocco.
If
you
want
to
send
it
again,
I'm
not
quite
sure
whether
it
was
an
attachment
and
it
got
stripped
off
or
not
quite
sure
what
happened
there.
D
But
yeah
do
you
think
it
has
to
be
processed
before
a
good
press
core?
Because
maybe
you
want
to
change
dramatically
the
document
or
is
it
like
something
which
can
be
part
of
the
work
of
last
call
resolutions
yeah?
I
think
it
will
be
better
before
okay,
well,
okay,
please,
please
resend,
I
mean
sure
we
didn't
get
it.
A
Okay,
so
I'm
I'm
quite
happy
to
hold
the
last
call
until
we
receive
rocco's
comments
and
and
the
author
team
can
have
a
look
at
it
and
see
whether
what
the
impact
of
addressing
them
is
and
depending
on
the
outcome
of
that,
we
can
go
for
a
last
call.
At
that
point,
it
doesn't
immediately
have
to
have
last
call
now,
but
absolutely
noted,
pascal
that,
apart
from
these
comments,
you
think
it's
ready.
So
I
think
we
can
probably
move
fairly
quickly
on
this
unless
somebody
else
has
comments,
but
thank
you.
D
Okay,
so
I
have
more
to
say
on
this
one:
this
slide
please
so
first
thing
is
compared
to
to
the
classical
sdn
model,
where
the
pc,
the
controller,
basically
pushes
some
rods
and
and
the
network,
just
you,
know,
obeys
and
forwards
the
packets
along
the
path
that
is
indicated
by
the
pce
row.
Basically,
the
core
flow
is
to
turn
that
into
a
new
loop,
where
we
we
observe
and
that's
the
the
role
of
bfdo
am
etc.
D
Then
we
can
leverage
the
wisdom
from
the
pce
that
built
this
complex
track
or
something
within
the
network
to
orient.
You
know
the
the
new
routing
decision,
then
the
new
psc,
that
we
we
have.
We
are
putting
together
as
part
of
row,
make
this
this
new
routing
decision,
of
which
subset
of
this
graph
is
going
to
be
used
for
the
next
packets
and
then
the
psc
acts
and
acting
basically
means
deploying
the
period
function
across
this.
D
This
graph
that
we
call
a
track
to
to
basically
use
the
the
selected
subset
of
of
this
graph.
This
period
activity
takes
place
at
the
net
service
layer,
so
we
need
basically
some
control
information
to
steer
across
the
network
this
this
perio
activity.
D
So
for
now
the
the
document
is
pretty
rich
on
the
psc.
It
was
rich
for
a
while.
Now
what
we've
done
recently
is.
We
have
improved
the
oam
section.
D
What
is
missing
throughout
is
more
precision
on
the
I
would
say,
the
type
of
exchange,
type
of
messages,
type
of
data
that
is
propagated,
made
available
at
the
different
places
to
obtain
the
expected
result.
D
For
instance,
in
no
know
am
there
are
multiple
forms
of
am
with
the
improvement
that
we
placed
we,
we
are
saying
hey,
you
can
do
this.
What
we
call
reversal
am
in
the
document
and
greg
now
has
proposed
another
term
which
is
upstream
so
we'll
discuss
that.
So
so
we
have
this
upstream
oem,
but
we
still
don't
know
which
data
which
formats
is
is
going
to
be
captured
along
the
way.
For
instance,
it
could
be
something
that
we
learned
from
dilip
that's
on
the
table.
D
We
have
not
really
expressed
what
came
of
wisdom.
No,
please
yeah,
for
instance,
the
statistics
about
the
quality
of
the
links,
etc.
The
pc
will
pass
to
the
plc
to
help
the
psc
make
its
future
decision
and
for
the
the
the
action
the
perio.
D
There
are
different
models.
As
I
write
down
here.
There
is
one
model
where
the
the
pse
is
on
the
ingress
only
so
it
has
to
basically
make
every
decision
of
what's
going
to
happen
all
around
the
the
past,
that's
followed
by
the
packet,
and
so
everything
must
be
placed
in
the
packet.
So
that's
one
way
of
doing
things.
D
There
is,
there
is
a
way
to
do
things
in
a
partial,
partially
distributed
fashion,
meaning
the
psc
may
hint
some
information,
some
goals
like
what
what
kind
of
quality
is
needed
on
the
rest
of
the
way
and
then
the
node
on
the
path
to
achieve
that
quality
may
decide
to
to
do
a
replication,
for
instance.
So
that's
halfway
and
now
that
the
psc
can
also
be
fully
distributed,
meaning
it's
in
every
node
and
just
based
on
on
the
the
reversal.
D
Am
the
upstream
of
am
coming
from
the
rest
of
the
way.
The
pse
at
every
hub
knows
the
rest
of
the
way
and
makes
some
decision.
So
so
we
have.
We
use
those
three
models,
but
we
have
not
really
described
the
type
of
data
and
the
type
of
logic
that
may
that
will
be
used
to
achieve
those
models.
In
particular,
when
we
signal
things
in
the
packet.
We
we
have
words
which
say:
hey,
we
could
use
beer
or
we
could
use
a
service
6.,
but
we
did
not
go
much
farther
than
that.
A
I
guess
so
I
see
balash
is
in
the
queue.
I
think
I
pronounced
your
name
right.
I
hope
I
did
so
are
you?
Do
you
want
to
take
questions
now,
pascal
or
at
the
end?
Oh.
G
Thanks,
thank
you
first,
I
I
would
have
a
question
for
clarification,
so
there
is
a
dedicated
oam
document
in
raw
and
now
the
raw
architecture
document
also
starts
to
speak
about
oem
functionalities,
so
how
oem
will
be
covered,
so
it
will
be
covered
in
two
documents.
It
will
be
in
the
architecture.
Just
refers
to
the
dedicated
oem
document
so
so
height.
How
this
discussion,
how
these
oem
functionalities
will
be
described.
D
So
we
we
are
working
on
a
good
point.
We
are
working
very
closely
between
the
architecture,
the
raw
am
and
the
deathnet
oem
documents,
and
we
are
trying-
and
you
know
it's
an
everyday
thing-
work.
We
are
trying
to
keep
them
in
sync.
D
Basically,
the
architecture
needs
to
give
the
overall
structure
of
things
that
the
oam
document
will
have
to
follow
like
we'll
support.
This
will
support
that,
for
instance,
the
the
need
for
upstream
comes
from
the
architecture.
D
So
so
that
that's
how
we
position
do
we
need
to
position
oam
in
this
wooden
loop
to
explain
what
role
it
plays
and
what
kind
of
messaging
can
happen,
but
without
going
too
much
in
the
details,
the
details
will
come
from
the
raw
document
or
even
the
net
document
for
everything.
That's
come
up.
A
D
Yes,
but
it's
it's
a
bit
more
than
that.
We
have
to
specify
what
kind
of
flows,
for
instance,
the
the
very
concept
of
upstream
or
am
yeah,
has
to
be
described
in
the
architecture.
It
has
to
explain:
hey
there.
Is
this
packet
coming
from
h
on
the
right
back
to
the
source
flooded
across
the
graph
to
learn
everything
that
is
to
learn
and
bring
it
back
to
the
source?
That's
that's
architecture,
and
then
exactly
you
know
the
format
of
this
message,
the
content
of
this
message,
etc.
D
The
details
go
to
the
om
document,
but
the
fact
that
it
exists
the
fact
that
it
flies
from
right
to
left
against
the
current.
This
is
architecture
does.
A
G
Yeah
yeah.
Thank
you
very
much
for
the
clarification.
I
I
think
that's
that's
good.
I.
I
have
also
another
question
for
clarification.
So
on
this
slide
I
I
see
that
that
service
layer
and
that
that
service
plan,
so
what
does
it
mean?
Is
it
the
dot
net
service
sub
layer?
What
you
mean
here
or
is
it
something
different.
D
No,
no,
that's
it
also
call
it
layer
or
sub
layer.
I
mean
the
sub
layer
is
still
a
layer,
but
but
I
mean
yes,
it's
the
net
service
layer.
It's
this
thing
where
replication
elimination
happens.
In
our
case,
we
we
are
extending
it
a
little
bit
because
pario
has
things
which
are
not
listed
in
the
net
architecture,
for
instance
arq,
and
there
will
be
more.
My
next
ballot
is
about
the
things
that
we
we
may
need
to
add,
either
us
or
that
net
in
its
next
steps.
G
Maybe
it
would
be
better
to
use
explicitly
that
terminology.
For
me
it
was
somewhat
confusing,
but
there
you
are
introducing
some
new
term,
which
is
absolutely
fine,
but
I
I
was
not
aware
whether
it
is
the
service
sub
layer.
What
you
mean
here
and
the
is
functionalities
that
service
sub
layer
is
providing
you
intent
to
extend.
I
Okay,
this
is
a
different
topic.
I
was
going
to
bring
this
up
on
the
next
slide,
but
since
you
took
questions
on
this
one,
it's
a
good
place
to
show
it.
Pascal
is,
I
take
an
approach
to
shame
me
to
provide
my
comments
that
I've
said
a
few
times.
I
You
do
the
author
list,
so
I
do
promise
to
provide
the
text
where
we
add
in
the
ability
to
do
multi-layer
integration
as
a
multi-layer
approach,
as
opposed
to
this
integrated
approach,
where
both
the
radio
layer
or
the
raw
layer
and
the
the
that
net
layer
are
fully
integrated
and
we've
said
we
want
the
architecture
allowed
for
both,
and,
I
said,
I'd
provide
some
text.
That'll
include
some
things,
including
which
is
on
the
next
line.
D
You
you
had
some
some
issues
here
and
there
that
that
you
said
when
you
get
the
pen
you're
gonna
edit,
so
I
mean
yes,
if
just
let
me
know
when,
when
you
want
the
ball-
and
I
will
you
know,
leave
you
the
documents
free
for
for
some
time,
so
you
can
do
the
changes
and
propose
them
and
whatever
and
then
we'll
decide
exactly
how
we
do
the
integration.
I
mean
it's
in
github
anyway.
D
The
the
functions
that
we
we
present
in
the
raw
architecture
can
be
seen
as
an
enrichment
of
of
that
net
as
being
worked
on
the
wire,
and
there
are
a
number
of
examples
of
that
so
perrio
with
with
the
arq
and
and
overhearing,
and
all
those
functions
is
an
extension
to
priof.
Obviously,
there
is
the
discussion
about
inserting
timing
information
in
the
packet.
D
D
It's
also
possibly
responsible
of
deciding
when
the
packet
will
cross
every
half
on
the
way,
maybe
providing
some
window
of
time
or
whatever,
and
how
this
is
signaled
is
yet
to
be
defined.
But
if
we
decide
to
support
it,
it
has
to
be
described
in
the
architecture,
and
there
was
this.
This
work
by
jacob
about,
for
instance,
providing
some
information
about
pretty
much
when
one
each
hub
should
be
complete,
and
that's
one
way
of
achieving
that
this.
D
So
that's
one
thing
that
we
could
discuss
another
one
is
sr
based,
so
sigma
trading
based
or
beer
tea
based
insulin
control
that
they
just
discussed
from
the
psc
to
enable
the
decision
by
intermediate
node
to
make
replication
elimination,
for
instance.
So
what
will
we
put
in
the
packets
and
that's
again,
an
architectural
decision
that
we
have
to
take
here
and,
like
I
said
there
are
some
couples
which
are
available
on
the
table
like
srv6,
with
or
without
extensions
to
what
exists
or
vrt
same
with
or
without
extension.
D
So
some
of
you
already
read
that
that
slide
and
yes
at
that
point,
follow
so
said
it
before.
I
could
so
progress
and
documents.
So,
yes,
we
we
we
work
quite
a
bit
on
it
in
particular
for
the
om,
but
not
only
so,
there
were
three
bumps
so
went
from
six
to
nine
since
last
etf.
A
D
My
fingers,
you
know
hoping
to
too
loud.
No,
we
are
not
there.
So,
yes,
the
new
work,
you
you
find,
the
abstract
was
kind
of
obsolete.
It's
been
reworked
I'll,
go
in
details
about
the
terminology,
because
you
can't
talk
intelligently
between
people.
If
we
don't
share
our
terminology,
it
can
go
anywhere.
So
we
we
needed
terminology
and
we
worked
a
lot
on
it.
D
Then
there
was
all
this
discussion
about.
You
know
oam
and,
as
badass
said,
there
is
what
fits
in
this
document
and
what
fits
in
the
other
documents,
but
keeping
them
in
sync
and
actually
distributed
are
not
two
but
three
documents,
because
there
is
the
row-
and
there
is
the
detonator
here
and
then
you'll
see,
and
we
have
to
define
terms
for
that
that
we
have
new
oem
methods
that
will
apply
there.
D
Is
this
two-step
discussion,
this
two-step
technique,
and
then
there
is
the
reversal
am
on
maybe
upstream,
if
we
have
to
agree
on
how
we
call
it
now
what's
missing.
As
we
said,
there
is
all
this
discussion
of
cross
layer
and
delete,
which
is
normally
lower
layer.
How
that
that's
fed
into
probably
the
the
reversal
am
and
how
that's
abstracted
and
returned
to
the
psc,
which
makes
this
morning
decision,
how
we
integrate
timing,
information
and
encode
it?
How
we
express
the
multi-path
shall
that
be
services
and
services
extensions?
D
Should
that
be
brt?
We
have
to
describe
that
in
more
details,
and
maybe
there
is
something
else
I
mean
if
somebody
sees
like
we're
missing
a
section,
but
basically
the
the
overall
structure
is
we
have
this
ooda
loop
that
I
just
described
on
previous
slide
and
we
want
to
provide
every
component
for
the
2d
loop.
That's
pretty
much
this
architectural
framework
document
yeah
so
do
steps
of
observe
orient.
You
know,
decide
and
act
next
slide.
D
So
now
goes
to
terms
and
how
much
time
do
I
have
just
please.
A
Sorry
I
was
on
mute
you're
a
little
bit
over,
but
I'm
willing
to
let
it
run
long
because
we
have
a.
We
have
some.
D
Okay,
so
the
first
thing
that
for
which
we
needed
terms,
was
what
I
call
differentiating
the
pipe
from
the
water
in
some
documents
and
and
work
groups,
and
sometimes
even
in
the
net
discussions.
D
There
is
this
term
path,
and
there
is
this
term
flow
and
the
term
flow
can
be
used
to
represent
an
application
flow
or
it
can
be
used
to
represent
some
abstract
aggregate
of
data
which
has
to
to
to
follow
the
same
treatment
we
care
about
the
treatment
we
don't
really
care
about.
You
know
what
goes
into
this
pipe,
so
we
we,
the
the
goal
of
those
two
terms
here,
is
to
differentiate
the
flow,
which
is
really
something
which
is
which
belongs
to
the
application
and
can
be
found.
D
You
know
by
the
six
double,
for
instance,
maybe
to
even
take
dpi
to
find
really
what
this
flow
is,
but
we
don't
really
care.
If,
if
you
look
at
the
net
architecture,
what
it
says
is
basically
you
take
the
flow
of
the
flows,
and
then
you
place
them
over
a
path
and
the
path
is
this:
this
track
this
subtract,
that's
the
sequence
of
nodes
and
treatment
that
have
to
be
followed
to
get
from
ingress
to
egress
and
that's
what
we
care
about.
D
We
want
to
to
place
the
packets
that
match
whatever
flow
or
oam,
whatever
policies
there
are
onto
a
path
tag
that
and
then
that's
the
only
thing
that's
used
for
forwarding.
D
So
we
need
to
place
the
packets
what
we
need,
but
we
don't
want
to
have
to
do
dpi
or
system
at
every
hub,
big
reason
for
differentiating
the
path
from
the
water
is,
you
might
put
different,
you
know,
temperatures
of
water
or
even
different
fluids
in
this
pipe
like
oam
and
application
flows,
you
want
them
to
follow
the
same,
to
receive
the
same
treatment
because
you
care
about
the
treatment,
not
what
what
is
being
treated
and
and
so
signaling.
The
the
track
is
really
what
we
are
about:
blah
blah
blah.
D
So
in
the
definition
we
we
take
the
terms
and-
and
I
won't
read
that-
but
please
please
take
the
time
to
read-
what's
in
green
here,
the
basically
we
provide
the
properties
of
what
we
call
a
track
and
you'll
find
particular
that
the
track
is
reversible,
meaning
that
you
can
send
the
packet
over
the
over
the
reverse
track.
While
you
inverse
basically
every
link
and
that
that's
usable,
for
instance,
to
send
oam
from
egress
to
ingress,
to
inform
every
node
on
the
way
about
the
shape
of
the
rest
of
the
way.
D
And
so
we
can
express
the
track
as
a
graph.
You
know
with
vertices,
which
are
the
relay
so
there's
the
service
of
layer,
nodes
and
the
edges
being
sequences
of
nodes
which
just
do
forwarding
so
they're
just
transit.
Not
next
slide.
Please.
D
Okay,
so
we
we
introduced
the
term
subtract.
A
subtract
is
a
track,
but
it's
the
subtract
will
be
used
to
refer
to
what
the
psc
has
selected
for
this
packet
and
that's
a
subset
of
the
track
that
was
designed
by
the
pce.
So
the
psc
is
really
there
to
make
a
decision
of
a
subtract
of
the
truck
per
packet
or
by
group
of
packet.
D
We
we
have
also
the
term
segment
which
basically
refers
to
so
an
edge,
and
it's
really
a
sequence
of
nodes.
A
track
is
a
complex
graph.
It's
can
be
a
direct
acyclic
graph,
but
it
can
even
be
not
really.
D
Asic,
like
so
you'll
see
that
there
is
this
concept
that
east-west
segments
are
oriented
left
to
right
so
from
ingress
to
egress,
but
there's
also
north-south
segments,
and
this
one
can
be
used
in
either
direction.
And
if
you
look
at
fig
one
in
the
net
architecture,
you
will
see
exactly
that.
You
have
no
self
segments
which
can
be
used
for
replication
elimination
in
both
directions.
D
So
it
results
that
the
track
is
not
really
a
directive
graph,
but
for
for
a
given
packet,
what
it
will
follow
will
be
a
directly
a
cyclic
graph,
because
if,
if
it
goes
across
north
segment,
a
given
cup,
he
cannot
go
back.
D
A
delta
copy
of
the
same
packet
could
go
the
other
direction,
but
a
given
copy
cannot
go
back,
and
then
we
have
this
concept
of
flapping,
which
is
useful
because
you
know
in
wireless
you
can
lose
your
your
link
for
split
seconds,
and
that
comes
back,
and
that
happens
all
the
time
and
that's
pretty
much
one
of
the
justifications
why
we
need
to
do
a
period
inside
the
network
as
opposed
to
just
live
life.
D
Next
slide,
please,
okay,
so
we
need
the
term
oam,
and
certainly
we
don't
want
to
reinvent
it.
So
we
basically
refer
to
60
to
81,
as
defined
as
the
reference
for
what
om
means.
D
We
just
remind
it
a
little
bit,
but
basically,
what
we
say
is
62
91,
as
presidents
for
defining
the
track
and
the
what
om
observes
in
in
the
case
of
raw
is
is
a
limited
domain,
that
domain
being
the
track,
and
it's
not
the
subtract,
it's
really
the
track
so
for
the
pieces
of
the
track
that
are
not
being
traversed
by
traffic
at
this
time.
That's
when
we
need
active
air,
which
is
stimulating
oil
that
has
to
be
injected
in
the
truck
even
on
portions,
which
are
not
being
traversed
by
traffic.
D
Now
we
also
need
to
make
the
difference
between
inbound
and
out
of
boundary
am
inbound,
be
following
the
traffic
with
the
exact
same
treatment,
whereas
out
of
bed,
we
can
take
another
path,
possibly
the
reverse
direction.
Next
slide,
please
possibly
the
reverse
direction,
and
that's
that's
when
we
we
really
create
this
new
piece
of
work
in
the
oam
domain.
That
seems
to
be
mostly
ours
for
the
time
being,
one
function
that
we
call
limited
oam
and
then
again
think
that
those
two
terms
limited
oam
and
rioso
am
are
brand
new.
D
We
need
to
agree
on
them.
There
is
already
an
alternate
proposal
for
reverse
oem,
which
would
be
upstream
or
am
to
really
indicate
that
it
goes
against
the
current.
So
please
feel
free
to
on
the
mailing
list.
I
want
to
discuss
proposal
for
alternate
names.
D
The
limited
oin
basically
says
we're
going
to
observe,
not
the
whole
track,
but
not
even
a
subtract,
but
a
different
function
on
one
node
or
just
a
few
nodes,
for
instance,
just
between
this
replication
node
and
this
elimination,
node
or
just
around
this
replication
node
by
injecting
a
packet
into
the
replication
function
and
observing
that
the
packet
has
been
replicated
in
due
time.
You
know
at
the
egress
so
just
observing
the
replication
inside
this
name.
D
D
So
that's
when
the
two-step
operation
is
is
handy,
so
you
have
a
first
step
which
basically
signals
hey,
let's
start
the
collection
and
so
the
nodes
forward,
the
packets
and
and
learn
you
know,
for
instance,
through
how
that
goes,
and
then
the
second
step
is:
is
the
packet
coming
the
reverse
direction
from
egress
to
ingress
capturing
all
the
measurements,
taking
a
picture,
if
you
like
of
the
graph
with
the
recall
with
the
measurements
that
were
recorded,
to
bring
that
back
on
the
reverse
path,
meaning
that
each
node,
which
is
being
traversed
by
this
oem
information,
can
also
learn
the
shape
of
the
rest
of
the
way.
D
A
Thanks,
pascal
sorry,
a
chair
hat
off
just
a
clarifying
question
about
flows
and
tracks.
Are
you
intending
to
reuse
the
work
in
it
that
assigns
flows
to
tracks?
So
my
concern
is
always
that
an
ingress
node
spots,
a
flow
it
maps
it
to
a
track,
starts
to
send
it
down
that
track.
But
an
intermediate
node
makes
its
own
classification
and
suddenly
switches
it
across
to
a
different
track.
D
A
That
that
track
management
we're
going
to
lean
on
debt
net
and
the
debt
net
technologies,
rather
than
inventing
extra.
But
do
we
think
there
is
extra
requirements
that
raw
has
beyond
the
facilities
that
that
debt
net
provides
with
dinner
over
ip
debt
over
mpls
and
the
various
encapsulations.
D
Well,
it
could
happen.
It
depends
on
how
far
that
net
goes
so,
for
now
the
the
the
there
are
two
things
right:
the
the
current
that
net
data
plane
basically
forwards
based
on
flows,
meaning
that
it
initiatively
reads
the
the
six
double
so
respectively.
We
don't
want
that.
D
I
have
been
pushing
some
new
work
based
on
hub
by
hub.
It
could
be
done.
Otherwise.
I
think
there
is
some
work
by
shusang
at
six
man
which
chooses
sr
v6,
and
you
know.
J
A
Yes,
so
it's
so
so
yeah
are
you
familiar
with
this?
I
spotted
that
there's
a
reasonably
new
working
group
called
application,
centric
networking
that
is
looking
at
adding
ipv6
header
option
fields:
option
headers.
Let
me
get
my
terminology
right
to
to
tag
flows
from
a
they
want
to
say
as
an
application
perspective,
but
it's
it's
an
extended
dhcp
marking
effectively.
D
D
D
You
know
I
tried
to
sync
with
the
work
at
spring,
for
replication,
elimination
and
so
far
and
banash
was
there
greg
here
and
so
far
it
seems
that
it's
more
like
okay,
everybody
will
do
its
work
on
this,
even
if
it
looks
like
from
a
distance
like
the
same
thing.
It
might
very
well
be
that
there
is
too
much
difference
and
then
we
need
to
to
do
it
on
our
sides.
We
have
to
make
that
same
work
and
just.
D
D
Even
if
you,
if
you
don't
see
the
sr
signaling
and
we
do
up
by
hub-
yes-
are
thinking
of
classifying
the
flows,
assigning
them
to
subtracts
to
tracks
actually
and
then
forwarding
based
on
the
track
information,
as
opposed
to
flow
information.
That's
critical
because
you
want
to
merge
oam
with
that
and
and
you
want
to
aggregate
flows
and
all
those
things,
and
that
can
happen
anywhere
in
the
network
and
they
said
banashi's
also.
D
If
it
is
just
to
finish,
if
we
can
reduce
signaling,
that
is
done
at
six
man
or
at
that
net
or
whatever
hey,
and
that
saves
some
rfcs,
I
mean
that's
good.
We
provide
the
architecture
and
the
missing
components,
but
whatever
can
be
converged
with
that
net
and
done
at
betnet,
I
mean
we've
been
doing
that
for
a.m.
Already,
that's
the
best
possibility.
A
So,
chair
hat
on,
I
completely
agree.
I
don't
think
inventing
yet
another
method
of
doing
this
is
is
a
sensible
idea.
I
think
we're
burning
cycles
there
and
I'd
rather
lean
on
the
work.
That's
happening
in
other
working
groups.
D
D
Work
for
pre-op
doesn't
seem
to
to
converge
with
that
night
in
general,
and
so
with
us,
it's
going
to
be
difficult
as
well,
but
we'll
see
right,
we'll
see
where
they
go
and
if,
if
there's
a
way
to
use
what
they
did,
because
it
makes
a
lot
of
sense.
I
say
since
I
read
it,
then
why
not,
but
let's
let's
them
do
their
stuff.
You
know
without
trying
to
please
everybody
and
let's
see
if
we
can
derive
what
we
need
from
their
work.
The
architecture
puts
all
those
things
together.
G
Okay,
so
regarding
the
oem,
I
think
it
would
be
very
essential
for
the
next
step
to
really
define
the
requirements
for
raw
regarding
oem,
and
that
should
be
the
first
step
in
my
understanding-
and
this
is
what
we
have
started-
also
to
clean
up
in
the
in
the
net
om
framework
to
list
explicitly
the
that
net
specific
oem
requirement,
and
I
think,
if
the
same
is
done
for
raw,
then
we
can
compare
whether
there
are
any
gaps
or
anything
else
to
be
added.
D
Where
we
are,
we
are,
we
are
very,
very
much
in
here
yeah.
Basically,
the
only
thing
which
which
I
may
disagree,
but
it's
a
word
in
game
is,
when
you
say
anything
specific
to
that
net.
The
architecture
must
say
what
we
use,
not
just
what
is
specific
to
us,
what
we
use,
everything
we
use
and
and
if
it's
basically
to
us,
then
we'll
have
requirement
to
define
to
to
do
the
rfcs.
D
If
it's
not
specific
to
us,
then
we'll
just
point
on
the
rfc
and
do
it,
but
the
architecture
must
say
we
are
doing
this
or
they
sell
this.
It's
not
just.
What's
specific
now,
obviously,
the
the
role
specifications,
not
the
architecture,
but
the
specification
will
specify
what's
new,
so
that's
where
your
words
fit,
but
but
what
globally
the
framework
everything
we
can
use
has
to
be
described
in
this
document.
G
D
Okay,
that's
my
last
slide.
Sorry,
all
right.
D
Oh
yeah
last
slide.
I
just
wanted
to
to
point
out
that
there
is
opinionated
text,
but
I
wrote
as
a
challenge
to
see
how
people
think
and
get
them
to
to
kind
of
react,
and
that
takes
probably
will
change,
but
that
like
says
that
the
best
method
for
the
psc
to
make
its
forwarding
decision
so
to
act
based
on
you
know
the
the
tools,
the
observation
by
oab
and
the
the
wisdom
by
the
psc,
the
pce.
D
The
best
city,
though
I
am
to
do
that,
is
the
reversal-
am
where
you
you.
You
know
at
each
point
of
time
the
quality
of
the
rest
of
the
way
and
the
two-step
approach
to
trigger
the
capture
and
then
do
capture
the
result
is,
is
the
best
content
called
the
the
expected
approach?
So
this
goes
into
you
know
into
the
direction
where
we
say:
that's
what
we
do.
I
don't
want
to
say:
that's
the
only
thing
we
do
right.
D
I
just
say
it's
the
best
suited,
that's
what
we
hope
to
do,
but
if
there
are
alternator
way
and
methods
which
can
be
as
useful,
that
text
must
change,
but
at
least
I
want
it
to
trigger
discussion
and
and
get
people
to
to
say.
Oh,
that
might
be
true,
or
there
is
also
this
thing
or
that's
completely
wrong.
A
J
A
J
D
D
The
frequency
at
which
we
capture
that
has
to
be
taylor,
then
I
guess
the
architecture
should
have
words
on
that.
I
wrote
them
on
some
mailing
list.
I
think
it's
that
spring,
I'm
not
sure
that
that
in
spring,
but
there
are
a
number
of
reasons
to
tune
the
reversal
am
period
dct
or
when
you
do
it
and
how
often
et
cetera
it
really
depends
on
how
many
packets
you
can
lose
in
a
row
how
much
redundancy
you
have
to
cover
anyway.
There
are
tons
of
reasons
to
to
to
tune
that
could
be
hard.
A
So
greg
did
you
have
a
comment
or
have
you
changed
your
mind.
K
Brought
very
interesting
point
perspective
of
that
collecting,
aggregated
metric
and
reverse
might
be
viewed
as
a
aggregated
metric
incurs
their
delay
and
that's
something
that
we
can
discuss
and
bring
to
attention
to
the
operator,
because
there
is
a
trade-off.
K
So
if
operator
wants
to
aggregate
the
metric
so
to
reduce
the
number
of
injected
packets
that
provide
the
feedback,
then
that
will
increase
this
latency.
D
The
need
for
instantaneous
growth
with
the
lower
level
of
redundancy,
the
more
redundancy
you
have,
the
less
you
have
to
be
very
precise
and
how
you
use
it
right.
So
so,
basically,
there's
a
there
is
a
balance
here
of
the
cost
of
holding.
So
I
am,
in
the
one
hand,
which
is,
which
is
spectrum
and
the
spectrum
you
can
save
by
not
using
the
full
track.
K
Yeah
so
again,
I
I
think
that
it's
it's
an
important
point
that
very
specific
for
raw
and
we'll
need
to
express
it
in
the
document.
A
So
I
I
this
is
a
great
conversation.
Let's
take
it
to
the
list,
I'm
I'm
watching
the
time
and
we're
eating
into
other
people's
presentations.
If
there's
time
at
the
end,
we
can
pick
it
up
in
the
the
extra
question
time
we've
got
at
the
end.
Meanwhile,
go
ahead,
carlos
you
you
over
to
you.
L
L
I
will
first
just
basically
summarize
again
the
use
cases
that
we
have
covered
in
the
draft.
I
will
not
go
into
the
details
because
we
have
covered
this
in
previous
meetings,
but
just
to
to
keep
the
context.
L
So
we
have
the
different
use
cases
described
in
the
in
the
document:
aeronautical
communications,
amusement
parks,
wireless
for
industrial
applications,
broadband
media,
wireless
screening,
uav
and
v2v
platoon,
and
control
edge,
robotics
control
and
emergencies,
instrumented
emergency
vehicle
and
for
each
of
these
use
cases
the
structure
in
the
drive
that
has
been
changed
for
some
time
already
is.
First,
we
start
with
the
use
case
description
high
level.
Then
we
going
to
the
specifics
that
are
relevant
for
for
raw
the
challenges
that
these
use
cases
poses
to
to
the
reliability,
reliability,
availability
in
wireless
heterogeneous
networks.
L
L
So,
in
terms
of
next
steps
that
we
agreed
in
itf
110,
basically,
we
always
request
input
for
the
working
group.
That
feedback
is
always
very
valuable
in
terms
of
the
structure.
The
use
cases
that
we
cover
are
they
relevant.
Are
they
not
do
we
need
to
merge?
Do
we
need
to
add
some
use
case?
That
is
missing?
Do
we
need
to
update
anything
because
some
some
of
the
requirement
has
changed?
L
Then
we
also
agreed
to
collaborate
and
align
with
their
architecture
document
this
we
vivid,
we
have
some
conversation
with
pascal
and
we
ensure
that
we
align
on
the
terminology.
These
changes
that
pascal
just
summarized
on
the
tracks
of
tracks
segments
all
these
kind
of
things,
the
use
of
flow
path.
We
we
checked
that
in
the
use
cases
document
is
aligned
and
consistent
with
architecture
document
we
also
discuss
about
working
towards
including
requirements
not
only
use
cases.
There
was
a
milestone
on
requirements.
Well,
the
document
already
has
something
on
requirements.
L
There
is
a
question
about
that
later
to
to
see
what
we
do
specifically
on
this,
and
then
there
was
some
discussion
on
the
integration
with
the
the
document
on
the
specific
requirements
for
industrial
use
case,
there
was
a
discussion
on
the
main
list.
The
the
concession
consensus
that
I
got
was
that
the
either
merging
integrating
was
not
a
good
idea,
so
the
idea
was
to
do
some
cross
reference.
This
is
what
we
have
at
this
point.
L
In
the
use
cases
document
we
make
a
reference
to
the
to
the
drasofia
industrial
requirements
and
I
don't
know
there
will
be
additional
discussion
as
as
mentioned
by
the
chairs
at
some
point
in
today's
meeting,
but
this
is
what
the
pro
use
cases
document
has
done.
Regarding
that
point
so
far,
then
the
changes
I
I
made
well,
I
already
summarized
most
of
them
check
terminology
for
consistency
done
other
reference
done.
L
We
also
generalized
the
use
of
uav
and
instead
of
uav,
what
we
refer
to
vehicles
in
general,
because
platooning
is
not
limited
to
uav
uavs.
We
have
platinum
in
in
cars
with
cars
or
trucks
vehicles
in
general,
so
we
basically
tried
to
generalize
that
section
to
not
to
be
specific
to
uavs,
and
we
also
added
a
summary
section
where
we
put
some
text
about
non-latency
critical
communications,
and
this
is
another
question
related
to
this
in
the
next
slide.
L
So
let
me
go
directly
into
the
questions,
which
is
the
main
point
of
this
presentation,
so.
L
A
Quickly
interrupt
with
the
with
the
point
of
order,
so,
as
you
said
on
the
last
slide,
you
now
have
a
reference
through
to
the
industrial
requirements,
which
is
obviously
a
personal
draft.
So
this
would
be
a
good
reason
to
adopt
the
industrial
requirements
as
a
working
group
document,
because
therefore
we
can
have
a
a
proper
reference
between
two
working
group
documents.
It's
unusual
otherwise,
so
just
for
the
clarity
of
the
working
group
carry.
L
On
okay
thanks-
and
I
basically
just
do
that-
I
fully
agree
with
that
adoption
paul
and
I
will
be
supportive
of
that
adoption.
So
going
back
to
the
question,
so
one
point
that
came
up
in
the
discussion
that
we
had
with
pascal
is
about
the
that
raw
is
not
only
about
latency
critical
communication.
So
there
is
a
component
about
the
or
there
are
some
use
cases
that
are
very
much
putting
the
focus
into
the
reliability
and
availability,
not
being
so
critical.
L
The
the
latency
part-
and
there
are
some
examples-
there-
wireless
gaming,
uav
and
b2v
platinum.
Of
course,
the
control
that
depends
on
the
scenario.
But
there
are
scenarios
in
platoon
that
you
don't
need
a
very
low
latency
to
to
make
them
work.
L
L
A
Yeah
but
rick
without
my
chair
hat
on,
so
I
think,
having
us
a
section
somewhere
in
the
use
case
is
saying:
non-latency
critical
communications.
I
think
absolutely
agree
whether
it
needs
to
be
4.1
in
every
section
is
debatable,
but
I
think
specify
concentrating
on
the
reliability
and
availability
as
the
key
drivers
rather
than
late.
Otherwise,
would
be
the
latency
critical
applications
over
wireless
law
rather
than
raw,
so
absolutely
support
it.
Don't
know
whether
we
need
to
cover
it
in
every
single
4.1.
D
Yeah,
I
completely
agree
as
well
and
it's
something
that
we've
been
hinting
for
a
while.
Certainly
we
have.
We
have
used
cases
where,
where
delivery
time
is
critical
and
but
we
also
have
a
very
important
use
case
where
we
basically
mostly
protect
the
access.
D
If
you
look
at
the
architecture,
there
is
one
section
just
on
that,
and
so
row
basically
observes
the
the
quote-unquote
lease
for
label
hub,
which
is,
which
is
the
first
wireless
hub,
hoping
that
the
rest
of
the
way
is,
you
know,
wired,
highly,
reliable,
very
fast,
etc,
and
so
since
we
don't
do
that
net
all
the
way,
there
is
no
way
to
guarantee
latency.
D
But
if
we
can
accept
that
most
of
the
loss
and
the
reliability
and
viability
issues
are
on
the
wireless
first,
half
like
wi-fi
or
5g,
and
that
the
rest
of
the
way
is
a
lot
more
reliable.
Then
yes,
raw
applies
even
if
latency
cannot
be.
D
Just
for
that
use
case,
it's
it's
exemplary
of
when
we
don't
ensure
latency.
B
And
one
of
the
things
that
you
referenced
in
an
earlier
slide
was
about
additional
whether
the
list
of
use
cases
was
complete
enough,
at
least
that's
what
you
seem
to
imply,
and
I
think
that
this
could
go
a
long
way
to
help
flush
out
some
of
those
additional
use
cases.
If
we
sort
of,
I
agree
with
rick
that
we
may
not
need
something
like
a
4.1
for
every
single
use
case
there,
but
going
through
the
exercise
of
asking
to
see
if
we
could
find
those
use
cases
would
be
interesting.
B
So,
for
example,
I
was
recently
looking
at
the
use
cases
from
the
net
document
and
there's
a
really
healthy
body
of
work
around
utility
use
cases
and
in
that
domain
it
there
actually
is
this
sort
of
you
know
there
are
a
set
of
applications
where
reliability
is
more
interesting
to
that
particular
application
than
than
the
latency,
and
so
I
was
thinking
in
in
the
wireless
domain.
So
that
was
an
example
of
where
I
thought.
Oh,
you
know.
Maybe
we
should
add
something
here
in
the
use
cases
for
net
for
raw.
L
Okay,
thank
you
thanks,
pascal
and
rick,
for
the
comments.
I
I
mean
I
fully.
This
was
just
a
question,
so
I
don't
have
a
strong
opinion
either
I
mean
I'm
not
even
pushing
for
this
just
to
trigger
the
discussion
how
to
how
we
address
this
thing
about
adding
the
non-latency
critical
communication
part
into
the
draft.
So
let's,
let's
try
to
have
a
discussion,
maybe
on
the
mailing
list
on
how
do
we
this
is
best
to
do
it.
L
L
So
I
have
a
question
here
again
very
open
to
the
working
group
and
especially
maybe
to
the
church
that
is,
we
already
have
some
requirements
for
raw
section
in
the
document,
so
I
don't
know
if
we
are
still
need
to
or
expected
to
develop
this
further,
like
maybe
having
a
wrap-up
section
on
requirements
and
putting
you
know
this
language
on
summary
language
and
requirements
for
raw,
which
may
be
good
in
the
sense
of
trying
to
be
cleaner
for
the
reader.
But
it
will
be
a
bit
challenging
because
we
have
different
use
cases
with
different
requirements.
L
So
it's
a
bit
hard
to
generalize
some
of
the
requirements
so
maybe
sufficient
as
it
is.
But
I
just
wanted
to
make
that
point
just
to
see
whether
there
is
something
that
the
working
group
expects
this
document
to
do.
That
is
maybe
not
yet
done
as
as
expected.
A
L
A
With
chair
hat
on,
I
don't
think
we
need
to
have
a
specific
requirements
document.
As
I
understood
the
consensus
of
the
working
group
is
the
use
cases
document
fulfills
what
we
want
out
of
a
requirements
document,
particularly
in
light
of
the
industrial
requirements
document
existing.
So
if
somebody
wants
to
write
another
document
which
drills
into
autonomous
vehicles
and
talk
about
specific
autonomous
vehicle
requirements,
that's
fine
that
that's
great
and
we
can
take
that
on
board.
But
I
do
like
the
idea
of
a
summary
so.
L
A
A
J
L
L
Okay,
thanks
and
and
then
well
the
typical
or
yeah
the
usual
next
steps
slide
on
whether
asking
for
feedback,
I'm
always
trying
to
get
additional
feedback
on
what
you
believe
can
be
improved,
removed,
updated
and
at
some
point
in
time.
I
would
like
to
ask
for
maybe
the
chairs
or
someone
the
chairs
to
to
ask
as
chairs
for
some
good
reviews
of
the
document
before
we
do
working
with
call
we
need.
A
Okay,
you
said
chairs,
so
that
that's
the
cue
would
anyone
like
to
volunteer
to
do
a
good,
solid
review
on
this?
Please
I
will
try
and
find
some
time
to
have
a
look
at
it
myself.
But
yes,
so
karina
go
ahead.
A
That
would
be
great
so
so
in
general
to
the
working
group.
We
think
carlos
thinks
this
document
is
pretty
much
done.
Yes,
a
working
group
last
call
is
probably
on
in
on
the
cards.
I
think
it's
probably
ready
for
that
lets
everyone
in
the
working
group,
if
you've,
if
you've,
got
a
spare
couple
of
hours
to
have
a
proper,
read
and
review.
That
would
be
fantastic.
A
B
It
looks
like
there
are
a
couple
of
others,
both
adam
and
xavier
villain
hosanna,
who
have
also
offered
on
the
chat
to
do
reviews.
So
you
can.
A
L
That's
highly
appreciated
and
just
one
one
point
rick:
I
do
think
that
we
need
to
go
through
this
couple
of
points
on
the
latency
critical
on
the
requirements
summary
before
we
go
to
the
working
group
last
call
so.
L
A
A
Okay,
so
so
from
as
as
one
of
the
chairs,
I
suggest
that
you
upgrade
the
document
to
put
these
to
address
those
comments
as
you
as
you
would
see
fit.
We
get
some
review
back
from
the
from
the
people
who've
offered,
which
is
very
kind
and
then,
when
you're
happy
we'll
go
to
last
call.
I
think
that
sounds
like
the
way
forward.
Okay,
okay,
thanks
carlos
it's
a
great
document
by
the
way,
so
I'm
desperately
trying
to
find
the
agenda.
So
next
up,
we've
got
fabrice
with
oam.
A
F
N
N
So
that's
just
a
diagram
of
the
the
historical
parts
of
the
draft.
Actually,
it
was
created
at
the
beginning
with
everything
together
we
first
split
the
draft
to
to
connect
everything
which
was
specific
to
that
net
in
a
more
generic
draft
and
for
the
oim
raw
draft.
This
is
very
focused
on
wireless
networks
and
since
the
working
group
adoption,
we
changed
the
version
just
copying
and
we
we
have
under
an
update
in
the
terminology.
N
N
So
for
the
vocabulary
we
changed
a
little
bit
some
definitions.
We
have
listed
ideoly,
the
inbound
hat
of
bonds
or
everything
to
make
a
distinction
between
the
oem
packets,
which
are
transmitted
through
the
the
recesses
which
have
been
dedicated
for
data
flows
or
not.
We
have
also
defined
thanks
for
cal,
thanks
to
carlos,
for
that
the
type
of
links
we
may
support
in
raw,
since
we
may
have
peer-to-peer
links
or
or
also
some
some
links
which
are
more
complicated
with
one
transmitter
and
several
receivers.
N
So
we
keep
on
only
considering
some
links
with
without
collisions,
but
we
may
have
several
receivers
for
each
of
the
transmission
opportunity
and
basically
we
also
remind
that
all
the
transmissions
that's
a
broadcast
transmissions,
so
any
node
which
is
in
the
vicinity
may
receive
it
and
may
be
able
to
look
at
it.
So
we
now
make
a
clear
distinction
between
the
the
characteristic
of
the
networks
and
the
constraints
so
typically
battery
lifetime.
N
We
also
introduce
a
powerful
about
the
mobility,
because
we
have
more
and
more
mobile
notes,
thanks
to
carlos,
for
that
also,
we
are
now
properly
defining
the
delay.
That's
the
time
between
the
generation
of
the
packet
and
the
reception
and,
more
importantly,
we
make
a
distinction
between
the
transmission
delay,
which
is
fixed,
actually
depends
on
the
bit
rate,
the
water
bit
rate
and
the
residence
time
the
queue
so
that
it
depends
on
the
skid
ring.
N
Our
second
update.
We,
we
have
made
bats
about
the
predictive
maintenance,
since
we
are
continuously
changing
the
other
one
and
the
characteristics
we
have
to
predict
the
evolution
of
the
future.
So
that's
the
key
to
proactively
detect
when
the
annuities
or
defects
will
overcome
and
will
break
the
transmissions
for
the
four
clearance.
We
are
addressing
the
problem
of
multi
attachments,
so
we
have
multiple
mip
for
each
up.
N
N
We
also
now
describe
clearly
the
information
collections
about
information
elements.
The
fact
that
we
we
need
probably
hierarchical
monitoring
because
the
oval
will
be
too
large,
because
we
we
have
a
large
collection
of
matrix
to
collect
because
of
the
water
characteristics
and,
as
a
matter
of
fact,
for
some
of
the
technologies
we
we
try
to
address.
We
have
a
very
small
bond
wave,
so
we
cannot
transmit
everything
that
we
would
like
to
do.
N
So
we
have
to
make
a
choice
and
a
yaki
core
approach
would
be
relevant
in
that
situation
and
the
last
part
which
which
needs,
I
guess,
is
still
a
little
bit
to
be
modified,
but
how
to
report
the
statistics
that
have
to
be
collected
back
to
the
source.
N
Actually,
it
comes
from
the
fact
that
we
may
have
multiple
paths
so
that
strike
that's
a
concept
of
track
when
we
have
multiple
possibilities
of
forwarding
nodes.
So
we
have
a
very
large
number
of
possible
forwarders
and,
as
a
matter
of
fact,
for
the
maintenance
intermediate
end
point:
we
we
have
multiple
forwarders
for
each
water,
so
so
that's
very
complicated.
N
N
So
I
guess
that's
probably
a
question,
but
we
should
also
support
a
collection
which
is
much
more
optimized.
So
that's
the
reverse
oem.
When
we
get
the
information
back
to
the
source,
we
may
be
able
to
collect
that
easily
and
efficiently
and
since
that's
not
so
straightforward,
so
I
guess
we
need
to
discuss
about
this.
This
problem,
specifically,
that's
the
only
current
weakness
of
a
draft,
to
my
mind,
so
next
step,
thanks
first
to
chavy
for
sending
his
comments
that
we
have
addressed
on
the
mailing
list.
N
If
other
persons
participants
want
to
review
proof,
read
the
draft
share
their
critics
comments,
they
are
very
well
welcome.
We
are
in
the
direction-
I
guess
for
our
last
call
just
after
having
addressed
the
problem
of
we
there.
So
I
am,
but
I
guess
we
we
are
quite
close
from
addressing
this
last
point.
A
So,
thank
you
very
much,
fabrice
and
and
the
whole
author
team
for
for
doing
this
work.
It's
it's
vital
and
and
excellent,
and
thank
you
for
the
various
commenters
for
providing
feedback.
I
don't
know
what
you
think
eve.
This
is
a
discussion
in
progress.
I
don't
want
this
document
to
go
to
working
group
last
call
because
I
see
a
dependency
on
the
raw
architectures
document.
A
I
don't
want
to
push
this
into
working
group
last
call
just
to
find
six
months
later,
that
we
needed
to
make
an
adjustment
or
or
make
a
demand,
perhaps
on
the
on
the
reverse,
oam
or
something
I'm
very
happy
for
it
to
sit
as
a
the
working
group
thinks.
This
is
pretty
much
done,
but
we're
we're
blocked
on
another
document.
I'm
I'm
very
happy
with
that.
What
does
what
do
you
think
eve,
and
what
does
the
group
think.
B
I
will
say
that,
while
you
were
thinking
about
one
kind
of
blockage
for
it
in
terms
of
the
architecture
document
inside
of
raw,
I
was
thinking
about
the
coordination
with
the
debt
net
oam
draft,
and
so
I
was
thinking
that
they
probably
need
to
hold
off
until
they
go
up
in
tandem
or
that
that
net
probably
precedes
this
one.
But
maybe
my
assumptions
are
wrong,
but
that
was
what
that
was
my
first
response
to
your
question:
rick
fabrice.
What
do
you
think
of
those
comments
and
other
authors.
N
Okay,
I
think
that,
yes,
it
makes
sense
to
to
work
to
wait
for
the
adoption
of
the
architecture
draft,
because,
yes,
we
have
a
dependency
between
between
the
two
drafts,
particularly
for
the
reverse
way
for
the
coordination
with
the
date
net
or
am
draft.
I
think
this
is
less
sensitive.
A
Okay,
okay,
so
I
I
think
we've
got
a
way
forwards
where
I
I
think
we
can
pretend
it's
in
last
call,
as
in
the
authors,
think
it's
ready.
It's
been
well
reviewed,
don't
let
that
stop
any
members
of
the
working
group
doing
another
deep
review
on
it
if
they,
if
they
want
to
do
that,
that's
fantastic
and
always
welcome
so
we'll
we'll
sort
of
assume
it's
done,
but
hold
it
pending
any
radical
changes
driven
by
the
evolution
of
the
architecture
document.
As
that
matures,
I
think,
that's
the
way
forwards.
A
Obviously
that
puts
pressure
on
the
architecture
document
to
make
progress,
because
I
don't
want
to
just
leave
this
in
limbo
forever,
so
sort
of
slightly
putting
putting
pressure
on
the
architecture
and
the
working
group
as
a
whole
to
go
and
review
the
architecture
document
and
help
the
architecture
authors
to
get.
That
document
worked
on
because
I
architecture
is,
I
think,
our
our
critical
path
now
and
is
actually
the
the
core
work
of
raw,
as
I
said
so
yeah.
Thank
you
very
much
fabrice.
If
nobody
else
wants
to
jump
to
the
queue.
A
Thank
you
so
quick
glance
at
the
agenda,
so
eve.
It's
you
and
we
are
two
minutes
ahead
which
gives
us
a
bit
more
time
for
discussion
on.
You
go
okay,.
E
Oh
hang
on
right.
I'm
just
gonna
hide
this
okay.
B
As
rick
introduced
early
on
in
the
agenda,
this
is
a
conversation
that
pokes
its
head
up
every
so
often
sorry,.
B
Okay,
good,
okay
and
I
will
use
my
new
york
voice
and
be
loud
all
right,
so
this
is
a.
This
is
a
topic
that
periodically
I
raise
my
hand
as
an
irritant
and
say:
shall
we
talk
about
interoperability?
B
I
know
where
so
many
of
these
documents,
not
only
in
raw
but
in
debt
net,
are
in
flight,
but
maybe
we
should
have
one
of
these
early
discussions
to
just
seed
people,
thinking
about
this,
to
cogitate
about
it
and
to
just
have
some
discussion.
So
this
is
really
a
bit
of
a
teaser
discussion
and
it
comes
about
because
this
visual
that
that
I
often
go
back
to,
which
is
a
very
rough
detonate,
raw
timeline,
it's
something
that
is
an
estimate.
Of
course.
It
doesn't
include
everything.
B
The
salient
feature
is
the
things
in
yellow
are,
as
in
on
the
net
line
you
can
see.
These
are
things
that
have
become
rfcs.
B
The
the
the
buttons
in
bright
green
are
giraffes,
that
we
have
milestone,
estimates
around
and
and
then
the
so
I
showed
detonate
here,
which
you
know
seems
to
be
marching
along
at
a
at
a
good
cadence.
The
timeline
of
course
comes
way
before
this,
for
when
debt
net
started
and
no
doubt
it
will
proceed
into
the
future.
Beyond
this
and
raw
you
can
see.
Many
of
our
documents
are
still
in
the
id
phase.
That's
okay!
B
We
just
launched
about
a
year
and
a
half
ago,
and
then
there's
this
ietf
hackathons,
which
I
I
think
the
hackathon
started
somewhere
in
the
80s
in
the
maybe
the
mid,
not
80s
the
ietf
85,
or
something
like
that,
maybe
10
years
ago,
15
years
ago.
But
but
it's
this
idea
of
hackathons,
held
jointly
with
the
itf,
is
something
that
has
evolved
over
the
years.
B
Obviously
it
happens
three
times
a
year,
and
if
we
could
imagine
that
we
had
specs
that
were
mature
and
finished,
what
are
the
kinds
of
things
that
we
might
bring
to
an
I.t
hackathon,
and
is
it
even?
Is
it
time
to
start
thinking
about
if
and
how
we
would
use
them
to
to
good
end?
Some
of
the
aspirational
kinds
of
demonstrations
that
I
have
here
on
the
bottom
follow
the
evolution
of
these
broader
discussions.
B
You
know,
maybe
we
would
begin
with
just
purely.net,
demonstrate
why
a
layer,
3
solution
is
interesting.
It
can
cross
subnets
and
provide
scalability
what
happens
when
we
pair
layer,
3
determinism
with
layer
2,
maybe
in
the
form
of
something
like
tsn,
what
happens
when
we've
got
wired
and
wireless
working
with
tsn?
You
know
these
are
the
kinds
of
things
and
clearly
this
is
aspirational,
because
I'm
showing
this
all
on
this
timeline,
it's
not
to
scale.
B
You
know
those
sorts
of
things
are
probably
well
into
the
future
go
into
2022.,
but
this
is
to
put
this
out
there.
Now
I
put
this
out
there,
because
when
I
look
at
debt
net
and
not
raw
so
much,
but
but
when
I
look
at
debt
net,
you
know
there's
a
pretty
healthy
body
of
rfcs
that
are
completed
for
the
foundational
drafts.
The
data
plane
drafts
not
drafts,
but
there
are
rfcs.
B
Now
the-
and
there
are
you
know
just
a
few
more
specs
that
might
complete
the
suite
of
things
that
someone
would
use
to
implement
a
full
net
implementation
and
and
raw,
as
you
can
see,
is,
is
not
quite
there
yet
but
nonetheless,
so
so
the
the
question
that
I
really
often
come
back
to
is:
how
might
we
use
an
ietf
hackathon?
Should
we
use
an
ietf
hackathon
as
a
venue
for
interoperability
testing
and
it
used
to
be
the
case
that
hackathons
happened?
B
Oh
you
know
for
a
couple
days
over
a
weekend
and
and
that's
been
growing
steadily
and
during
covid,
the
hackathons
are
week-long
events,
which
is
actually
quite
promising
from
the
standpoint
of
when
you
have
drafts
that
have
complexities
that
are
going
to
require
some
sophisticated
sort
of
setup
that
you
know
a
longer
period
of
time
might
be
beneficial
to
them.
B
B
You
know
one
is
it
time
to
cue
up
these
kinds
of
discussions,
because
we
are
having
more
mature
sets
of
of
rfcs
and
does
the
pop-up,
hackathon
or
plugfest
offer
us
the
right
format
for
the
kinds
of
testing
we
want
to
do
both
in
terms
of
the
number
of
days
that
this
kind
of
hackathon
happens
and
the
frequency
with
which
we
might
want
to
be
doing
this
interoperability
testing
and,
admittedly,
my
fascination
with
this-
is
when
you
get
to
the
part
around
well
what?
B
If
we
want
to
pair
this
with
some
tsn
capabilities,
how
might
a
hackathon
could
a
hackathon
facilitate
those
kinds
of
access
to
those
kinds
of
capabilities,
and
do
we
need
to
think
about
more
permanent
underlying
infrastructure
in
order
to
even
have
our
our
hackathons
or
plug
fests
and
the
so
so
one
of
the
questions
would
be?
Might
there
also
be
a
range
of
approaches
to
how
we
go
about
supporting
hackathons
and
interoperability
testing?
Do
we
want
to,
in
some
sense,
have
a
more
permanent
testing
strategy?
B
I
would
go
it's
a
little
bit
bold,
to
call
what
we
do
a
test
bed
in
the
sense
like
it's
not
a
permanent
infrastructure,
but
maybe
we
want
to
create
something
more
permanent.
Maybe
we
want
to
borrow
or
or
partner
with
or
even
invite,
others
to
come
in
and
showcase
the
sorts
of
testaments
they
had
for
this
sort
of
deterministic
networking
and
what
kinds
of
collaborations
do
we
want
to
think
about?
Fostering?
B
B
I
have
enjoyed
being
an
observer
of
how
he
conducts
the
hackathons,
which
is
to
partner
pretty
actively
with
our
sister
or
adjacent
standards
bodies
like
in
in
the
think,
to
thing
research
group
case
w3c
as
well
as
industrial.
Well,
I
guess
you
could
call
an
industrial
forum,
but
a
standards
forum
like
one
dm
which
is
doing
similar
work
and
so
partnering
across
you
know
formal
standards,
bodies
and
informal
forums
to
get
the
right
mix
of
participants
at
these
kinds
of
events.
B
So
I
will
open
up
the
floor
to
see
if
there's
like
what
do
people
think
about
thinking
beyond
that.
First
collection
of
of
rfcs
that
might
give
us
a
hold
on
a
full-bodied
implementation
of
some
of
this
work.
B
Anyone
in
the
queue
I
can't
see
the
screen,
but
I
would
also
invite
my
co-chairs
to
to
come
to
the
bike
and
and
further
elucidate
some
of
these
ideas.
M
Quickly
say
what
was
I
was
going
to
type
so
indeed
using
an
organization
like
a
research
group
or
a
working
group
as
long
as
you
have,
it
is
really
a
good
way
to
to
bring
together
people
from
different
organizations,
and
the
hackathon
is
is
a
very
good
milestone
for
that,
because
people
prepare
for
that,
and
then
people
have
a
week
to
bring
things
together
and
make
them
work
together.
M
M
You
might
not
be
happy
even
with
the
wonderful
new
stuff
that
that
now
is
available
for
people
who
want
to
share
networks
from
remote
points
during
the
hackathon.
So
that's
probably
something
where
you
need
to
think
about
what
the
best
setup
is,
but
there
are
probably
still
so
many
things
that
can
be
done
at
the
hackathon.
I
I
would
heartily
recommend
pursuing
that.
A
So
I'll
add
my
voice
to
the
mix,
because
I've
I've
had
this
side
conversation
with
eve
before
my
one
concern,
I
think
ties
into
what
carsten
has
said,
which
is
when
we're
trying
to
do
reliable
protocols,
building
on
top
of
reliability,
capabilities
at
layer
2,
using
the
the
network
facilities
available
at
a
hackathon
short
of
bringing
a
a
very
complicated
set
of
equipment
specifically
for
it.
I
I
think,
there's
a
and
I'm
not
a
huge
hackathon.
J
A
Devotee
my
concern
is
that
the
building
a
rig
where
you
can
start
to
really
validate
what
you're
designing
works,
which
is
part
of
what
a
hackathon
or
a
plug
fester
an
interoperability
test,
is,
is
to
validate
that
the
the
the
protocols
and
architectures
that
we've
spent
our
time
working
on
do
actually
work
needs
quite
a
complex
rig
when
you're
talking
about
not
only
wireless
systems
but
determinism
as
well,
and
I
wonder
whether
that's
too
big
for
an
ietf
hackathon
or
whether
there's
something
else
that
can
be
done,
and
I
don't
have
the
answers
to
these
things,
which
is
why
I'm
interested
in
other
people's
opinions.
J
Voice
from
rick
it
is
quite
a
big
undertaking
for
a
hackathon
I've
done
it
before.
In
the
driftworking
group
we
do
wireless
protocol,
we
were
doing
broadcast
stuff.
I
had
to
bring
stuff
to
singapore
with
me
and
it
was
a
bit
of
a
pain
to
be
put
it
mildly.
So
I
can
understand
that
sentiment.
It
might
be
beneficial
because,
as
he
pointed
out,
you
know
if
we've
been
doing
hackathons
for
weeks
long
a
week
long
now
it's
a
hey
at
112
hackathon.
A
Thanks
adam,
you
make
a
very
good
point
that
around
the
planning-
and
that
is
something
that
definitely
that
the
chairs
are
here
to
assist
with,
so
that,
if,
if
there's
an
understanding
that
yeah
there's
some
willingness,
as
we
mature
the
technologies
of
course,
to
attempt
to
do
something
at
a
hackathon,
but
it's
going
to
need
a
lot
of
organization
to
try
and
get
kit
to
wherever
it
needs
to
be
or
or
connected
in
whatever
distributed
manner.
It
currently
exists.
That's.
B
Something
that
an
early
discussion,
because
I
think
it's
complicated
enough-
that
it
really
is
going
to
take
some
brainstorming
and
thinking
about
and
planning
and
assessing
whether
maybe
we
need
to
do
something
slightly
differently
than
a
hackathon.
B
But
you
know
again
and
it's
because
it's
pr
it's
not
at
ietf
112
by
any
means.
But
maybe
it's
a
year
out,
not
sure.
A
So
is
there
anyone
with
a
counter
to
this
say
you
know,
does
someone
want
to
say
I
don't
see
the
point
of
this
we'll
do
it
inside
my
corporation
and
we'll
be
happy
with
our
product.
It's
quite
a
bold
statement
as
an
itf,
but
it's
a
perfectly
valid
one.
I
mean
that
might
be
the
approach.
We
we
let
companies
or
universities
do
it
on
adam.
J
The
kind
of
what
you
were
just
saying
rick
is
that
you
know
company
will
do
it
internally,
they'll
be
happy
with
their
product.
It
would
be
more
of
an
exercise
for
them
to
just
come
and
say:
oh,
is
there
going
to
be
another
company
there?
Let's
see
what
happens
when
we
put
two
our
two
systems
next
to
each
other,
what's
going
to
explode.
A
And
that
that
is
a
very
valid
point.
It's
it's
about
the
interoperability.
It's
because
we're
we're
aiming
for
you
know.
Layer
3
is
about
connecting
the
layer,
2
technologies
together
and
keeping
that
reliability
acro
across
those
heterogeneous
layer,
layer
2s.
Otherwise
we
can
all
just
go
away
and
use
tsn
or
5g
or
whatever,
and
and
there's
no
point
to
this
working
group.
So.
B
Actually,
I
I
do
think
that
that
is
where
the
where
we
got
to
and
why
it
is
that
I
use
the
term
showcase
various
testbed
strategies,
because
companies
aren't
likely
doing
and
doing
this
within
their
own
walls
and
creating
their
own
test
pads.
But
that
perpetuates
the
problem
that
we
have,
which
is
that
you
know
interoperability
with
oneself
is,
is
boring
and
it's
really
an
interoperability
test.
And
so
maybe
this
is,
you
know,
becomes
a
place
where
we
can
entice
others
to
share
with
us
their
strategies
for
doing
testing.
B
Maybe
it
would
help
us
even
evolve
the
kind
of
hackathons
we
support
or
or
the
borrowing
of
resources
elsewhere,
and
I
think
there
may
be
precedent
for
that
within
the
hackathon
community
at
itf,
but
I
don't
know-
and
it's
probably
worth
engaging
some
of
the
people
who
are
more
involved
in
the
hackathons
and
have
watched
them
evolve
to
ask
exactly
that.
Question.
Go
ahead.
Rick.
A
Can
I
have
a
clarifying
point
here?
What
I'm,
what
I
don't
think
we're
proposing
is
any
sort
of
formal
verification,
so
we're
not
handing
out
badges
to
say
this
is
ietf
raw
approved
technology.
This
is
purely.
A
Exactly
but
I
wanted
to
underline
that
at
the
mic,
what
we're
talking
about
is
validating
the
assumptions
that
have
gone
into
the
standards
that
we
have
produced
to
make
sure
that
that
we
haven't
written
nonsense,
I'm
pretty
sure
we
haven't
but
or
we
won't,
but
until
you
check
it,
you
never
really
know.
M
Just
we're
still
talking
so
yeah.
I
think
that
that
interrupt
testing
is
is
a
useful
thing
on
its
own
and
when
we
built
co-op
at
the
start
of
last
decade,
we
had
several
events
that
etsy
organized
for
us,
where
we
actually
brought
together
our
implementations
and
went
through
a
formal
program
of
tests
that
we
were
doing
this,
that
didn't
lead
to
a
badge
or
anything.
That
was
not
the
point,
but
the
point
was
to
to
really.
J
M
At
a
high
level
of
of
test
coverage,
so
there
would.
I
was
some
assurance
that
what
we
were
doing
were
was
understood
by
most
of
the
people,
and
I
think
a
hackathon
is
a
slightly
less
structured,
so
yeah.
Of
course
it
needs
planning.
But
I
think
you
can.
You
have
more
ability
to
to
react
on
the
spot
to
weird
things
that
are
happening
and
we
we
actually
when
we
did
rock
in
in
the
early
2000s.
M
We
we
had
several
meetings
that
we
called
interrupts,
but
really
they
were
about
finding
problems
where
the
specifications
allowed
different
interpretations
and
so
on
and
resolving
them
and
the
spot
fixing
the
code
on
the
spot
and
and
carrying
on,
and
that
also
was,
was
very,
very
useful
and
that's
what
that
was
much
more
like
a
hackathon
except
that
at
a
hackathon.
You
are
not
even
expected
to
bring
a
fully.
M
So
so
you
can
still
write
code
while
you
are
there.
So
I
think
that
that
are
the
three
points
on
the
scale
that
you
can
can
try
to
look
at
and
the
hackathon.
B
Great
that
that
is
fabulous
feedback
and,
like
I
said
I
really
have
enjoyed
watching
your
your
strategies
of
drawing
in
the
the
broader
community
inside
of
some
of
these
other
groups
that
you're,
leading
and
and
do
see
that
as
a
model
for
what
we
could
be
doing
here.
B
A
I
think
we'll
be
we'll
be
continuing
to
to
lean
on
carsten
for
inspiration
and
advice
as
this
matures,
I
don't
hear
anyone
objecting,
but
I
I
understand
several
people
are,
are
being
quiet
about
this
because
there's
obviously
corporate
interests,
etc,
etc.
But
thanks
eve,
I
think
I
think
that
was
worth
asking
and
we
weren't
expecting
any
concrete
results
from
it
so
which
is
which
is
great.
A
So
we
have
11
minutes
left
in
the
session
on
the
agenda.
This
is
marked
as
open
mic
any
other
business,
so
this
is
really
over
to
the
floor.
If
anyone
has
anything,
they
want
to
bring
up
or
ask
any
clarifying
questions.
They've
just
thought
about
on
any
of
the
presentations
we've
had
or
anything
else.
Raw
related
put
your
hand
up
jump
to
the
queue
and
ask
away.
B
A
A
Yes,
likewise,
thank
you
very
much.
John
go
ahead.
C
Plus
one
great
meeting-
and
I
it
did
my
heart
good-
to
hear
actual
substantive
discussion.
Thank
you.
Everybody.
A
A
A
If
only
there
were
cookies
available
for
everyone,
we
could
all
rush
out
and
eat
them,
but
hopefully
we
will
get
a
chance
to
meet
in
person
at
some
point,
kovid
willing,
but
otherwise
thank
you
very
much
for
your
attendance
and
your
presentations
and
please
review
the
drafts.
We've
got
in
progress.
All
review
is
useful.