►
From YouTube: IETF108 TCPM 20200727 1300
Description
TCPM session at IETF108
2020/07/27 1300
A
So
I
again
to
the
second
slot
of
tcpm.
We
at
least
I
was
a
bit
surprised
by
the
way
the
first
meeting
is
ended.
I
didn't
know
that
there
would
be
no
warning.
Nonetheless,
I
think
we,
as
we
still
have
some
time
left
in
the
second
part
of
today's
meeting.
We
should
be
able
to
finish
some
of
the
discussions.
A
A
B
B
This
draft
is
actually
part
of
a
collection
of
drafts,
a
nine
in
total
and
there's
actually
others
that
are
being
worked
in
other
working
groups
for,
for
instance,
pc,
ep
syslog
and
others.
But
these
are
the
ones
that
the
netconf
working
group
are
working
on.
In
the
left
hand,
side
you
can
see
the
tcp
client
server
draft,
which
is
the
one
that
this
presentation
regards,
but
just
be
mindful
that
it's
a
part
just
part
of
a
larger
set
of
drafts.
Next
slide.
B
If
you
look
in
the
lower
left
hand,
corner
you'll
see
an
example,
https
client
stack
and
starting
at
the
bottom
of
that
you
see
the
tcp
client
grouping,
which
is
defined
in
the
in
in
the
draft
that
this
presentation
is
about
above
it
is
the
tls
client
grouping
which
provides
you
a
snippet
of
configuration
for
tls
clients.
Primarily,
you
know
what
is
the
tls
certificate
trust
anchor
certificate
to
use
to
authenticate
the
server
with,
and
if
a
tls
client
certificate
is
required
for
authenticating
yourself
to
the
server?
B
What
is
that
and
then
on
top
of
that
is
http
client
grouping
which,
for
instance,
might
be
http
basic
off
authentication
scheme
on
the
right
hand,
side
is
an
example
configuration
this
is
xml,
but
yang
models
can
be
encoded
in
any,
you
know
could
be
json
or
cbor
or
something
else
at
the
top.
You
see
the
snippet
of
tcp
client
configuration
and
below
that
is
tls
and
then
below.
That
is
http
next
slide.
Please.
B
This
draft
actually
defines
a
total
of
three
yang
modules
and
on
I
want
to
start
at
the
bottom.
The
two
primary
gang
modules
are
ietf,
tcp,
client
and
then
an
ietf
tcp
server.
Just
a
moment
ago
we
were
looking
at
the
iutf
tcp
client
and
in
particular,
if
you
look
inside
that
box,
it
says
tcp
client
grouping,
so
that
module
defines
a
grouping
and
actually
only
one
grouping
same
with
the
tcp
server
drafted.
It
only
sorry
module.
It
only
defines
one
grouping
both
of
those
groupings
use
a
grouping.
B
That's
defined
entire
inside
of
a
third
module.
The
itf
tcp
common
yang
module
that
grouping
that
they
both
use,
is
called
tcp
connection
grouping
and
that
connection
grouping,
the
only
thing
it
does.
It
doesn't
define
anything
except
use.
It
uses
the
tcp
common
grouping
and
then,
if
you
see
a
little
call
out
on
the
right
hand,
side
the
tcp
common
grouping,
all
it
does
is
define
keeper
lives.
B
B
B
Okay,
I'm
going
to
just
dig
into
the
client
and
server
groupings.
First,
the
client
at
the
top.
It
defines
basic
parameters.
Of
course
a
client
needs
to
know
what
is
the
ip
address
or
host
name
of
the
remote
system
it's
connecting
to
and
maybe
a
port.
If
it's
not,
you
know,
there's
not
a
default
defined.
B
5.,
4
and
4a
are
actually
identical
configuration,
but
they
differ
at
the
protocol
level,
so
they
need
to
be
called
out
in
case.
The
client
is
using
one
or
the
other,
it
needs
to
know
which
protocol
is
supposed
to
be
using.
Five
is
really
the
similar
to
four,
but
it
introduces
authentication
as
well
here.
The
actual
five
sox5
spec
defines
multiple
authentication
types.
B
Here
we
only
define
the
most
common
gss
api
and
username
password.
It
is
in
yang
terms
a
choice
and
other
case
statements
can
be
augmented
in
by
future
efforts.
So
by
no
means
is
the
finite
list
or
or
the
only
authentication
schemes
that
can
ever
be
supported,
and
each
of
these
authentic
authentication
schemes
are
again
constrained
by
a
feature
statement,
so
implementations
can
choose
as
to
whether
or
not
they
they
support
at
all
and
then
very
at
the
very
bottom.
B
B
That
was
previous
slide
next
slide.
Please
there
you
go
okay,
so
here's
another
example
of
tcp
client
really
much
the
same
as
the
previous
one,
but
now
it's
just
the
tcp
client,
not
having
tls
or
http
client
snippets
as
well,
and
this
configuration
also
shows
the
stocks
5
parameters
being
configured
as
well
as
keepa
lives.
So
it
just
kind
of
shows
you
how
it
all
comes
together,
the
snippet
of
configuration
and
that
which
it
enables
to
be
configured
next
slide.
B
Please
now
looking
at
tcp
server
grouping,
it's
actually
much
simpler
than
the
tcp
client
grouping
from
a
basic
parameters
perspective.
The
only
thing
to
configure
it
truly
is:
what
is
the
local
address
that
the
server
should
bind
to
and
optionally?
What
is
the
local
port
and
and
by
the
way,
it's
okay?
It
says
optional,
but
really
what's
happening
here
is
the
default
is
set
to
zero,
which
is
an
invalid
value
and
it
thereby
forces
any
implementing
application
to
have
to
set
the
default
to
another
value.
B
So,
for
instance,
when
the
http
draft
uses
the
tcp
server
grouping,
it
defaults
to
443
or
80,
and
and
and
and
then
that's
why
it
shows
the
local
port
is
being
optional
here,
but
in
practice
it's
it's
actually
set
to
a
value,
that's
application
specific
and
then
again
it
has
the
same
tcp
connection,
grouping
which
is
the
keep
alive
values.
And
since
it's
such
a
small
snippet
of
configuration,
I
was
able
to
fit
the
example
at
the
bottom
of
the
page
as
well.
B
Here
you
see
it
all
coming
together
and
and
how
a
tcp
server
could
be
configured
next
slide.
Actually
that
I
don't
know
if
there
is
the
next
slide.
Oh
there
we
go
yes
again,
so
we're
about
to
enter
a
dual
working
group
last
call-
and
hopefully
this
is
looks
interesting
to
work
group
and
there's
no
objections,
but
are
there
any.
A
At
the
moment
I
see
nobody
in
the
dq
in
the
queue
I
mean,
I'm
I'm
an
author,
so
I
have
to
be
careful
than
what
I'm
saying
here,
but
speaking
is
cheer.
If
there's
some
comments
on
that
document
as
a
please
speak
up,
as
you
can
see,
there's
probably
going
to
be
a
working
group
last
call
on
the
tcpm
list,
specifically
concerning
the
tcp
specific
parts
of
this
document,
because
clearly
there
are
some
tcp
specific
parts
in
there,
and
I've
also
mentioned
this
on
the
list.
A
B
A
Okay,
this
is
the
second
yang
related
talk
in
this
session,
in
this
case,
I'm
speaking
as
individual
contributor.
So
my
name
is
michael
sherf
and
I'm
submitting
this
tokyo
man,
together
with
michelle
and
maheshmash,
is
co-chairing
the
netconf
working
group
and
you've
already
seen.
There's
the
ongoing
work
on
a
tcp
model
that
looks
at
tcp
from
the
application
perspective
from
a
tcp,
client
and
server
perspective.
A
This
document
looks
at
the
tcp
stack
itself
and
with
that
I'd
like
to
move
to
the
next
slide,
we
had
in
tcbm
quite
a
bit
of
discussions
what
this
implies.
So
this
is
not
the
first
presentation
on
yang,
so
I
I'd
like
to
briefly
recap
the
situation
other.
First
of
all,
we
have
a
tcp
mip
that
is
widely
implemented
in
some
cases
directly
as
a
mip,
in
other
cases,
in
quite
a
number
of
operating
systems,
not
as
specified
in
the
mid,
but
it
is
a
very
close
modeling
in
specific
format.
A
So
the
map
is
widely
implemented.
We
do
have
other
needs
in
other
working
groups.
The
one
that
we
specifically
have
on
the
table
is
the
tcpao
configuration
in
idr,
which
basically
needs
a
yang
module
for
tcpao
configuration,
which
is
typically
something
that
happens
inside
the
tcp
stack
as
part
of
other
system
settings
for
the
tcp
stack,
and
this
obviously
raises
the
question
what
to
do
in
tcpm
about
that.
A
But
on
the
other
side
that
doesn't
try
to
boil
the
ocean,
because
there
have
been
concerns
on
that,
and
we've
listened
to
that.
So
if
you
can
move
on
the
next
slide,
please
so
version
06
of
the
model
now
includes
a
very
short
yang
module,
as
the
model
is
short
because
I
can
entirely
put
it
on
one
slide.
A
It
basically
contains
four
different
parts.
First,
it
contains
two
modeling
features
that
are
established
by
the
tcp
map.
It's
a
connection
list
and
stats,
and
the
stats
are
basically
a
variant
or
modeled
after
the
tcp
map
this
taking
into
account
some
feedback,
we
got
on
the
list,
for
example
on
the
length
of
the
counters,
which
need
to
be
updated,
so
that
alone
is
a
reason
to
think
about
the
tcp
map
by
the
way,
and
then
we
have
the
part
that
is
needed
in
the
idr
model.
A
That
is
mostly
tcpo
configuration
as
needed
in
the
stack.
So
you
can
see
on
this
slide
here
some
parameters
for
tcpao
configuration.
We
also
have
the
request
to
consider
md5,
even
it,
even
if
it's
obsoleted
I've
put
some
very
explicit
warning
signs
in
the
draft
that
md5
is
outdated
and
tcpo
should
be
used
instead.
A
A
A
We
have
the
part
that
is
needed
in
idr
on
the
tcpao
configuration
and
the
md5
configuration,
and
we
have
references
to
the
other
document,
basically
to
tie
together.
The
two
young
modules
and
that's
it
so
it's
a
relatively
short
document,
I
think
15
pages,
the
ammo
dual,
as
you
can
see,
is
very
short
that
doesn't
boil
the
ocean
and
at
least
based
on
the
feedback
that
I
got
so
far.
A
C
Okay,
I
first
of
all
thank
you
for
for
your
work
to
to
reduce
the
scope
of
this
draft.
I
mean
I
I
think,
as
you
said,
there
was
a
definite
concern
about
the
turning
to
a
giant
time
sink
and
by
shrinking
it
you'd
help
do
that
can
can
anyone
who,
who
like
objected
to
doing
this
work
before
maybe
share
with
the
group
if
they
feel
like
this,
the
problems
have
been
addressed.
C
A
There
is
a
dependency
at
the
moment
from
this
document
to
the
other
one,
but
I
mean,
of
course
this
is
an
early
document.
The
other
one
we've
seen
as
close
to
working
group
last
call
so
there's
no
dependency
in
the
reverse
direction,
so
the
netconf
document
does
not
depend
on
that.
One,
of
course,
as
part
of
the
working
group
discussions,
we
can
look
at
that
dependency
but,
as
I
said,
the
other
document
is
not
dependent
on
that
one.
Here:
okay,.
D
A
D
D
C
D
D
A
Yeah-
and
I
I'd
like
to
explain
as
a
first
of
all,
if
you
hum,
you
should
go
to
the
widget
on
the
left,
there
should
be
a
window
that
opens
for
humming,
and
I
also
have
to
record
for
the
minutes
that
as
a
chair,
I'm
not
allowed
to
hum,
even
though
I'm
presenting
this
as
an
individual
contributor.
So
I
will
not
hum
here
because
I'm
not
allowed
to
do
it's
a
little.
Yes,
it's
the
tap
on
the
left
hand,
side
you
have
to
click
there
and
yeah.
D
D
E
D
A
F
Janet
yeah,
I
just
looking
at
the
chat
screen.
I
think
people
are
still
quite
confused
about
what
to
do
so.
Your
test,
I
think,
was
excellent
in
that
it
proved
that
people
people
still
need
some
help
to
this.
You
might
want
to
make
sure
that
people
can
actually
hum
before
asking
for
it
again.
Okay,
maybe
because.
F
F
D
F
About
this,
I
think
the
main
thing
is
that
you
have
to
basically
say
the
question
and
say
the
hum
starts
now,
because
the
hum
is
only
for
25
seconds
or
30
seconds,
and
if
people
are
trying
to
locate
where
the
hum
is,
then
it
simply
doesn't
work
right,
but
yeah.
I
think
this
is
it's
useful,
at
least.
D
D
D
G
D
D
D
D
D
A
D
D
D
D
D
A
A
H
H
H
A
A
One
of
the
observations
is,
we
don't
have
the
multi-pass
tcp
implementers
community
in
today's
meeting,
and
this
makes
it
pretty
hard
for
us
to
make
any
call
on
that,
because
the
implementation
feedback
matters
a
lot.
I've
already
give
you
one
feedback,
so
I
think
ipr
is
something
that
you
need
to
sort
out
at
least
that's
my
personal
view
and
other
than
that.
What
typically
helps
a
lot
in
tcpm
is
implementations
beyond
prototypes.
H
H
D
G
And
this
page
shows
the
typical
use
cases
from
for
this
function.
As
we
all
know,
mptp
can
use
multiple,
subfloors
or
automation
during
one
session,
as
shown
in
the
future.
You
can
see
the
client
have
two
network
interface,
that
identified
by
ip1
and
ip2
and
on
the
server.
There
are
two
existing
network
in
the
interface
indicated
by
ip3
and
ip4,
when
server
tour
detailed
that
the
ppi
for
for
for
ip3
is
better
than
that
of
ip4.
G
G
G
G
And
turning
the
target,
the
type
network
interface
by
the
jslib
and
client
to
receive
requests
here,
we
are
select
one
sub
slow
connected
to
the
target
network
interface
for
for
data
for
data.
Switching
and
another
basic
flow
is
that,
as
server
decided
to
cancel
this
navigation,
he
will
send
a
request
to
client
to
cancel
previous
navigations.
G
Okay,
go
to
next
slide
to
support
this
function.
I
always
think
we
should
define
a
new
option
and
we
named
it
empty
navigation,
and
this
is
a
structure
for
this
option.
A
new
subtype
should
be
allocated
to
indicate
this
new
option
and
the
address
id
should
be
used
to
indicate
the
target
network
interface.
G
G
Dp,
that's
all
our
that's
all
our
design
for
this
function,
we
think
is,
is
useful
and
practical.
In
fact,
we
have
received
a
million
suggestions
from
the
mayoralists
from
yush,
from
chris
and
from
professor
olivia
thanks
a
lot
thanks
a
lot
for
next
step.
I
will
incorporate
the
suggestions
to
our
new
version
of
this
chart.
A
D
So
yeah,
my
personal
comment
is
yeah.
I
think
you
know
we
already
discussed
olivia
and
christoph
made
a
similar
comment,
but
I
think
mp
purio
is
too
simple
in,
but
no
we
don't
know
you
know.
What's
the
best
way
to
you
know,
add
new
features.
So
if
you
have
very
good
use
case
very
tangible
and
concrete
use
cases
that
will
be
very
beneficial
for
us
to
think
about.
Okay,
this
proposed
proposal
is
the
best.
You
know
idea
to
address
the
use
case,
and
so,
if
you
could,
you
know,
come
up
with.
G
A
I
Hello,
all
thanks
for
having
us
still
here.
I
will
talk
about
the
tcpao
test.
Pictures
background
is
that
I
tried
to
find
test
factors
for
the
tcpa
and
there
weren't
any
while
I
was
implementing
so
during
the
email
discussions.
It
was
noticed
that
maybe
a
draft
could
be
something
that
helps
here.
After
all,
the
tcpa
is
10
years
old
and
it
seems
that
there
aren't
that
many
implementations
out
there
either.
So
the
next
slide,
please.
I
So
here
we
provide
the
test
vectors
to
actually
validate
the
implementation.
So
so
we
have
all
the
keys
that
are
needed
and
based
on
the
rfc
and
then
also
have
tcp
headers
and
packets,
and
also
the
max
available
for
the
for
the
developer
to
check
if,
if
they
are
valid,
if
they
are
valid,
if
they
have
valid
implementation
and
something
is
still
pending,
so
the
ipv6
is
still
missing
and,
and
that
travels
are
variant
also,
but
that's
not
even
included
in
the
original
rfc.
I
I
I
I
I
Well,
I
guess
the
option
option
there
is
to
actually
have
the
equipment
and
the
software,
but
that's
pretty
heavy,
so
it
would
be
good
to
have
the
feedback
for
this
draft.
That's
one
way
and
of
course
the
hackathons
are
another
way
where
we
can
check
what
might
be
the
differences
between
the
implementations.
I
I
A
J
J
A
Thanks
yeah-
and
I
guess
I
mean
we
will
run
out
of
time,
but
I
think,
although
at
least
my
point
of
view
always
shares
in
individual
contributors
that
this
could
end
up
in
something
very
useful,
of
course
it
needs
more
work,
but
if
you
find
others
to
work
on
this,
that,
I
think
this
could
be
something
that's
really
useful.
So,
at
least
from
my
point
of
view,
I
encourage
you
to
further
work
on
this.
A
Okay,
and
with
that
we
are
through
the
agenda,
so
I
guess
we
will
get
locked
out
in
four
minutes
or
three
minutes
I'd
like
to
thank
all
presenters
for
this
experiment.
We,
I
think
all
of
us
learned
a
bit
more
about
meet
echo.
Nonetheless,
I
hope
it
was
okay.
You
will
definitely
have
to
think
about
the
humming,
and
that
is
something
that
probably
needs
further
thinking.
A
But
I'd
like
to
thank
all
the
presenters
and
all
speakers
for
contributing
to
this
tcpm
session.
We
don't
have
the
blue
sheets
this
time.
This
is
done
automatically,
but
I'd
like
to
think
again,
and
I
hope
that
we
can
see
again
soon
either
face
to
face,
or
maybe
in
another
online
edition
of
the
ietf.
So
thanks
a
lot
and
stay
safe.