►
From YouTube: IETF-TAPS-20220517-1500
Description
TAPS meeting session at IETF
2022/05/17 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
C
C
B
C
F
G
A
A
Yes,
so
today,
in
terms
of
agenda,
I
think
we
mostly
had
wanted
to
talk
about
the
implementation
draft
and
we
did
get
a
few
comments,
but
I
was
thinking
maybe
before
we
do,
that
we
can
like
briefly
check
in
about
so
I
we
have
an
itf
meeting
coming
up,
but
we
just
had
a
tab
session
at
iatf
113
and
I
think
the
working
groups
sort
of
sense
of
how
often
we
should
have
these
at
an
ietf
meeting-
was
that
maybe
every
other
meeting.
A
F
A
Okay,
good
yeah,
I'm
not
aware
of
any
other
topics
other
than
our
usual
issues
and
prs.
So
why
don't
we
get
started
with
those?
Do
we
have
a
volunteer
to
drive
ours,
not
slides
github?
A
A
B
A
A
F
F
F
Just
for
people
to
look
at
the
scope,
it's
not
huge,
mainly
just
kind
of
cleaning
things
up
and
trying
to
clarify
bits,
I'm
in
general,
fine
with
it.
We
had
some
suggestions.
F
I
I
guess
for
going
ahead,
should
we
just
try
to
make
the
changes
we
think
are
appropriate?
Do
you
want
to
update
the
pull
request
based
on
that?
E
So,
as
the
author,
maybe
I
can
comment
of
the
pr
I
try
to
be
as
sort
of
conservative
as
possible
and
sort
of
make
a
very
minimal
pr
in
terms
of
scope
and
changes
and
in
order
to
sort
of
test
the
watches
whether
this
is
something
that
I
could
keep
doing.
I
realized
that
you
kind
of
it
was
on
the
agenda
that
you
wanted
to
wrap
this
up.
E
Maybe
during
this
entry
meeting,
I
apologize
for
not
having
had
more
time
to
sort
of
go
through
more
of
the
of
the
draft
but
yeah.
So
I
I
would
have
a
few
more
prs
along
these
lines
in,
in
my
queue
in
the
next
few
yeah,
let's
say
next
week
or
two.
E
If
you
want
to
wrap
this
up,
that
would
also
be
fine
by
me.
F
I
I
think
getting
the
prs
would
be
great
for
myself.
F
I
I
guess
you
know
like
for
things
like
this.
E
Oh,
I
can
definitely
sort
of
accept
your
your
comments
and
into
my
pr,
that's
totally
fine
by
me.
I
just
I
wasn't
sure
how
how
much
like
authority
I
can
assume
myself.
F
I
I
you
know,
suggest
stuff,
I
think
that's
great
ananias.
The
editors
will
merge
things
and
you
know
make
sure
it's
good,
but
I
think
the
changes,
the
type
of
things
you're
doing
are
all
good.
F
You
know
and
as
we
point
out
you
know
like
in
this
place,
we
want
to
make
sure
that
we
keep
the
spirit
of
the
api
that
it's
saying
like
you
know
it's
host
name
first,
but
I
think
it's
it's
just
wording,
details
and
making
sure
we
don't
lose
some
of
the
nuance,
but
please
yeah
continue
to
make
the
suggestions.
F
I
think
that
was
fine,
so
I
I
made
a
pr
of
that
change.
So,
let's,
let's
try
to
fix
this
one
up
and
merge
it
in
the
entire
connection.
Attempt
which
part
is
that.
F
A
H
F
Which
that
notifies
the
application
that
the
connection
as
a
whole
is
ready
to
use
so
yeah.
This
is
kind
of
similar
to
this
second
sentence
here,
which
is
fine.
We
could
also
say,
I
think
we
are
referring
to
a
connection
establishment
tree,
but.
F
F
All
right
and
then
we
have,
we
have
a
new
one
on
section,
4.1.
E
So
maybe
I
can
explain
real
quick,
please
please
do
I
noticed
that
in
the
happy
eyeballs
sense
racing
protocol
racing
is
basically
basically
means
that
near
simultaneous
connection,
establishment
attempts
where
you
basically
pick
the
connection
that
first
exceeds,
but
in
in
this
case
or
in
this
draft
racing,
is
defined
more
loosely
or
broader,
where
in
section
4.3
it
says
that
three
different
racing.
E
F
F
E
So
in
section
so
where
it
says
section
4.1.1.3
right
there,
so,
yes
yeah,
it
says
implementation
that
support
racing
protocols
and
protocol
options
should
maintain
a
history
and
so
on.
This
information
can
influence
further
racing
decisions
to
prioritize
or
prune
branches
and
from
coming
from
a
happy
eyeball
perspective,
it's
sort
of
unclear
what
a
racing
decision
is,
because
the
race
is
it's
sort
of
understood
in
this.
E
In
this
metaphor,
of
like
a
race
among
equals
that
all
start
at
the
same
time
and
someone's
someone
is
coming
in
first
and
they
won
the
race
and
only
later
is
then
this
racing
term
cast
more
loosely
or
defined
more
loosely,
where
we
have
the
simultaneous
staggered
and
failover
kinds
of
racing,
and
it's
just
a
bit
confusing
that
these.
E
We
are
obviously
talking
about
racing
when
we
do
mean
failover
before
actually
having
introduced
racing
to
also
mean
failover.
F
C
F
F
Oh,
but
I
actually
consider
that
to
be
staggered,
just
like
normal
happy
eyeballs.
C
E
All
right,
so
so
this
this
section
then
implies
a
staggered.
D
H
D
The
reason
why
I
think
it
doesn't
really
need
much
of
a
clarification
is
that
I
mean
I
looked
at
the
draft
and
it
somewhere
points
back
at
the
architecture
draft,
where
we
have
a
pretty
clear
definition
of
what
this
is.
It
even
says
we
refer
to
this
process
as
raising
borrowing
terminology
from
happy,
eyeballs
and
dynamic.
Then
it
explains
how
this
could
operate.
D
F
Although
you
know
what
I'm
wondering
so,
the
reason
for
section
4
is
structured.
The
way
it
is.
Is
it
kind
of
does
things
in
order?
It
says.
First,
you
build
your
tree,
then
you
kind
of
gather
the
candidates
for
each
layer.
Then
you
race
them
like
it's
kind
of
the
order
of
operations,
and
then
you
complete
the
establishment.
F
So
to
that
end,
it's
nice
to
have
them
in
this
order
and
you're
right
that
we
do
talk
about
section
4.2.2
of
the
architecture,
but
what
we
don't
have
is,
in
the
section
4
a
forward
reference
to
the
candidate
gathering
section,
the
candidate
raising
section
and
the
completed
establishment.
So
we
should
probably,
in
this
paragraph,
have
more
references
to
the
rest
of
the
document
and
maybe
mention
here
that
the
kind
of
default
style
of
racing
is
staggered
just
to
get
that
in
people's
head
right.
E
From
my
perspective,
it
was
simply-
I
maybe
took
the
racing
metaphor
too,
literally
and
sort
of
thought.
Okay,
we
start
the
race
more
or
less
simultaneously
and
way
too
comes
in
first,
but
from
from
this
right,
like
tabs
perspective,
it's
just
a
perspective
on
at
the
at
the
finish
line,
so
to
speak
and
whatever,
whichever
comes
in
first,
has
won
the
race
and
not
actually
talking
about
sort
of
starting
in
any
fair
way
or
something.
Yes,.
F
F
F
That
all
of
the
issues
are
assigned
to
someone,
I
think
some
of
the
older
ones
still
need
to
be
done.
Reece.
What
would
you
like
to
do?
Do
we
want
to
go
through
these
issues,
some
of
which
we've
looked
at
before
I
I
mean
I,
I
know
you
know
we
just
need
to
do
them.
Do
we
want
to
look
at
some
of
the
other
pull
requests
that
are
open.
A
Yeah,
maybe
let's
look
at
pull
requests.
A
A
D
J
I
I
think
the
reason
that
people
wanted
it
for
quick
was
because,
like
h3,
has
specific
semantics
about
the
meanings
of
particular
stream
ids
and
the
one
sctp.
J
Multi-Streaming
article
that
I
have
experience
with
is
ipfix,
which
also
has
specific
semantics
for
stream
ids,
so,
like
both
of
the
users
of
these
protocols,
actually
do
want,
in
certain
cases,
to
be
able
to
to
say
explicitly
use
this
stream
id
yeah
so
like.
So,
if
we
want
to
allow
those
protocols
to
be
implemented
with
apps,
which
I
think
we
probably
do-
or
at
least
we
don't
want
to
specifically
forbid
it,
then
we
would
need
something
like
this.
J
I
I
my
comment
here
is
a
little
bit
cheeky
like
I
I'm
basically
saying
look.
We
have
two
examples
of
stream
multi-streaming
protocols.
They
both
use
integer
stream
ids.
J
I
could
imagine
like
esoteric
protocols
trying
to
use
something
other
than
an
integer
stream
id,
but
it
would
be
like
a
chunk
of
bytes,
which
you
could
just
use
an
arbitrary
length
integer
for
it
like
we
don't
say
what
the
length
of
the
energy
is
in
the
api,
so
the
I
think
there
are
two
objections
to
doing
this.
One
is
we
are
assuming
enter
semantics
for
stream
ids,
I'm
kind
of
okay
with
that
right.
J
J
The
other
objection
to
it
is
that
we're
basically
now
have
two
ways
to
specify
that
you're
multi-streaming
and
like
one
is
our
connections
and
the
connection
group
thing,
and
then
we
just
sort
of
like
poked
the
stream
id
through
this,
and
I'm
I'm
not
sure
what
that
means
right
like
so
what
happens?
If
I
create
a
bunch
of
connections
in
a
connection
group,
the
tap
system
figures
out,
they're,
going
to
bunch
them
together
into
a
multi-streaming
connection,
and
then
I
do
a
thing
with
a
stream
id
like.
J
K
J
You
could
also
say
that
if
you
specify
a
stream
id
for
any
cloned
connection,
you
must
specify
a
stream
id
for
all
of
them
right,
because
that's
that's
what
you're
going
to
do
like
if
you're
ever
going
to
do
it
you're,
never
the
application
will
either
say
I
care
about
stream
ids
and
I'm
going
to
allocate
them
myself
or
I
don't
actually
care
about
the
underlying
transport
at
all.
Give
me
something
that
works,
but
it
won't
say
both
or
if
it.
D
J
D
C
C
So,
but
how?
How
do
we
access
this
stream
number
now
is
the
other.
J
J
And
we
give
you
the
ability
to
do
that
right,
I
mean
in
the
selection
properties
we
can
select
on
multi-streaming.
Can
we
not?
We
could
at
one
point.
C
J
J
Which
means
so
what
we
would
need
to
do
in
this
case
is
we'd
also
need
initiate
to
take
a
stream
id
as
well,
because
you
might
need
to
say
which
stream.
Oh
man,
yeah.
C
A
C
We
really
can
and
then
you
can
explicitly
say:
okay,
I
got
a
ctp,
let's
use
sctv.stream
id
and
have
the
screen
rdf
stp,
because
I
have
no
idea
whether
I
prefix
overweight
will
be
defined,
but
I'm
not
sure
whether
I
fix
over
quick
would
have
the
same
semantics
for
the
stream
ids
as
it
srt
fix
over
sctp
has.
J
F
F
F
D
D
D
K
D
F
F
D
D
G
We
can
talk
about
that.
If
you
like,
can
you.
G
F
G
Okay
good,
so
this
is
actually
an
old
issue
which
has
been
open
for
quite
a
while
about
multicast,
and
they
made
a
pr
to
try
and
sketch
out
what
a
simple
answer
here.
G
The
the
way
multicast
is
currently
done
is
that
it's
a
little
odd
in
that
it
uses
the
local
end
point
to
specify
the
multicast
group
in
some
cases,
and
it
doesn't,
there
didn't,
seem
to
be
a
way
of
specifying
the
local
interface
by
which
you,
which
you're
using
to
join
that
group-
and
it
was
a
bit
weird
in
that
there
wasn't
any
way
of
rendezvousing
to
say
that
you
can
have
one
connection
that
can
both
send
and
receive
to
the
group.
G
G
And
then
you
can
listen
on
that
or
send
to
that,
and
they
they
do
the
obvious
thing
for
a
receive
only
or
a
send.
Only
multicast
group
which
matches
nicely
with
an
ssm
session
or
you
could
rendezvous
on
it,
and
the
idea
was
that
would
give
you
an
asm
group
which
you
could
both
send
to
and
you
would
be
joined.
You
would
receive
the
packets,
and
I
thought
that
worked
out.
G
Okay
until
I
tried
to
put
in
how
we
handle
source
filtering
and
then
we
you
run
into
sort
of
a
bit
of
an
odd
case
and
that
we
don't
really
have
enough
addresses
because
you
you
need
the
local
address
which
you're
bound
to
you
need
the
address
that
people
are
sending
from
and
you
need
the
group
address
somewhere
and
we've
only
got
local
and
remote
addresses
in
the
protocol
and
so
for
the
way
it
ended.
G
So
I'm
not
sure
it
works
out
any
better
than
what
was
in
there
before.
But
it's
got
a
different
set
of
problems,
at
least
what's.
C
So
one
suggestion
has
one
idea:
we
have
so
many
with
specification
for
the
remote
and
local
endpoint.
Why
do
we
not
explicitly
are
for
ask
for
the
remote
endpoint
having
with
multicast
group
and
then
adding
the
group
id
as
an
explicit
parameter
to
the
remote
object?
Then
we
could
be
really
safe,
that
we
can
do
both
source
filtering
and.
G
Yeah,
I
mean,
I
think,
that's
probably
the
right
solution
is
to
have
a
you
know,
because
I
mean
you've
got
a
third
address
now
when
there's
a
group-
and
it's
defined
it's
just
to
add
that
in
explicitly-
and
that
was
a
bigger
change
than
I
had
time
to
make
just
before
this
meeting,
because
you'll
notice,
this
pr
was
submitted
about
two
minutes
before
the
meeting
started,
but
I
think
that's
probably
the
right
answer.
Although
it's
a
pretty
big
change
to
the
way
multicast
works.
G
G
G
C
G
C
You
can
do
both,
you
can
say
remote
with
group
remote
with
multicast
group
and
it's
the
group
you
want
to
listen
to.
And
if
you
want
to
first
restrict
that
you
could
also
say
with
address
and
then
the
address
of
the
person
sending
also
for
listening,
sure
sure.
G
Sure
that
that
I
think
is
clear
but
let's
say
I'm
joining
an
asm
group,
and
I
I
specify
in
my
pre-connection
that
my
local
is
my
wi-fi
interface
say
on
whatever
port
the
remote
is
the
multicast
group
and
whatever
port,
and
I
want
packets
from
anyone
sending
to
that
group,
and
I
think
we
can
specify
that
as
a
pre-connection
easily.
G
G
F
G
C
Yeah,
oh,
would
you
just
say
that
the
multicast
group
is
always
a
special
thing,
and
so
you
have.
The
multicast
group
is
a
special
thing
on
the
remote,
no
matter
whatever
you
do,
and
so
you
get
away
with
this
kind
of
dualism.
C
C
F
B
A
Sorry
I
I
was
just
gonna
confirm.
We
also
have
some
more
comments
in
the
queue
from
torben
right
and
then
we
also
had
asked
christian
amzus
for
a
review
or
he
actually
volunteered
to
review
at
the
last
ietf
meeting.
But
I
haven't
seen
his
review
yet,
but
I
pinged
him.
I
haven't
gotten
a
reply
yet
so
there
is
also
one
outstanding
review
coming
there.
Hopefully.
H
F
J
I
think
all
the
ones
that
I
created
have
been
handled
now,
I
think
so
yeah,
I'm
not
seeing
any
open
ones
with
my
name
on
them.
B
J
J
K
F
K
J
J
A
A
H
F
J
A
Briefly,
talk
to
talk
about
sort
of
timelines
for
what
we
are
about
to
do
so
we
we
are
still
waiting
on
comments
and
or
reviews
which
might
take
a
couple
weeks.
I'm
not
sure.
Maybe
we
want
to
do
an
interim
meeting
sometime
in
june.
However,
my
june
doesn't
look
so
great
for
meetings,
but
maybe.
A
It
doesn't
look
like
your
audio,
is
it
doesn't.
L
A
A
J
L
Oh
yeah
yeah,
I
don't
know,
I
think
I
was
logged
in
at
home
because
I
came
home
when
it
worked.
I
couldn't
log
into
the
data
tracker
at
all
at
work.
J
I
A
Up
for
for
the
meeting
today
so.