►
From YouTube: IETF-RAW-20220715-1500
Description
RAW meeting session at IETF
2022/07/15 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
I'm
afraid
I
couldn't
make
the
the
last
meeting
two
weeks
ago
on
the
grounds
that
I
was
on
vacation,
so
I'm
very
much
catching
up
with
the
outcomes.
From
from
that
at
the
moment,
we
don't
have
much
of
the
way
of
an
agenda,
mostly
because
I
was
kind
of
hoping
that
pascal
and
eve
would
suggest
an
agenda
as
they
attended
from
there.
A
A
I'm
of
hoping
he
joins
fairly
promptly.
I
did
give
him
a
nudge
a
couple
of
days
ago
to
say
it's
this
friday.
Can
you
make
it
and
he
said
he
was
rearranging
his
calendar
to
make
sure
he
could
so
I
am
really
hoping
he
does
arrive,
and
eve
also
is
on
vacation
at
the
moment.
So
she's
not
going
to
be
able
to
meet
this
meeting.
Sorry
uk
is
having
a
heatwave
at
the
moment,
so
I
shall
be
drinking
continuously
through
this.
A
A
A
A
Welcome
I'm
just
trying
to
I'm
just
flipping
through
the
notes
from
the
last
interim
to
see
whether
there
was
anything
in
particular
that
were
actions
to
be
taken
at
this
meeting,
and
I
can't
see
any
immediately
but
pascal
and
john
in
particular,
or
carlos.
Actually,
if
you
can
see
that
there
was
any
actions
that
needed
to
be
taken,
can
you
jump
to
the
mic
and
remind
why?
But
tell
me,
because
I
can't
see
anything
at
the
moment.
C
C
A
C
It's
still
unclear
in
that
net,
how
the
transport
signal
to
the
network
so
that
what
the
transport
layer
is
and
what
it
does
to
signal
to
the
network:
bang,
bang,
bang
gear
or
the
packets.
So
this
is
still
undefined,
and
I
had
a
draft
that
I
submitted
to
tsv
area
explaining
that
and
explaining
that
we
need
a
transport,
but
that
that's
beyond
raw.
C
Now
that
matches
I've
not
entered
much
details
on
that,
because
all
the
transport
discussion
does
not
exist.
It
will
have
to
come
one
day,
but
in
this
role
and
that
scenario
would
probably,
if
you
want
the
first
story,
we
probably
want
to
talk
about
the
transport
as
well.
So
I
just
said
you
can
have
one
next
to
the
other
like
rolling
device
and
that
netting
network
or
even
loaded
net
in
network,
or
you
could
have
rover
that
net,
meaning
that
raw
function
which
operates
in
the
network
in
in
the
the
top
of
the
service.
A
I
just
can
I
just
drill
into
one
thing:
you've
just
said
there
a
little
bit
deeper,
which
is
because
I'm
trying
to
take
some
notes
at
the
same
time
and
can
someone
else.
Please
help
it's
interactive,
hdoc
and-
and
I
I'm
a
terrible
note
taker
I
I
can
only
apologize
much
to
the
annoyance
of
of
all
my
academic
tutors.
I
am
terrible
at
taking
notes.
You
said
you
believed
that,
in
order
to
make
raw
work
successfully,
we
needed
support
from
the
transport
area.
We
needed
some
some
transport
protocol
support
in
order.
C
It's
really
for
that
net.
It's
not
really
a
role
right,
it's
more
generic!
Well,
it
did
expectation
in
that
net
and
and
remember
the
only
document
that
talks
about
that
is
a
personal
submission,
probably
zero,
zero
zero
one,
which
is
one
or
two
years
old,
with
my
name
on
it
and
that's
right.
So
there
is.
This
is
not
a
discussion
that
we
could
have
in
that
net
and
part
of
the
problem
is
that
net
is
internet
area.
It's
not
transport,
but
the
point
is
you
don't
want
tcpr.net?
C
Do
you,
because
what
that
net
will
we're
gonna,
it's
gonna
expect
is
blocks
of
maximum,
say
a
certain
size
like
2k
at
a
certain
period
and
this
they
will
be
injected
at
that
period
across
the
network,
and
if
you
give
that
net
2k
every
second
I
mean
that's
stupid,
2k
every
second,
you
will
transport
them
with
full
grantees.
If
you
give
that
net
more
than
2k,
what's
going
to
happen,
is
either
the
increase
discards,
your
extra
packet
re
put
them
in
the
network
with
different
costs.
C
C
Equivalent
to
vcn,
but
but
the
first
thing
is
say
that
net
is
in
my
box
right,
I'm
the
one
that
I
have
that
net
local.
The
first
thing
is,
if
I
put
tcp
over
ls
right,
I
mean
tcp
window
will,
even
if
you,
if
you
have
the
the
mss
correct
to
2k,
I
mean
the
tcp
window,
will
will
try
to
grow
and
and
then
it
will
be
cut
by
that
net
or
you
know
because
curing
it
ingress.
C
It
makes
no
sense
on
that
net,
so
it
will
be
cut
and
and
then
it
will
reduce
dramatically,
and
so
you
will.
You
will
see
that
see.
So
that's
some
type
of
traffic.
You
know
you,
don't
you
want
to
flat
traffic?
You
will
see
so
so
that
tcp
is
not
what
you
want
over
that
net.
You
want
something
that
can
effectively
deliver
just
in
time.
Bang
bang
bang
bang
blocks
of
2k,
regardless
of
what
the
application
gives.
So
this
three
means
that
the
transport
must
be
time
aware.
C
For
one
thing,
it
must
deliver
the
packet
to
the
network
at
a
precise
time,
and
until
that
precise
time
it
must
basically
pack
everything
it
can
in
this
2k,
meaning
that
it
will
have
to
probably
get
different
blocks
from
the
upper
layer
like
a
tcp
stream,
but
just
aggregate
aggregate
aggregate
what
the
apollo
gives
until
those
2k
are
full
and
when
the
2k
are
full,
then
at
the
precise
period
give
them
to
the
network.
So
you
see
that's
not
tcp.
That's
not
udp,
either.
C
C
A
C
Yeah
incomes
is
when
there
might
be
a
need
for
an
interface,
because
if
that
net
is
not
in
my
box
now,
but
that
next
is
on
the
first
hop
box,
I
don't
even
I
don't
know
when
time
comes
so
so
it's
probably
it's
probably
a
need
for
a
signal
like
a
pool
or
something
coming
over
the
internet,
the
ethernet
and
and
that's
where
my
draft
has
read
two
sides.
One
is
one
hop
it's
layer,
two
and
it's
not
tomorrow,
that
you'll
see
it,
but
it's
basically
something
like
a
pull
from
from
the
switch.
C
B
C
We
are
talking
about
very
precise
time
here,
so
so
the
two
clocks
will
drift,
and
so
I
think
the
two
times
managed
separately
is
not
very
good,
so
you
really
want
something
on
the
you
and
I
to
make
sure
the
host
is
synchronized
to
to
the
switch
yeah
okay.
So
so
what
that
is-
and
the
pool
is
one
way
of
doing
it-.
A
So
raw
is
about
producing
this
reliability
across
wireless
links,
and
we
talked
about
perio
and
path,
selection,
elements
and
path,
computation
and
how
they
interact
with
computation
elements.
Is
the
control
plane
to
establish
mechanisms-
and
I
know
perio
is
a
way
of
doing
this,
but
there
is
also
a
second
piece
which
is
there.
Are
they
are
lower
layer?
I'm
not
go
they're,
not
always
layer.
Two,
because
the
example
you're
using
is
subtly
different,
but
there
are
layers
below
you
know
the
data
layer.
A
Yeah
yeah
yeah,
so
so
there
are
link
layer
solutions
which
are
effectively
from
an
ip
concept.
One
hops-
and
you
know,
decknet-
is
trying
to
bind
these
things
together.
So
you
get
an
end
to
end
deterministic,
deterministic
deterministic
path,
and
we
are
within
the
scope
of
the
raw
working
group
looking
to
do
that.
Deterministic
behavior
over
a
a
path,
including
a
wireless
link,
not
just
entirely
made
of
wireless
links,
isn't
what
you're
proposing.
D
A
Saying
that
to
take
advantage
of
this,
actually
you
need
transports
that
are
that
will
take
advantage
of
it
and
not
naively
fail
based
on
what
debt
net
and,
by
extension,
raw
has
laid
down.
So
raw
can
develop
control,
plane,
protocols
and
oam
protocols
to
allow
us
to
say
actually,
yes,
I
can
give
you
a
deterministic
path
track.
What
do
we
call
it?
C
The
first
big
switch,
which
was
the
20
20
20
20
20
to
20,
and
it
would
have
a
cir
function,
committed
information
right
and
that
cir
would
expect
you
know
a
maximum
burst
within.
Basically
cir
was
the
the
right
and,
and
there
was
maximum
burst
and
then
a
period
associated
to
that
and
and
the
endpoints
we
connected
to
that
were
the
classical
old
sna
devices
and
those
were
window
based,
and
so
what
happened?
C
And-
and
we
did
not
have
cia
function
in
the
36
40-
it's
not
76
at
the
time,
which
means
we
would
do
just
what
knife
tcp
will
do
of
with
title
to
the
two.
So
it's
basically
a
window
that
can
grow
until
you
know
it
shrinks
back
to
zero
or
something.
When
you
have
a
loss.
I
should
expect
to
work
so,
and
so
the
window
would
always
shrink
back
to
because,
as
soon
as
it
grew,
the
switch
would
cut
because
of
the
cr.
C
And
so
what
I'm
describing
is
is
something
I've
experienced.
You
know
the
bad
way
and-
and
we
produce
the
cir
very,
very
very
quickly
on
the
transmitter
making
sure
that
we
effectively
send
what
the
switch
can
accept,
because
otherwise
I
mean
the
traffic
was
drops.
You
know
each
one.
You
would
wait
until
one
time
or
something
which
was
whatever
to
resend
one
packet,
because
the
throughput
went
to
a
few
kbps.
A
Yeah,
so
your
utilization
of
this
beautifully
laid
down
path
through
a
combination.net
and,
by
extension,
raw
we'd,
have
laid
down
this
beautiful
path.
All
the
switch
equipment
along
that
path
would
be
ready
to
to
give
you
that
that
deterministic
packet
rate,
you
then
do
something
dumb,
which
means
you
don't
take
advantage
of
it,
and
your
utilization
of
that
path
drops
to
near
zero.
A
C
C
B
A
C
C
C
D
It's
a
pretty
good
idea
to
document
that
in
the
architecture
so
saying
certain
things
we
don't
need
to
to
do
here
because
it's
done
in
a
different
place.
That's
an
important
thing
to
do,
and
it's
probably
not
requiring
a
page
of
text
that
can
be
done
in
a
relatively
simple
way.
In
particular,
if
you
already
have
a
document,
you
can
point
to.
A
So
I
to
answer
that,
yes,
the
current
architecture
document
attempts
to
do
that
and
and
most
of
the
I'm
still
waiting
for
lou
to
turn
up,
because
he
had
a
couple
of
comments
around
that.
But
the
current
architecture
document
does
go
through
capabilities
of
of
lower
layers
that
can
be
reused
in
order
to
to
provide
this,
what
we
call
a
track.
A
A
What
I'm
hearing
pascal
suggest
and-
and
I
think
he's
making
a
lot
of
sense-
is
that
raw
and
net
as
well,
could
complete
all
their
work
and
complete
their
charter
and
have
fantastic
control,
plane
protocols
that
would
allow
these
end-to-end
paths
to
be
created,
but
from
an
application
perspective.
There
are
no
transports.
A
C
A
A
C
Yeah,
because
there
is
no
better
transport
right
and
that
net
is
kind
of
about
putting
in
the
network
things
which
are
normally
done
at
the
application
layer
as
well,
not
bonded
latency,
because
they
can't
but
at
least
adjusting
the
jitter
right,
the
jitter,
animation,
elimination,
buffer,
every
application,
which
does
some
some
streaming
has
to
have
them,
because
the
network
will
have
cheater.
Now,
if
you
have
a
net
network,
you
can
eliminate
that
function
from
all
applications
and
that's
the
benefit
of
doing
it
here.
Now
this
what
we
do
for
the
jitter.
C
We
are
not
doing
for
packetization
blocking
and
scheduling.
Basically,
for
you
know,
whatever
the
application
delivers,
so
the
application
still
has
to
do
it
and
and
well,
and
then
the
second
thing
is:
the
net
architecture
has
a
uni
interface,
which
is
not
specified.
We
say
it's
it's
the
architecture
knows
it,
but
right
now,
if
the
end
system
is
part
of
that
net,
then
you
don't
have
a
unif.
C
You
are
already
that
net
the
uni
would
be
inside
the
box,
and
so
now
I'm
talking
about
the
real
uni,
where
the
endpoint
would
not
necessarily
need
to
have
all
the
good
features
that
that
network
has
like
like
being
insane,
etc,
etc,
etc.
But
for
that
you
need
a
minimum
hint
over
the
you
and
I
for
for
the
transport
actually
to
deliver
the
packets
at
the
right
time,
so
yeah.
But
I
don't
want
to
yeah
discussion.
C
A
C
Transport
protocol
right
well,
in
theory-
it's
never
four
pages,
but
yes,
but
I
tried
because
I
wrote
that
draft
and
they
went
into
you
know.
Actually
some
of
the
functions
like
replication
elimination
could
should
be
considered
as
layer,
4,
supposedly
a3,
because
you
you
go
out
and
you
go
back
in
layer,
3
and
one
one
packet
goes
in
two
packets
goes
out,
go
out,
it's
hardly
a
layer,
three
thing
right:
normally
there
are
three:
it's
one
packet
and
one
packet
out
and.
A
C
Right,
but
but
in
the
middle
of
the
network,
when
you
do
replication
or
elimination,
you
need
to
cue
things
right,
elimination,
you
need
to
queue
ordering
it's.
These
are
not
three
function.
These
are
your
four
functions.
I
mean
that's
typically,
what
tcp
will
do
right
to
a
reorder
thing,
etc,
and,
and
so,
if
you
start
looking
at
the
architecture
and
and
you
know
you
forget-
you
know
the
history
of
that
net
little
bit,
you
would
figure
that
probably
the
architecture
should
have
been
going
all
the
way
to
layer.
Four
in
the
service
layer.
A
A
Do
you
think
there
is
value
for
the
working
group
to
draw
out
and
discuss
this
within
the
existing
architecture
document
or
some
other
draft
to
talk
about
this?
As
a
as
a
I
want
to
say
problem,
but
people
think
problem
statement,
but
as
a
kind
of
an
issues
document
is
sure
raw
can
do
all
the
work
it's
charted
to
do
and
we
can
solve
all
these
problems
in
beautiful,
elegant
ways
and
everyone
can
have
glorious
consensus
on
it,
but
without
a
transport
protocol
to
take
advantage
of
it,
it's
not
actually
ever
going
to
fly.
A
Is
there
value
in
us
suggesting
it
or
should
we
just
record
it
in
the
minutes
here
and
yeah
we've
got
we,
you
know,
we've
got
john
we've
got
cast
and
you
know
there's
there's
a
bunch
of
chairs
on
this
call:
hey
lou
is
here
great
and
and
between
us
we
can
sort
of
keep
it
in
our
heads
and
discuss
and
and
get
it
between
us.
That's
that's
my
question
to
the
room,
but
go
ahead.
Lou,
hello,.
F
Hey
sorry
about
being
late
yeah,
I
think
this
is
a
great
topic.
I'd
love
to
see
it
discussed.
I
I
think
it's
a
definitely
a
good
transport
issue,
and
you
know
it
it
could
be
bubbled
up
even
to
making
it
into
tcp,
where
tcp
is
aware
of
what
the
underlay
can
provide,
and
I
don't
I
think
it's
a
would
be
great
to
get
the
transport
area
to
talk
about
it.
I
don't
think
this
has
anything
specific
to
raw.
It's
a
general
net
problem.
F
You
know
it
doesn't
really
matter
if
you're
going
over
wireless
or
wired
the
having
your
transport
protocol
be
aware
of
what
is
under
underneath
is
would
be
hugely
valuable.
There
are
protocols
that
I've
seen
that
have
come
through
the
ietf
that
go
and
try
to
measure
the
available
bandwidth
or
measure
around
trip
time
and
then
adjust
themselves
to
those
parameters.
They're
self-adjusting
and
you
know
if
if
we
could
have
an
api
up
where
the
network
could
tell
the
application
protocol,
this
is
what
you
should
expect
and
sort
of.
F
This
is
where
you
should
self
tune.
That
would
be
great
and
I
I
actually
think
even
tcp
could
take
awareness
and
take
advantage
of
it.
Although
you
know
I
I'm
more.
I
think,
like
the
rtp
stuff
is
probably
a
better
place
to
be
thinking
but
or
even
something
new,
but
but
they
all
could
take
advantage
of
it.
A
So
so
I
absolutely
take
your
point
and
made
a
lot
of
sense,
though
lou,
I
think,
there's
a
difference
between
what
I'll
call
reactive
transport
protocols
where
they
they
discover
during
their
their
their
operation.
That,
oh,
I
you
know
the
sliding
window
is,
is
it
reacts
to
things
it
finds
explicit
congestion
notification
is
still
a
mechanism
to
which
the
transport
protocol
can
react.
As
I
understand
it,
pascal
is
saying
that
that
should
be
a
a
a
new
protocol
which
is
non-reactive
it.
A
It
is
told
at
connection
establishment,
if
whatever
that
means
that
something
has
pre
or
some
some
control
protocol
that
goes
alongside
the
transport
protocol
has
pre-agreed
that
this
path
that
you
will
use
will
have
these
characteristics.
Don't
bother,
don't
bother,
adjusting,
don't
react
because
it's
this
you've
been
told
it's
deterministically
this,
and
if
you
discover
it's,
not
there
then
drop
into
some
sort
of
abort
mode,
or
does
that
sound,
draconian
and
unwieldy?
No.
F
I
I
I
think,
we're
saying
very
similar
things.
The
only
difference
in
everything
you
said
there
is,
I
don't
think
we
need
a
new
transport
protocol.
I
agree
with
everything
that
pascal
said.
I
agree
with
what
you've
just
said.
A
new
transport
protocol
would
be
great,
but
I
don't
think
we
need
one.
I
think
we
could
dovetail
into
the
existing
ones,
but
a
new
one
is
also
good.
It's
it's
just
the
the
difference
is
it's.
C
C
Yeah-
and
that
comes
with
variations,
I
agree-
I
mean
one
variation:
is
you
know
the
application
doesn't
know,
but
just
push
his
bites
just
like
tcp,
and
then
we
will
block
them
until
the
period
or
the
application
is
aware
effectively,
and
we
send
him
the
we
send
the
application,
the
tick
and
then
the
application
gives
at
the
tick
whatever
it's
there.
So
there
are
variations,
but
my
point
is
basically
something
needs
to
emulate.
C
What
tsn
is
doing
in
all
those
shapers
and
it
can
be
effectively
it.
It
can
be
a
national
shaper
or
it
can
be
a
time-based
shaper,
and
this
these
are
the
abstractions
that
are
not
really
classical
to
to
the
current
transport.
So,
yes,
you
can
twist
and
turn
on
something
existing,
but
maybe
something
more
directly.
C
C
And
and
I've
seen
some
proxies
for
the
upper
layer
and
you
could
even
make
it
look
like
udp
for
the
lower
layer,
but
but
you
need
to
have
a
a
udp
on
steroid
in
the
middle
to
to
I
supposed
to
just
send
the
things
you
know:
block
the
datagrams
and
and
and
reorganize
them
in
the
industry.
But
it
could.
It
could
be
made
to
look
like
just
like
udp,
okay,.
A
I
I
have
a
left
field
suggestion
and
then
I'm
gonna,
let
john
speak
because
he's
been
very
politely
standing
in
the
queue.
Is
this
something
that
can
be
pushed
back
into
quick
because
it's
suddenly,
when
you
said
oh,
you
can
make
it
look
like
udp
on
on
the
wire
for
middle
boxes
and,
of
course,
quick.
Does
that
explicitly
to
to
work
around
middle
box
problems
quick
and
I'm
looking
at
others
on
this
call
to
tell
me
where
quick
has
got
to
with
its
explicit
congestion
notification
or
its
non-explicit
congestion
notification
mechanisms.
A
B
Yeah,
I
actually
wanted
to
respond
to
a
question
you
asked
earlier,
which
was
this
is
very
interesting.
Should
we
try
to
capture
it
in
our
documents,
and
I
thought
that
karsten
had
a
fairly
compelling
point,
which
was
if
you
think
that
your
architecture
needs.
You
know
certain
attributes
from
the
lower
or
upper
layers.
You
know
that
you
are
in
between.
In
order
to
be
useful.
B
C
C
B
B
C
I
picked
it
and
john
I
will
I
will.
I
will
act
on
that
that
was
already
checked
so
yeah
to
probably
publish
a
new
architecture
with
you
know,
dependency
on
the
upper
layer
and-
and
I
already
I
like
quick
sense-
discuss
a
lot
about
the
lower
layers
and
that
net
discusses
a
lot
about
the
lower
layers.
I
mean
that
net
tsm
this
is
discussed
at
length
we
inherit
from
that
net.
C
A
F
I
was
just
going
to
say
that,
rather
than
in
the
raw
architecture
document,
I
think
it.
This
is
worth
even
raising
the
visibility
more
and
make
it
its
own
document
and
make
it
a
net
document
because
it
applies
to
that
net.
Equally,
if
it's
in
the
raw
architecture,
it'll
be
buried
there
and
people
think,
oh,
I
only
care
about
this.
If
I'm
doing
wireless-
and
you
know-
I-
I
think-
that's
just
off
base-
you
always
care
about
it.
When
you
have
a
dead
net.
C
Yeah
well
yeah,
I
I
I
won't
be
working
on
that
show
instructor
right,
I'm
in
the
middle
of
a
big
piece
of
code.
Actually
stopping
is
hard
and
even
for
this
meeting.
That
was
but
but
that's
why
I
created
this
document
that
tsv,
because
for
me,
since
it
was
a
transport
project,
I
tried
to
document
it
to
tsbwg.
C
So
I
could.
I
could
republish
it
to
that
net,
but
maybe
it
was
too
much
on
the
solution
already
and
maybe
it
will
require
a
prime
statement.
First
yeah
I
mean
whatever
now
the
point
that
john
made
was.
If,
if
this
architecture
has
dependencies,
they
should
be
written,
I
can
have
two
sentences
and
say:
hey
it's
going
to
work.
If
you
know
the
input
fits
the
shapers,
there
is
an
ingress
shaper
somewhere,
and
the
input
must
fit
that
english
shaper.
I
don't.
A
C
C
A
A
F
A
Let
me
rephrase,
I
think,
the
right
place
to
to
s
to
create
a
a
transport
solution
which
either
interacts
with
with
tcp
or
sctp
or
whatever
or
is
a
whole
new
transport
protocol.
Yeah,
absolutely
that's
transport,
but
if
there
is
a
a
a
a
a
problem
statement
that
needs
to
be
clearly
defined
as
if
you
are
using
a
debt
net,
you
need
to
be
aware
of
these
issues.
A
Does
that
if,
if
we
take
the
existing
transport
draft
and
just
point
it
towards
or
introduce
it
to
debt
net,
will
that
help
to
to
trigger
the
the
generation
of
some
document
that
records
hey
upper
layers
to
work
well
with
debt
net?
You
need
to
understand
that
you're
on
a
debt
net
in
some
way
there
is
a.
There
is
a
a
gap
here
in
in
what
ietf
has
for
you
to
to
use.
F
F
I
I
believe
I
read
the
document,
but
I
frankly
don't
remember
it
at
all.
So
I
can't
remember
if
it's
written
as
a
requirements
document
or
as
a
solution
document,
so
a
solution
document
would
not
be
right
to
bring
entities.
A
tsb
working
group
solution
document
does
not
belong
in
debt,
correct
yeah.
If
the
answer
is
that,
then
you
know
your
answer
to
your
question
is
no.
If
the
answer,
if
the
answer
to
the
question,
what
is
this
document?
Is
this
a
requirements
document?
F
Then
the
answer
could
be
yes,
so
you
know,
I
can't
answer
the
specifics
without
looking
at
the
document,
but
in
principle
a
requirements
document
requirements
on
transport
protocols
or
it's
not
even
it's,
it
may
be
consideration,
I'm
not
sure
it's
even
requirements.
It's
just
you
know
hey.
If
transport
takes
advantage
of
these
things,
you
know
this
is
what
that
can
do
for
you.
That
seems
like
a
great
thing
to
do
and
dripping.net
and
maybe
make
it
a
debt
net
raw
document.
C
Having
written
it,
I
don't
remember
exactly
what
I
put
in
it,
so
I
can't
even
answer
I
I
do.
I
remember
there
were
two
parts.
One
of
them
was
really
layer.
Four
and
one
was
more
layer
two,
and
there
was.
I
think
my
goal
was
to
raise
attention
to
that
problem,
but
but
I
don't
know
to
which
detail
I
want,
I
think
it's
mostly
prime
statement
and
architecture.
B
C
B
Is
the
document
I
pasted
is
that
the
the
right
one
draft2bear
tsvwg.net
transport,
yeah?
Okay?
So
it's
it's
in
the
chat
and
I
mean
just
looking
at
your
table
of
contents
like
the
first
half
of
it
looks
yeah,
like
you
know,
sort
of
high
level
requirements,
problem,
statement,
etc,
but
then,
like
down
toward
the
end
of
it,
you've
got
things
like
you
know,
specific
messages,
so
it
looks
like
it
sort
of
slides
into
solution
by
the
end
of
the
document.
A
So
here's
how's
this
for
a
suggestion.
Why
don't
you
just
forward
a
link
to
that
document
to
the
det
net
mailing
list?
Saying
hey
everyone?
I
think
we
have
missed
some
considerations
for
the
use
of
debt
net
that
ought
to
be
drawn
out
here
is
an
here
is
an
old
document.
I
wrote
a
while
ago
the
first
half
might
be
a
suitable
starting
point
for
a
document
within.net,
the
second
half.
Definitely
a
transport
based
solution
and
see
what
the
reaction
is
within
the
group.
C
I
don't
think
that
not
missed
it
because
it
was
published
right.
So
it's
more
like
the
work.
The
priority
was
not
to
work
on
this,
and
so
that
networked
on
you
know
making
that
network
and
that
network
work.
But
now
maybe
it's
a
better
time
to
to
think
about
those
things
now
that
that
net
has
progressed,
that
much.
F
I
would
actually
be
perfectly
fine
with
taking
the
document
and
sending
it
to
that
net
and
then
saying
hey
parts
of
it
don't
belong
here
or
you
know,
pascal,
if
you
want
to.
If
you
want
to
look
at
it
and
strip
out
the
parts
that
you
don't
think
belong
go,
you
know,
jump
right
there,
but
either
way
it's
a
starting
point.
F
So
I
would,
I
would
say,
just
submit
it
and
if
you
want
to
send
the
mail
saying
you're
gonna
submit
it
on
when
the
doors
open
on
sunday
and
would
love
to
talk
five
minutes
in
the
session.
We'll
we'll
give
you
a
few
minutes
in
the
session.
I
think
we
have
time
you
know
if
you
want
to
give
like
a
literally
a
five
minute
intro
to
the
topic
and
then
get
attract
some
people
to
it.
F
C
Sadly,
I'm
not
flying
this
time.
Lou,
and
I
just
don't
remember
when
that
net
is,
I
think
it's
in
the
afternoon
and
it's
it's
a
long
week
and
and
I
I
won't
be
able
to
stay
out
of
sleep
for
five
days,
so
it
might
be
london
whatever
I
can
stand,
you
know
right
say:
oh
there
was
this
document
and
if
you
look
at
it
section
blah
blah
blah,
maybe
it's
worth
thinking
again
and
even
raised
kind
of
the
question
like
we
just
did
to
get
an
open
discussion
I'll
try
to
attend
that
net.
A
Pascal,
this
is
the
advantage
of
the
mailing
list.
I
think
you
can
just
send
it
now,
while
people
start
to
ramp
up
to
ietf
they're
starting
to
catch
up
with
the
mailing
list.
Thinking,
oh,
I
better
better
just
see
what's
happening
and
watching
it
a
bit
more.
Even
if
you
can't
attend
the
meeting,
I
think
that
might
trigger
the
discussion
and
someone
else
possibly
evil,
myself
or
or
whatever
could
could
raise
it
at
the
mic
to
say
by
the
way,
pascal
who,
unfortunately
can't
be
here
and
time
zones
etc.
A
C
A
That
that
would
be
fantastic.
Pascal,
thank
you
lou.
I
I
I
know
you
have
had
comments
on
the
list
and
some
verbal
comments
with
with
pascal
and
so
on.
At
the
various
atf's
we've
had
well,
we've
all
been
remote.
Do
you
want
to
raise
any
of
those
now,
because
the
architecture
document
is
so
nearly
ready?
A
A
If,
if
there
was
anything
where
you
weren't
particularly
happy
with
the
responses
or
pascal
wasn't
or
any
of
the
author
teams,
weren't
particularly
happy
with
with
understanding
the
comments
given,
we
are
now
talking
in
real
time.
I
think
that's
the
best
use
if
the
if
they
were
sort
of
yeah
sure
we
can
do
that.
It's
not
a
problem.
I
don't
think
because
I'm
watching
the
clock
here,
but
it's
those
ones
that
are
a
bit
contentious
given
we
we
are
in
real
time
communication.
It's
a
good
opportunity
just
to
chew
through
those.
F
F
So
I'm
looking
at
the
email
from
march
20th
that
I
sent
and
then
pascal,
if
you
can,
represent
your
responses,
maybe
that's
the
best
way
to
to
go
through
it,
so
the
the
first
one
was:
what
does
the
term
raw
refer
to
in
the
context
of
the
architecture?
Is
it
mechanisms?
Is
it
addition?
Is
it
extensions,
you
know?
F
Is
it
or
is
it
just
the
terminology
thing,
and
I
found
that
in
the
document
it
was
unclear
that
it
seemed
to
be
a
mix
of
something
completely
new
and
something
that's
evolutionary,
and
you
know
I
I
was
expecting
sort
of
a
evolutionary
and
you
know
it
builds
on
existing
things
and
and
gives
us
a
solution
set
and
that's
what
raw
is.
But
I
didn't
think
it
was
clear
in
the
document
that
was
point
number
one.
C
I
was
asking
you
if
evolutionary
is
a
prime
if
if
that
would
contradict
our
charter,
and
so
so
that's,
but
because
I
agree
with
you,
it
is
depends
on
what
we
define
by
evolution,
but
I
do
think
it's
it's
an
evolution.
It's
it's
a
yeah.
It's
an
addition
to
to
that
net.
So
is
it
bad
I
mean.
Do
we
have
a
problem?
Do
we
have
a
charter
issue?
If
we
talk
about
something
evolutionary.
A
C
And,
and
about
what
is
the
term
row,
I
have
an
answer
to
that.
I
didn't
see
anybody
react
to
my
answer
but
effectively,
depending
on
what
we
want
this
one
group
to
become.
Is
it?
Is
it
a
long-term
activity
like
like
that
net
itself,
or
is
it
a
one-shot
activity
about
the
psc,
because
this
architecture
is
really
about
the
ooda
loop
that
enables
the
psc
and.
A
If
so,
so
I'll,
because
I'm
watching
the
clock,
I
would
say
from
my
position-
it
is
about
more
than
it's
more
than
just
the
pse.
I
would
see
the
pse
is
almost
a
an
output
of
the
raw
working
group
to
say:
hey
here
is
a
pse
and
a
control
plane
to
to
make
that
pse
work.
The
architecture
document
is
should
be
looking
at
the
bigger
picture
to
say
you
know
we
need
an
uder
loop
because
things
change
and
therefore
we
must
react
to.
C
C
F
So
I
think
we're
mixing
solution
with
with
architecture,
and
I
I
agreed
very
much
with
what
rick
was
saying
a
moment
ago.
Is
you
know
solutions?
Pse
is
the
solution.
The
architecture
shouldn't
be
nailing
you
down
to
a
solution.
Ooda
loop
is
a
concept.
That's
equally
applicable.
The
wireless
pieces
are
not
covered
in
the
general
raw
architecture.
So
that's
sorry
that
net
architecture.
So
that's
what
the
raw
architecture,
in
my
opinion
is.
It
is
all
about,
and
it's
a
I
do.
F
A
So,
just
by
two
pennies
worth,
I
believe,
given
that
the
current
charter
is
pretty
explicit
about
working
on,
probably
the
perio
and
the
pse
solution
to
the
the
the
raw
problem
as
it
exists
at
the
moment,
the
problem
of
getting
determinism
over
wireless
links
and
uder
is
a
fairly
general
way
of
solving
the
fact
that
yeah
things
change.
So
we
need
to
react
to
the
change.
Uder
is
a
very
sensible
concept
to
use
that
and
yes,
it
is
applicable
in
many
other
places,
rather
than
just
raw
address.
A
I
think
we
may
charter
one
or
two
more
times
to
solve
the
problem,
for
you
know
the
pario,
pse
and
some
of
those
approaches
if
there
is
a
whole
new
way
to
solve
this
problem,
I
think
that
would
probably
result
in
a
different
working
group,
probably
the
same
attendees,
but
we
could
come
up
with
a
new,
exciting
acronym
and
approach
it.
Something
different
in
a
different
way.
F
C
F
A
Well,
we
were
scheduled
for
an
hour,
so
we
are
already
over
time
lou
when
it
comes
to
wordsmithing.
Can
I
ask
you
to
suggest
some
text
because
pascal
is
already
picking
up
actions
out
of
this,
and
I
know
he
has
co-authors,
but
could
we
take
it
to
the
list?
I'm
I'm
gonna
draw
a
line
in
the
sand
because
I'm
already
late
for
my
next
engagement
and
it's
quite
late
on
a
friday
for
those
of
us
in
europe
already.
Thank
you
very
much
for
your
attendance.
Everyone.
There
are
notes.
A
Please
go
through
and
check
to
see
whether
the
notes
in
hedge
doc
do
actually
match
your
recollection
of
what
what
we
have
discussed.
I
think
it
was
productive
if
slightly
unstructured
and
I
apologize
for
it
being
unstructured,
and
I
look
forward
to
seeing
as
many
of
you
in
person
as
I
can
at
ietf114
and
those
I
don't
see
I'll
either
speak
to
or
miss
you
deeply
and
hopefully
catch
you
in
the
next
one.
F
A
A
Not
a
problem
there
will
be,
hopefully
london
will
be
a
bit
easier
for
you,
pascal
otherwise.
Thank
you
very
much
for
your
attendance
guys
and
I
will
see
some
of
you
soon
and
some
of
you
later
on.
Thank
you
and
I'm
gonna
shut
the
meeting,
although
I
think
it
closes
itself.
I
don't
know
how
I
don't
know
how
we
close
it.
I
think
we
just
let
it
roll
for
a
bit,
I'm
just
gonna,
let
it
roll.