►
From YouTube: IETF95-TSVWG-20160405-1400
Description
TSVWG meeting session at IETF95
2016/04/05 1400
A
B
B
B
We
now
have
a
note-taker
under
Jabba
scribe,
we're
always
looking
for
reviewers
40s
bwg
drops
and
we'll
be
calling
some
of
these
drafts
outs
to
the
go
through
the
meeting
today.
If
you're
thinking
about
authoring
something
that
you're
likely
working
group
to
look
up,
please
include
tsv
WG.
In
the
name
of
the
internet
draft
you
submit
and
we're
still
looking
for
a
working
group
culture
to
join
us
or
maybe
a
secretary
to
help
us.
B
B
So
this
is
a
session
where
we
have
still
no
artist
season
public,
but
we've
been
busy
in
the
background.
There's
three
IDs
now
in
RFC
le
to
cue
the
dtls
end
caps
off
press
CTP
and
it's
been
there
for
a
while.
It's
waiting
for
a
document
which
we
called
n
data
or
I
data.
This
document
we
presented
later
in
the
working
group
today
once
that's
with
the
ROC
editor,
the
and
cups
/
CTP
can
proceed.
B
We
have
a
nut,
behavioral
requirements
update.
This
is
now
with
the
RFC
editor
and
an
sctp
pass/fail
over,
which
is
currently
being
discussed
with
the
RSC
return
or
thurs
48.
To
finalize
that,
so
you
can
enter
the
RFC
atque.
So
as
a
working
group
we're
doing
quite
well,
we've
pushed
several
things
into
the
rst
I
took
you
next
IETF
will
be
able
to
report
being
published.
B
B
B
That's
good
thing
about
giving
a
status
update
that
says.
Lots
of
things
have
being
done
right.
I'll
talk
about
network
circuit
breakers
for
a
moment,
I
was
the
author
of
this
document.
Gambia
deters
it
came
a
working
group
document.
The
Shepherd
for
this
is
David.
The
draft
has
now
been
approved
by
the
iesg
when
the
slides
were
made
version.
B
14
incorporated
the
iesg
comments
if
you've
been
following
this
draft-
and
it's
useful
I
think
just
to
give
a
quick
heads
up
that
the
were
several
changes
to
the
structure
of
the
document,
as
well
as
a
small
changes
to
the
content
of
the
document,
because
the
structural
changes
creates
lots
of
deaths.
I'll
just
outline
those
along
with
the
major
change
that
occurred
in
section
before
requirement,
one
this
had
a
must
thin,
which,
during
the
iesg
discussion,
discussion
became
obvious
to
us
that
really.
B
This
must
was
only
remaining
due
to
an
editorial
problem
and
that
the
intention
here
was
to
describe
the
way
in
which
the
circuit,
where
control
channel
should
operate
in
what
was
then
requirement
16,
which
uses
the
language
of,
should
use
these
and
describes
the
places
where
control
feedback
needs
to
be
provided
in
a
way
that
cuts
the
circuit,
breaker
or
triggers
it.
This
change
has
been
incorporated.
B
It
will
send
to
the
list
by
David,
and
we
got
no
comments
to
say
that
we're
actually
making
a
mistake
in
implementing
this
change.
Any
fight
term
bothered
already
or
Bob's
going
to
a
club
had
already
commented
on
this,
and
we
had
amended
the
language
in
requirements
16.
We
just
failed
to
notice
the
languaging
requirement.
One
contradicted
that
in
requirement
16
Oh.
E
Crisco
yeah
I
haven't
looked
at
that
text,
I'm,
not
sure
that
English
when
it
fails
to
receive
measurement
reports
that
indicate
an
absence
of
congestion
if
their
parents
receive
them.
Howdy
didn't
know
that
they
indicated
absences
and
Justin
north.
These
are
blue
test.
Your
red
text,
blue
top
of
the
first
sentence
of
the
blue
thing.
B
B
There's
the
incredibly
complicated
nothing
between
which
requirements
were
which,
in
the
working
group
last
cold
version.
The
document
in
the
final
document
I'm
not
going
through
this,
but
you
read
it
on
the
slide
deck.
If
you
want
to
look
at
it,
the
next
steps
are
to
incorporate
all
comments
we've
received.
There
was
non
from
the
list,
there's
no
Bob's,
which
we
will
fix
and
Spencers
already
and
reviewed
all
the
other
ones
and
we're
happy
with
the
other
changes.
So
it's
going
to
be
submitted.
B
Curtis
taters
and
we
did
a
working
group-
must
call
the
version.
6
I'm
documents
now
progressed
in
a
number
of
small
steps
towards
something
which
has
completed
the
Shepherd
view
by
David
black.
All
current
edits
have
been
incorporated,
or
we
submitted
this
to
our
ad,
so
this
one
will
now
go
to
ITF
last
call
after
the
idea
review.
B
Okay,
she
never
publish
this
many
documents,
all
in
one
GRE
and
UDP
encapsulation
judge
talked
to
it.
Yeah
be
good,
because
that
was
said
me
talking
to
everything.
Have
a
other
mikael
gra
in
UDP
encapsulation
has
been
a
working
group
must
call
that
working
group
must
call
period
has
finished,
but
we
have
a
clause.
The
working
group
must
call
so
give
us
a
quick
update.
Yeah.
F
Just
click
update-
and
this
is
yeah
I,
said
Garcia
this
a
finished.
The
working
group
of
last
call
I
doing
in
this
earth.
Since
yokohama.
We
have
the
three
update
version
to
the
to
this
up
this
last
one
which
is
abortion.
You
live
in
during
the
three
update
that
we
really
thank
you
there's
a
David
and
the
goryeo
post
gave
us
a
lot
of
the
technical
comment
and
also
the
editorial
comment.
So
we
had
a
quite
a
amount
of
change.
I
can
change
among
those
changes
here.
F
To
summarize,
this
is
a
terminal
change,
try
to
a
language,
there's
a
quick
405
beats
and
also
we
have
some
other
structure
change
to
make
the
document
the
flow
as
a
better
to
to
read,
and
we
also
have
some
a
technical
changes.
That's
making
that
the
protocol
design
acceptable
or
precise,
based
on
the
daily
in
the
course
in
the
comments,
suggestion
and
I,
will
also
have
a
quite
Amanda
at
poirier
change
to
improve
the
readability.
So
that's
why
I
think
this
is
a
version.
F
B
F
B
F
B
So
I
also
did
a
bit
what
behind
the
scenes
and
I
believe
Elliot
leah
has
agreed
to
review
this
and
Martin
stream
Lee.
So
we
have
a
number
of
committed
reviewers
I'd
like
to
encourage
these
people
to
review
this
within
the
next
two
weeks
and
with
those
reviews
I
intend
to
close
the
working
group
last
call:
please
send
your
reviews
to
the
mailing
list,
so
people
can
see
them
and
then
and
then
we'll
discuss
how
to
get
this
forward.
Good.
B
So
the
final
bit
of
this
chair's
rapper
is
milestones
review.
We
have
a
number
of
milestones
which
we
have
no
marked
as
done.
The
yellow
milestones
are
still
pending,
but
we
hope
that
these
will
be
completed
very
soon.
The
Green
Mile
stuns
stand
good.
This
is
interesting
at
the
tsv
WG,
with
the
milestones
appear
to
reflect
the
progress
of
work
at
the
moment,
if
you're
a
nature
of
a
draft
on
this-
and
you
think
your
mouth
storm
is
going
to
be
to
be
extended,
please
contact
the
tsv
WG
chance.
B
Otherwise
we
are
happy
people
and
heads
up
last
part
of
this
presentation
is
to
note
that
one
ID
has
been
asking
for
working
group
adoption.
That's
the
draft
on
a
tour
to
eleven
mapping
to
this,
sir,
so
we
won't
be
doing
that
later
in
the
meeting.
So,
if
you
haven't
read
this
draft,
please
add
it
to
your
reading
list.
Please
have
a
look
at
it.
We'd
love
to
receive
comments
and
feedback.
B
G
G
So
this
is
the
status
we
have
version.
Five
of
the
document
out,
we
at
least
I
try
to
address
all
issues.
I
was
aware
of
I
added
a
description
of
stream
scheduling,
so
the
document
is
about
a
new
data
chunk
and
stream
schedulers,
and
this
new
data
chunk
allows
additional
schedulers,
so
the
scheduler
concept
is
new
and
I
have
put
into
figures
and
a
bit
of
text
to
explain
what
these
schedulers
are
about.
This
was
also
a
comment
raised
by
a
couple
of
people.
G
Reading
the
document
saying
we
don't
really
understand
what
you're
talking
about
so.
Can
you
have
some
explanation
of
that
and
arm
yeah?
So
up
to
that,
it
was
fine,
and
you
submitted
the
document
and
karen
who's
reading
the
document,
pretty
detailed,
has
already
given
some
comments
and
we
have
discussed
them
and
we'll
have
some
more
improvements
to
the
document
which
are
basically
cleanups,
so
Saturday
and
Sunday.
There
was
a
hackathon
and
we
use
that
to
actually
get
some
running
code.
We
started
with
some,
let's
say
existing
code.
G
He
must
he
can
do
it
in
a
way
that
it
blows
up
a
receiver.
He
could
do
it
with
the
old
stack
already,
but
we
want
to
put
in
the
sentence
saying:
if
you
do,
you
should
assign
the
TSN's
in
a
in
a
way
that
a
receiver
can
progress.
I
will
provide
as
an
example
of
where
method,
which
is
our
which
may
enjoy
us
that,
but
if
receiver
as
sender
can
do
otherwise,
we
haven't
done
the
statement
of
how
the
I-40
ascension
is
negotiated.
We
did
this
in
the
code
and
we
figured
out.
G
We
need
a
sentence
for
that.
We
need
text
that
the
I-40
SN
is
only
used
when
you
use
I
data.
If
you
use
novel
data
chance
to
use
forward
essentials-
and
we
have
an
API
issue
on
the
receiver
side,
which
wasn't
clear
and
I
think
what
we
want
to
do
is
we
keep
it
as
simple
as
possible
for
now
I'm,
not
allowing
an
arbitrary
flexibility,
but
to
arm
to
allow
that
functionality?
What
the
web
RTC
guards
needs-
and
this
keeps
things
as
simple
as
possible.
G
If
you
want
more,
you
can
edit
locally
it's
an
avi
issue
next
slide.
So
what's
to
do
address
Curren
comments
address
the
issues
we
had.
Most
of
them
are
editorial
shoot,
so
that
should
be
a
question
so
far,
what
one
or
two
weeks
to
address
see
of
possibly
SMS
comes
up
with
comments
before
or
during
the
working
group.
Mascot
questions.
A
B
With
Karen,
including
sign
of
currents,
comments,
and
then
the
next
question
will
be.
Is
anybody
going
to
read
this
and
could
provide
some
comments
on
it?
So
my
first
question
is:
oh,
could
you
please
put
your
hand
in
the
air
or
indicating
some
way
if
you've
read
this
or
a
recent
version
of
this
document.
B
B
B
G
I
So
I
am
again
and
marooned
from
a
range,
so
I
will
not
pretend
to
be
an
sctp
expert
I'm,
not
even
sure
what
is
this
protocol
that
Santa
curiam
pure
client
from
a
protocol
point
of
view,
because
diameter
is
running
over
sctp
and
also
from
an
approach
to
point
of
view,
because
we
need
to
to
use
it
for
in
different
environments.
So
next
night,
please
so
actually
in
the
current
version
of
the
sctp
years
back,
we
have
section
15th
at
least
a
number
of
recommended
values
for
setp
protocol
parameters,
and
this
list
is
commonly
used.
I
Yeah,
so
so
we
had,
this
discussion
may
be
internally
with
different
vendors,
for
maybe
now
two
years
so
I
suppose,
to
to
create
a
draft
and
to
submit
the
draft
into
to
have
a
clear
description
here
in
this
group.
So
the
word
proposed
here
is
to
update
the
specification
to
indicate
that
the
sag
delay
is
a
parameter
that
need
to
be
configured
and
we
or
slower,
given
the
recommended
value
that
is
already
in
the
spec
to
say
that
it
is,
it
should
be
200
millisecond.
I
So
why
the
widest
approach
it?
Because
if
you
update
you
will
not
obsolete
the
existing
one,
but
you
will
have
a
clear
int
for
the
implementer
for
the
implementers
to
know
that
the
recent
thing
new
and
this
kind
of
clarifications
cannot
be
seen
as
a
errata,
because
there
is
nothing
wrong,
except
that
the
the
table
in
the
section
15
is
not
up
to
date.
I
I
I
think
the
specification,
I
think
is
the
right
way
to
do
that,
just
to
clearly
indicate
that
it
is
some
things
that
need
to
be
configured
and
actually
we
are
clarifying
to
two
things
in
the
drafts:
things
that
you
have
a
set
of
parameters
that
need
to
be
configured
and
also
the
value
recommended
for
this
configure
parameters.
And
so
the
question
raised
in
tone
by
michael
was
that
is
there
something
that
need
to
be
merged
in
the
current
setp
updates?
A
draft.
I
I
B
G
Mycotoxin
I
think
this
address
is
an
editorial
on
RC,
4
e960.
It's
no
question
they
suggestion
I
made
is
that
we
are
working
on
a
document
collecting
all
the
editorial
things
we
need
to
improve
in
4960
and
we
can
include
that.
So
it's
it's
up
to
you.
If
you
want
to
get
that
included.
If
you
agree,
I'm
happy
to
take
this
in
how
that
document
will
progress,
we
will
see.
G
I
mean
I
will
ask
in
a
couple
of
minutes,
were
working
with
a
double
that
and
we
want
to
progress
that
so,
at
least
in
the
past
it
was
possible
for
an
operator
to
say
here:
let's
have
a
look,
we
have
4960
but
they're.
The
ITF
is
working
on
an
update.
It's
a
working
group
document.
The
issue
is
listed
there.
So,
yes,
it
is
something
it
worked
on
the
past
and
if
not,
you
can
also.
G
I
mean
if
you
really
as
an
operator,
need
to
talk
to
vendors
and
the
results
on
etsy
specification,
which
tells
you
which
parameters
must
be
configurable,
and
I
think
we
got
it
right
there.
But,
on
my
point
of
view,
it's
an
offer
too.
If
you
agree,
we
can
put
this
into
the
base
document
and
it
will
come
up
when
it
comes
up.
I
I
think
that,
as
I
said,
I
just
want
well
sure
that
we
will
have
something
soon
so
under
things
that
we
needed
means
in
few
months.
That
I
want
to
have
something
so
I,
don't
know
what
is
a
process
usually
to
update
4960
so
see
I,
don't
want
to
spend
three
years
on
trying
to
update
an
existing
protocol
and
so
on
so
I
don't
know
what
is
nearly.
C
B
Me
comment
on
the
process
and
see
if
Michaels
got
a
comment
to
my
committee,
and
the
intention
here
was
to
do
an
informational
document
that
we
publish
relatively
soon,
that
defines
the
exact
text
changes
to
be
made
to
49
16,
so
in
effect,
this
would
be
published
as
an
RFC
relatively
soon
as
soon
as
that
list
is
stable,
I
suggest
that
that
might
actually
be
in
the
same
sort
of
time
frame
is
publishing
any
other
document
in
the
idea.
It's
just
an
informational
document.
It
doesn't
have
to
go
through
a
huge
lot
of
extra
procedures.
B
To
get
that
published,
the
update
to
4960
is
a
little
bit
more
complicated.
This
is
a
document
that
people
rely
upon.
It's
a
fundamental
spec
here,
so
that
update
will
take
slightly
longer.
It
will
go
through
more
rigorous
review,
although
of
course
we
will
already
have
a
change
list,
because
we
have
the
informational
document.
That
process
will
take
longer
to
produce
the
new
replacement
for
4960,
and
it's
important
that,
when
we
think
about
this,
to
classify
whether
the
changes
we're
talking
about
here
are
corrections
and
amendments
based
on
experience
or
the
addition
of
new
features.
B
I
Just
just
just
on
this
point:
it's
actually
these
things
that
worm
is
the
fact
that
you
are
we're
going
to
rely
on
an
informational
RFC.
So
from
an
ITF
point
of
view,
it's
okay,
you
know
what
it
is
and
it
is
something
available
and
you
can
rely
on
when
you
have
a
discussion
with
a
vendor
is
different.
You
think
that,
just
as
for
for
the
time
being,
it
is
not
so
clear,
so
we
can
understand
that
it
is
something
that
may
not
be
in
a
very
good.
I
G
G
Is
that
so
you
said
you
want
something
soon
you
can
bring
to
the
vendors
I
have
no
problem
in.
If
someone
fights
an
errata
saying
there
is
a
missing
line
of
text
in
this
I'm,
not
sure
if
Randy
is
paying
attention
right
now,
but
if
I
would
be
the
guy
who
was
asked
if
it's
okay
at
all
I
would
say
yes,
so
then
you
have
an
approved
arata
of
an
existing
document
which
enough
to
go
to
a
vendor.
G
B
H
G
G
B
I
G
So
basically
we
have
a
couple
of
aratus,
not
that
many
fight
for
the
RFC
4960,
but
we
have
our
from
erickson
a
couple
of
issues
with
have
with
the
dock,
with
the
RFC
4960,
which
results
in
interrupt
problems.
So
we
decided
it's
might
be
good
to
collect
the
known
aratus
with
the
issues
which
have
been
reported
into
a
document,
so
the
status
is
on
that
we
have
the
second
version.
We
have
32
issues,
we
put
a
dealt
with
in
this
document
for
each
issue.
We
have
a
section.
G
It
says
this
is
the
old
text
IRC
4960.
This
is
the
proposed
new
texts
on
earth,
but
for
the
best
document-
and
these
are
the
reasons
for
the
change,
so
you
can
go
line
by
line
understand
what
will
be
the
changes
of
the
document
and
understand
what
the
changes
us.
So
this
will
be
once
the
best
RFC
has
been
published.
You
have
a
list
of
changes
and
why
they
are
there.
G
G
The
document
isn't
complete.
We
use
an
issue
tracker
on
github.
If
we
have
new
issues,
we
put
it
there
and
discuss
their
somehow
the
changes
so
that
you
have
some
history
arm
and
we
have
18
issues
to
go
arm
and
then
yeah
I'm
18
issues
we
know
are
now
offered.
Possibly
a
couple
of
them
are
coming
up.
I
think
maxim
had
one
additional
right
now.
B
This
is
something
you
did
right:
I
I
pulled
that
and
sent
you
an
email
saying
I
was
going
to
pull
it
from
the
github
and
just
put
it
on
the
slide.
Okay,
just
so
people
can
see
that
actually
they
can
pull
it
as
well.
This
this
is
not
a
closed
process.
You
can
look
at
what
these
lists
are
and
got
to
get.
Heaven
actually
find
all
the
little
tricky
bits
that
go
with
it.
Yes,
so
and
it's
nice
that
you
give
a
presentation.
G
You
didn't
see
okay,
so
we
can
go
through
this
list,
but
I
think
that
doesn't
make
any
sense,
because
some
of
them
are
pretty
easy
to
exchanges.
Some
of
them
are
required
to
a
deep
understanding
of
the
protocol
mechanisms
like
this
issue
with
action
be
of
table
to
Russell.
If
that's
the
subject,
that
means
you
really
have
to
think
about.
G
This
are
three
times
at
least
other
things
are
like
ICMP
feedback,
that
kind
of
stuff,
but
there's
also
something
like
in
like
remove
host
name
parameter,
which
is,
we
have
a
single
parameter
in
the
st
specification
which
hasn't
been
tested
in
an
interoperable
way
right
now.
So
when
we
have
in
mind
moving
from
proposed,
then
two
more
to
another
state,
we
have
to
remove
this,
so
this
is
the
stuff
we
will
deal
with
in
this
document.
B
B
The
question
working
group
adoption
comes
up
and
this
would
be
a
little
bit
of
a
shocker.
Had
we
not
mention
this
on
previous
and
working
group
meetings
and
previous
working
group
meetings.
We'd
also
asked
how
many
people
were
following
this
and
where
this
was
the
correct
process,
so
I'm
going
to
formally
call
a
working
group
adoption
for
this
document
at
this
meeting.
If
you
think
that
this
is
a
useful
thing
for
this
working
group
to
do
to
compile
this
list
of
arata,
the
process
is,
as
we
sketched
out
previously
in
TS
bwg
meetings.
B
B
B
G
G
What
is
the
status
of
this
draft?
It's
the
eighth
revision
of
a
document
in
this
working
group.
It's
actually
a
bit
longer,
it's
actually
a
bit
older
because
it
goes
back
to
a
time
where
we
had
behaved
working
group
and
we
have
it.
We
had
a
document
there
and
document
here
and
it
was
split
and
merge,
so
it
has
some
kind
of
history.
Well,
we
have
a
single
document
are
now
which
describes
how
a
net
implementation
for
sctp
should
look.
G
So
what
is
what
is
this
about?
Basically,
you
have
an
errant
nap,
so
you
can
change
on
a
packet,
the
IP
address
or
the
IP
address,
and
port
number
and
changing
the
IP
address,
and
the
port
number
has
a
problem
for
setp
in
case
of
multi-homing,
because
all
the
power
and
endpoint
is
a
list
of
IP
addresses
but
a
sink
and
has
only
a
single
port
number.
So
you
can't
change
the
port
number
independently
on
multiple
paths.
So
we
came.
C
G
A
way
of
doing
net
for
sctp,
which
means
we
don't
change
the
port
number
but
which
gives
you
almost
the
service
you
get
from
nap,
so
you
can
handle
two
nodes
behind
an
ad
talking
to
the
same
server.
Choosing
this
ensuring
the
same
local
port
number.
So
you
run
into
a
part
number
collision,
but
we
can
resolve
this.
We
do
this
by
a
simple
idea:
we
have
a
connect
and
Association
identifier
or
connection
identifier,
and
we
use
the
saw
spots.
The
short
part
at
the
part
number
sent
the
verification
tag
for
that.
G
This
gives
us
forty
six
bits
of
random
data,
which
is
good
enough.
It's
not
perfect.
We
deal
with
the
collision
case,
but
it
helps
in
almost
all
cases.
This
means
are
an
ad
box
does
not
need
to
change
the
packet,
the
sctp
packet.
It
can
change
the
IP
address,
so
the
IV
had
about
nothing
inside
the
acidity
back
and
it
needs
support
for
inside
the
net
box
and
in
the
end
point
so
we'll
both
have
to
do
something.
G
If
you
only
read
this
section,
we
have
a
lots
of
examples
of
message
flows
in
there.
We
will
keep
that
intertwine,
because
you
need
to
see
what
an
endpoint
sense,
how
it
influences
in
that
box
and
so
on.
The
other
point
was,
which
was
brought
up
in
an
earlier
IETF
meeting
in
a
discussion,
was
that
we
currently
use
only
ipv4
it.
We
give
concrete
examples
with
IP
addresses
in
the
document,
and
we
only
translate
before
addresses
to
be
for
addresses,
but
you
can
so.
G
This
is
not
there's
no
limitation
in
this
in
this
procedures
that
you
can't
do
v62
v6
translation
or
before
36
/
62
before
so
other
suggestion
was
to
it
is
especially
as
I
mention
that
you
can
do
be
62
before
translation,
or
vice
versa.
So
having
an
example
to
which
shows
this
should
be
added
or
can
be
down.
This
is
basically
what
needs
to
be
done.
Implementation
status,
I
think
the
middle
box
stuff
is
mostly
implemented
in
the
freebsd
net
stuff.
G
B
B
Personally
think
that
this
work
has
been
started
a
long
time
ago
it
starting
the
behaved
working
group
and
my
own
take
on
that
would
be
that
this
document
is
a
product
of
that
process.
That's
originated
a
while
ago,
and
we
should
continue
it.
If
people
want
to
comment
on
this,
please
feel
free
to
do
so,
but
please
do
it
within
the
working
group
now,
so
that
we
have
a
clear
consensus.
If
you
have
any
concerns
about
it,
wishing
a
not
document
at
this
time,
please
say.
B
G
G
G
So
this
is
about
a
UDP
encapsulation.
We
have
an
RFC
about
their
this
is
this
started
as
a
document
for
dealing
with
legacy
nets
which
don't
support
this
fancy
algorithm
we
described
in
the
other
document
on
the
one
hand,
side
and,
on
the
other
hand,
side
on
how
you
can
deal
with
sctp
implementations
are
when
you
don't
have
access
to
a
raw
socket,
so
you
can't
send
asset
V
packets.
G
So
these
were
the
two
reasons
to
simply
encapsulate
sctp
in
UDP
and
there's
an
RC
described
it's
obviously
69
51,
and
to
give
you
a
very
short
way
of
doing
this.
Is
that
when
you
want
to
encapsulate
a
packet
into
a
UDP,
an
STD
packet
into
a
UDP
packet,
you
basically
have
to
insert
the
UDP
source
and
destination
port
numbers.
So
that's
what
you
have
to
do
so
when
I
call
here
and
capsulate
what
I
call
here.
G
Encapsulation
behavior
means
whether
I
do
encapsulation
or
not,
so
I
can
send
it
over
UDP
or
natively,
and
if
I
encapsulate
I
must
know
my
own
part
number
and
the
destination
port
number,
so
an
sctp
stack
has
a
single
own
port
number.
That's
local
encapsulation
port
number.
That's
configured!
That's
not
the
problem!
So
when
I'm,
sending
a
packet
I
need
to
figure
out,
should
I
n
should
I,
send
it
over
UDP
or
natively
and
if
I
send
it
over
UDP.
What
is
the
destination
port
number?
G
That's
the
remote
encapsulation
point
and
that
RFC's
laid
out
in
a
way
that
it
just
learns
on
what
part
number
is
used
by
the
pier.
So
when
it
gets
my
window,
the
pier
sends
a
packet
that
source
port
number
can
be
translated
by
net
boxes
and
I
just
see.
Oh,
my
p
a--
uses
that
point.
So
whenever
I
send
a
packet
to
him,
I
used
that
part
number
and
that
can
change
over
time
and
the
sctp
said
we'll
just
adopt.
G
So
whenever
it
receives
a
packet,
it
verifies
that
it
really
belongs
to
the
Association,
and
if
that
check
is
performed,
it
updates
this
remote
encapsulation
port
and
it
can
also
turn
on
or
off
capsulation.
So
you
can
start
talking
and
kept
sedated
and
switch
over
to
native.
If
you
want
to
so
our
c69
51
states
that
you
must
do
this
update
of
the
behavior
after
first
when
you
receive
a
packet,
look
up
the
Association
and
once
you've
found
it
the
look
at
the
verification
tag
you
expect
and
ensure.
That
is
the
verification
tag
you
got.
G
Was
a
slide,
the
issue
and
the
issue
says
two
things
are:
are
missing:
one
is:
what
do
you
do
with
packets,
which
are
out
of
the
blue,
because
you
can't
check
you
don't
find
the
Association.
You
can't
do
this
check
and
the
other
question
is
what,
if
you
receive
a
packet
with
an
inner
chalk,
packets
with
any
chance,
have
the
verification
text
0.
So
you
can
find
the
Association,
but
you
can't
do
the
verification,
tech,
tech,
that's
not
mentioned
in
the
RFC.
G
So
that's
where
the
solution
comes
in,
which
is
proposed
here
and
for
all
of
the
loop
packets.
It's
very
simple!
So
if
you
get
a
packet
and
you
don't
find
the
Association,
we
call
this
out
of
the
blue,
and
if
you
have
to
send
response
packet,
then
you
just
reflect
the
behavior.
So
it
was
received
natively
you
answer,
natively,
it
was
received
and
capsulated
08
/
UDP.
You
respond
over
UDP
and
exchange
source
and
destination.
G
Node
simple
thing:
what's
not
that
simple
is
if
packets
come
in
with
the
inner
child,
then
you
have
the
verification
tag
of
zero,
but
you
find
an
association
and
nothing
is
mentioned
in
the
document.
What
you
have
to
do
is
you?
Don't
update
your
encapsulation
behavior
for
that
association.
So,
if
you're
running
natively,
you
keep
natively
if
you're
running
over
UDP,
don't
change
the
remote
encapsulation
port,
then
look
what
the
packet
you
received
this
if
it's
the
same
encapsidation
method.
G
So
if
you
are
currently
operating
natively
and
its
native
fine,
if
it's
UDP
encapsulated,
not
fine,
if
you're
running
over
UDP,
it's
natively,
not
fine,
if
you're
running
over
UDP
and
it
isn't
UDP,
but
it
has
a
different
point
number.
It's
also
not
fine,
and
if
it's
not
fine,
you
must
send
an
abort,
and
you
may
include
an
error
message
only
if
it's
fine,
it
doesn't
change
anything.
Then
you
sign
it
in
attack.
G
If
you
don't
do
this
and
attacker
might
be
able
to
take
over
your
association
because
he
only
has
to
own
the
same
IP
address,
but
he
doesn't
have
to
own
the
same
port
number
also.
So
if
you
have
a
userland
stack
on
that
note,
a
different
user
lands
deck
on
the
same
node
can
start
and
can
take
over
that
association.
So
that's
why
you
have
to
do
this.
The
stuff
done
right
and
it's
just
not
specified.
So
it's
not
wrong.
Morton!
It's
in
the
ROC
DRC
mrs.
this
edge
case.
G
There
is
a
limitation
and
the
limitation
is
if
a
node
sends
an
init
in
the
middle
of
an
association.
This
is
the
note
has
restarted,
so
he
wants
to
continue
an
association
but,
for
example,
crashed
in
the
middle
of
that
he
can't
change
his
UDP
encapsulation
behavior.
For
that,
but
that's
not
a
big
deal.
The
whole
idea
of
a
restart
is
to
continue
the
association
without
any
change.
So
it's
just
a
force
if
it
was
using
before
a
UDP
port
has
to
bind
to
the
same,
addressing
and
dusters.
So
that's
a
solution.
G
Here's
the
error
cause
it's
a
similar
behavior.
We
do
if
an
endpoint
restarts
with
a
new
IP
address.
We
are
also
don't
allow
this,
and
here
we
may
put
in
this
error,
cost
telling
this
was
the
old
encapsidation.
How
this
is
the
new
one,
so
yeah,
that's
why
you
get
aborted
and
there
is
a
maybe
cuz.
We
also
have
a
may
for
the
IP
address
and
it's
up
to
the
operator
to
decide
if
he
wants
to
be
open
and
say
what
the
problem
is:
it's
nice
for
debugging.
G
G
Okay,
so
yeah
this
is
correct,
but
doesn't
fit
actually
the
thing.
So
it
says
what
we
had
two
versions
of
slacks
yeah,
so
we
have
a
hybrid
here
yeah.
So
the
question
is
so
we
have
implemented
this
in
frequency.
We
have
some
some
experience.
The
whole
issue
came
up
while
we
had
some
people
running,
use
the
lens
tags
and
running
into
this
issue.
G
So
the
question
is
how
to
progress
this
this
stuff.
There
are
three
options:
harmony,
one
is
to
file
an
errata
on
the
existing
RFC
and
say
well,
here
is
a
missing
thing
and
here's
what
you
need
to
do
it
don't
think
we
can
get.
This
error
course
in
by
anuradha
because
of
the
inr
agency,
stuff,
Plan
B
would
be
well
the
reason.
B
G
G
G
G
B
G
G
B
That
was
a
question,
but
how
you
change
it
I
mean
the
first.
The
first
question
is:
who
who,
who
wants
to
do
this?
Is
this
a
thing
we
should
be
doing
in
the
working
group?
Should
we
be
implementing
this
update?
I?
Think
so,
and
I
would
be
willing
to
do
that.
You'd
be
willing
to
do
it
and
it
fixed
a
security
problem
and
which
probably
is
a
good
motivation
for
doing
the
work,
and
you
can
submit
an
individual
document.
We
will
then
need
people
to
have
read
that
document
before
we
can
talk
about
adoption.
Okay,.
H
B
B
B
So
the
first
question
I've
got
is,
as
anybody
read
the
diffserv
intercom
draft
recently
yeah
okay,
few
people.
Would
anybody
be
willing
to
read
the
latest
version
and
check
whether
this
appears
to
be
finished?
Fred?
Well,
oh,
you,
okay
thanks!
So
we
have
two
people
who
will
read
the
latest
version
and
see
if
this
is
complete
and
possibly
ready
for
publication.
If
you
want
to
pass
comments
on
it,
please
do
please
use
the
mailing
list
is
Gonzalez
here
you
be
next.
J
Okay,
thank
Gary
I've
been
asked
to
to
give
a
heads
up
on
on
the
Aquabot
that
is
actually
quite
relevant
to
to
the
armed
transport
area,
as
a
matter
of
fact
is
a
transport
book,
so
I
am
gonna,
basically,
no
summarize
a
bit
what
we're
going
to
discuss
their.
The
idea
is
not
to
run
the
buff
here,
as
you
can
imagine.
So
it's
just
like
you
know
so
that
you,
you
guys
know
if
you
want
to
go
on
on
thursday,
to
to
check
it
out
so
I
code.
J
Basically,
it's
above
sponsor,
bye,
bye
Spencer,
as
the
transport
ID
and
the
history
of
this
is
like.
As
you
know,
I
mean
we've
been
seen.
A
lot
of
an
encryption
on
the
internet
and
operators
are
seen
more
and
more
encrypted
traffic
on
the
networks.
On
this
several
reasons,
for
that
one
of
them
is
the
idea,
basically
not
moving
and
encouraging
people
to
increase
traffic
and
coming
up
with
protocols
that
use
encryption
by
default.
J
All
of
that,
but
they
sell
actually
know
many
other
reasons
a
out
there,
which
basically
the
end
result
is
like
people
are
seen
about
the
traffic
in
particular
mobile
operators.
They
tend
to
do
different
things
to
manage
traffic
on
their
radio
networks
and
some
of
those
techniques.
They
rely
on
actually
being
able
to
see
the
traffic.
So
when
a
lot
of
traffic
is
encrypted,
they
cannot
actually
do
all
those
things
that
they
do
for
operation
and
management.
So
you
know
the
GSMA
is
the
organization
of
you
know
the
mobile
operators?
J
The
IAB
reyna
works
up
with
them.
The
workshop
was
called
Manu
and
the
IAB
was
there.
Many
ITF
people
was
there,
but
anyway,
it
was
kind
of
like
you
know,
reduce
effort.
So
it
wasn't
like
an
IDF
white
thing
like
a
ba
fees
they're.
Basically,
it
was
interesting
for
the
operators
to
explain
what
they
do
because
many
times
it's
very
different.
What
you
can
see
on
a
3gpp
architecture,
for
example,
to
what
is
actually
deployed
and
even
to
what
is
actually
in
use.
J
So
that
was
interesting
for
for
people
to
understand
a
bit
better.
What
is
the
problem
and
I
know?
The
idea
is
basically
to
come
here
and
you
know
discuss
with
the
ideas
as
a
whole.
What
is
the
actual
problem
understand?
You
know
what
are
the
pain
points,
that
they
are
suffering
things
that
they
need
to
do
and
they
cannot-
and
you
know,
to
find
basically
ways
that
you
know
they.
J
They
allow
us
to
use
both
encryption
and,
at
the
same
time
they
can
do
what
what
they
need
to
do
with
their
with
their
networks.
As
you
can
see,
if
you
go
to
the
both
page,
this
is
a
non
working
group
forming
performing
both.
So
it
is
the
point
actually
is
not
to
create
an
awkward
boat
that
is
going
to
be
working
on
that
the
idea
is
to
understand
the
requirements,
understand
the
scenarios
and
once
we
do
that,
there
may
be
solutions
that
the
IPF
could
develop.
J
If
that
happens,
they
will
be
chartered
independently
on
on
this
buff.
One
of
the
reasons
I'm
presently
here
is
that
some
people
thought,
for
example,
that
beach
surf
could
be.
You
know
a
solution.
You
know
one
piece
of
the
solution
or
in
the
solution.
Space
included,
be
sure.
So
if
we
agreed
at
some
point
that
diffserv
was
actually
a
useful
thing
to
do,
and
we
need
to
define
that
we
would
obviously
come
to
the
right
working
group
and
do
it
there.
J
So,
as
you
see
it's
a
bit
of
you
know,
discussion
both
just
to
to
to
understand
basically
problem
space
instead
of
scope,
I
mean
a
very
night
I,
well
scope
effort,
and
then
we
will
take
it
from
there
actually,
depending
on
the
discussions,
the
the
understanding
we
get.
We
will,
you
know,
decide
how
to
how
to
follow.
It
could
be,
you
know,
chartering
work
in
different
groups,
it
could
be
actually
know,
maybe
using
existing
mechanisms,
and
that
remains
would
be
seen.
So
I
think
this
is
kind
of
like
enough
for
a
heads
up.
J
We
do
Asians
yeah,
that's
a
good
point.
Actually,
we
are
a
playa
plotting
everything
as
we
get
it,
so
you
can
actually
go
through
the
draft.
The
dis
life.
Actually,
the
agenda,
I
I,
would
suggest
that
you
know
before
doing
any
of
that,
you
go
on
face
the
man
new
report
from
the
IAB
and
really
just
to
understand.
You
know
what
happened
in
that
I
ap
work.
So
maybe
you
are
not
a
Mueller
with
that
and
she
basically
just
44
background
on
on
what
are
the
discussion
some
of
the
discussions?
J
Then
they
happen
there
as
a
matter
of
fact,
I
think
there
were
surprising
findings,
for
example,
I
mean
just
to
name.
One
I
mean
people
thought
that
you
know
on
the
radio
networks.
They
were
using
like
like
very
very
different
traffic
classes
and
that
wasn't
actually
true
for
real
deployment.
So
so
you
may
actually,
you
know,
find
a
few
surprises
there.
If
you
are
not
too
familiar
with
how
radio
networks
and
cellular
technologies
work
actually
so
so
my
suggestion
go,
there
read
the
report
and
then
have
a
look
at
the
different
drafts.
J
The
slides
and
if
you
are
interested,
please
come
on
Thursday
I'm
gonna
be
giving
the
same
heads
up
basically
on
the
TSB
area,
because
Spencer
told
me
that
I
mean
while,
while
we
will
have
overlap
in
India
Tandy's
here,
but
basically
no.
It's
interesting,
also
for
everyone
there
to
to
understand
that.