►
From YouTube: Service APIs Meeting (EMEA Friendly Time) 20200514
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
The
things
that
probably
fit
there
most
are
still
kind
of
in
early
stages
in
gateway
in
general.
The
the
examples
that
we
kind
of
came
up
with,
where
traffic
splitting
definitely
seems
like
something
you'd
wanted
its
PCP
route
and
session
affinity
can
also
be
a
good
thing,
like
as
more
of
the
gateway,
ish
type
concepts
from
from
service
move
up
to
gateway
and
two
routes.
B
Those
things
seem
like
they'd,
naturally
fit
on
a
TCP
route,
but
unless
you're
configuring
those
things,
a
TCP
route
would
essentially
be
a
kind
of
dummy
placeholder
that
a
user
would
need
to
create
without
without
really
any
value
right
like
the
the
exposed.
Ports
are
basically
defined
on
your
service
already,
and
if
you
have
to
create
a
listener.
B
You're,
you
you're,
basically
mapping
a
listener
to
a
service
port
when
you
want
to,
you
know,
define
your
load
balancer.
So
what
value
does
a
TCP
root
actually
add
and
then
taking
that
a
step?
Further,
a
service
kind
of
essentially
becomes
a
it's.
It's
just
part
of
the
routing
chain.
It's
the
terminal
link,
but
you
know,
if
you
think
about
like
the
routing
chain,
is
gateway
to
a
CP
route
to
service.
B
Now
this
kind
of
makes
a
question
of.
Does
this
mean
that
a
route
selector
needs
to
match
all
resource
types
or
at
least
multiple
resource
types,
and
it
needs
to
be
context
aware,
like
sometimes
it
matches,
HTTP
wrote.
Sometimes
it's
not
just
service.
Even
if
we
went
TCP
UDP
route,
we'd
have
to
match
that
as
well.
B
D
D
This
is
a
route
of
type
service
and
then
just
use
the
same
mechanics
with
a
label
selector,
and
then
the
important
distinction
between
what
I
previously
been
doing
with
service
routes
is
that
we
still
require
the
listener
definitions,
because
Jeremy
convinced
me
that
that's
useful,
even
with
the
service
being
the
terminal
and
only
member
of
the
route
chain,
because
you
may
only
want
to
expose
specific
ports
on
the
service
via
the
load
balancer.
So
the
listeners
are
what
define
what
ports
to
expose
and.
C
Yeah
I
was
gonna:
ask
given
the
previous
proposal,
where
we
kind
of
wanted
to
make
the
common
config
like
super
tiny
in
terms
of
defaulting
or
where
you
guys
were
going
that
but
I
think
that
answer
is
my
question.
One
thing
that
would
be
good
is
to
work
out
if
people
can
write
really
strange
configurations
based
off
of
this,
and
if
we
can
very
clearly
define
how
those
would
be
handled.
D
Well,
this
is
specifically
to
handle
this
configuration.
This
is
this
is
acknowledging
that
we're
in
a
position
with
routes
and
route
composability.
That
is
not
exactly
clear.
There
has
been
a
preference
towards
API
or
as
UX
with
HTTP
route,
and
we
actually
raised
the
question
later
on
if
routes
are
actually
intended
to
be
truly
composable,
and
so
this
is
saying
well
like
HTTP
route,
it
can
be
a
composite
right.
It
doesn't
require
the
other
routes.
D
So
this
is
how
do
you
introduce
l4
at
the
MVP,
though
the
lowest
are
the
fewest
possible
changes,
and
this
introduces
l4
to
the
service
API
project
in
a
way
that
any
controller
is
reconciling
gateways.
Could
support
forever
right,
because
in
the
note
about,
if
you
scroll
down
Jeremy
I,
think
there's
a
note
about
the
endpoint
slices.
No,
no
I!
Guess
it's
up!
Yeah!
It's
oh
yeah!
D
The
endpoint
slices
so
Jeremy
pointed
out
that
the
reason
that
we
deemed
TCP
route
and
UDP
route
unnecessary
for
basic
support
today
is
that
while
services
and
endpoints
already
provide
all
the
information-
and
while
I
pointed
Jeremy,
had
always
viewed
that
the
the
target
of
a
route
would
be
service
and
not
endpoints
and
I
thought
well,
why
wouldn't
it
be
in
points?
I
said
you
don't
really
need
the
service
and
he
said,
but
within
point
slices
you
do,
and
so,
since
we
know
service
is
going
to
be
around
for
a
while.
D
E
C
This
is
an
interesting
proposal.
One
sort
of
question
would
be
like:
can
we
precisely
define
what
everything
you
could
a
user
could
write
ends
up,
meaning
we
a
lot
of
these
api's?
Have
some
strange
corners
like
with
something
be
ambiguous
in
terms
of
just
working
through
the
consequences
of
setting
it
up
like
this
I
think
some
of
that.
C
Definitely
intent
is
to
have
a
class
of
type
that
you
can
go
to
next.
What
I
mean
more
is
that
let's
say
we
do
this,
make
sure
that
we
can
work
through
all
the
possible
different
configs
that
the
user
can
generate
and
check
that
we
have
a
deterministic
sort
of
meaning
for
them,
or
they
will
be
invalid,
like.
D
There
is
a
section
on
error
handling,
for
example,
like
duplicate,
poor
errors
yeah.
So
this
would
support
multiple
services
as
service
routes,
and
it
documents
that
if
there
is
a
dupe,
if
a
route
matches
multiple
services
and
two
of
those
services,
both
that
define
port
HTTP
at
port
80
or
the
same
name
or
st.
port,
then
that
would
be
an
error
on
that
listener
and
saying:
hey,
nope,
sorry,
duplicate
port
right.
So
there
is
the
there
is
the
possibility
of
introducing
error
States,
but
that's
what
would
be
reported
as
part
of
the
listener.
Styles
right.
B
And
then
that
raises
a
good
question
like
so
that
that
is,
that
is
also
potentially
a
realistic
scenario
that
you
actually
want
right
with
traffic
splitting,
so
you
actually
want
to
match
to
services,
but
that's
where
you'd
probably
need
something
like
a
TCP
route.
That's
that
provides
additional
configuration
because
you
probably
don't
want
you
know:
random
5050
selection.
C
Right
yeah,
so
the
questions
that
come
to
my
mind
are
and
I'm
not
saying
that
you
don't
have
the
answers
here.
It's
just
like
which
cert,
which
fields
on
service
are
relevant,
which
are
sort
of
like
not
ignored
somewhat,
for
example,
like
type
load
bouncer,
probably
is
not
relevant
to
the
rest
of
the
things.
C
B
D
C
We
have
like
a
clear
kind
of
conformance,
slash,
API
behavior,
because
the
thing
is
we're
composing,
something
that's
new
with
something
that
already
exists
and
those
the
thing
that
really
exists
exists
in
this,
like
kind
of
complex
ecosystem.
In
some
sense,
we
just
need
to
work
through
all
the
details
to
see
that
the
user
can't
get
into
trouble
or
at
least
easily
get
into
trouble
when
they're
describing
things
I.
Think.
D
D
C
Would
be
good
to
see
what
the
contract
is
so,
where
am
I
coming
from,
is
that
we
have
a
couple
user
stories
and
they
are
again
I'm
not
saying
that
I
think
this
is
an
interesting
idea
and
we
should
definitely
look
at
it
to
kind
of
figure
out
if
you
are
going
to
get
into
trouble
because
we
can
change
aspects
of
at
least
the
gateway
a
part
of
the
API
is
like.
Could
there
could
we
get
any?
Are
there
any
ambiguous
things
right?
C
Are
there
config
that
we
feel
like
are
valid,
that
the
user
is
going
to
write
and
get
it
wrong
that
kind
of
stuff?
So
that's
why
being
a
little
bit
exhaustive
is
useful
here
just
so
that
we
don't
end
up
I'll,
give
you
an
example
in
debt
work
policy,
I
think
the
API
was
designed
for
a
long
time,
and
then
there
was
people
found.
There
was
a
need
to
basically
have
a
tri-state
instead
of
Abilene
right,
and
at
that
point
it
was
pretty.
C
Basically,
they
needed
to
do
some
kind
of
fancy
footwork
to
kind
of
get
that
back
into
the
API
I
just
want
to.
You
know
when
we
are
connecting
things
together
to
understand
that
the
fields
are
going
to
be
well
defined
and
the
users
can't
have
a
strange
corner
case.
That
I
mean,
as
a
controller
author
you're,
going
to
discover
that
anyways.
But
it
would
be
good
to
understand
that
from
an
API
standpoint.
B
Basically,
and
and
you
know,
you
need
an
endpoint
aggregator
at
the
end
of
a
rope
chain,
but
lots
of
the
fields
on
service
don't
really
make
sense
with
gateway
and
gateway
can
take
over
for
something
like
you
know,
we
we
mentioned
potentially
session
affinity,
so
it
might
be
good
for
us
to
to
just
kind
of
add
in
here
the
fields
that
do
matter
still
like
we
can.
We
can.
C
I
like
it,
it
seems
like
there's
like
definitely
good.
If
you
overlap,
maybe
we
can
define
a
subset
with
that
are
like
going
forward.
These
are
the
ones
that
matter
if
you're
using
on
with
gateway
and
then
the
other
one
you
know
you
can
set
them
up
but
like
Gateway
won't
be
looking
at
them
because
then
it
it
really
shrinks
kind
of
the
set
of
possibilities
that
we
have
to
kind
of
sort
of
figure
out.
What
the
semantics
are
right.
B
D
I
I
really
I
think
we're
solving
two
different
problems
here,
because
if
we
were
talking
about
a
TCP
route,
instead
of
this
concept
of
service
right
I,
don't
know,
we'd
be
having
the
same
conversations
and
really
we're
just
removing
it.
There's
an
implied
connection.
I
think
the
other
conversation
is
important
to
have
lord
knows
I've,
had
it
with
Nikita
and
Jeremy
and
Rob
and
buiid
some
extent
you
as
well.
C
Guess
what
I'm
saying
is
I'm
straining
your
problem.
So
if
we
say
that
there's
like
very
few
things
on
service
that
we
actually
care
about
and
we're
actually
going
to
look
at,
then
it's
much
easier
to
define
how
that
and
Gateway
works
together.
If
we
don't
do
that,
my
fear
is
that
people
will
have
an
expectation
in
our.
D
C
D
C
C
What
if
there's
you
select
multiple
services
and
they
have
different
ports,
and
so
for,
like
that's,
that's
where
that
becomes
an
issue
and
then
the
other
one
is
if
you,
if
you
are
talking
about
l4
and
there's
such
an
affinity
there
right
now,
how
does
that
propagate
back
and
forth
on
ingress
I?
Think
some
controllers
propagate
session
Tiffany?
Some,
don't
you
know,
that's
sort
of
like
a
mismatch
on
how
it
can
behave
and
we
should
just
write.
Let's
just
define
it,
I,
don't.
D
Agree,
I
just
think
it
should
also
be
maybe
a
blocker
for
this
or
handled
separately.
I.
Think
the
idea
of
defining
the
relationship
between
the
properties
on
a
service
related
to
ingress
and
load
balancer
with
respect
to
the
gateway
API
is
an
important
and
necessary
task
and
it
sounds
like
it
was
just
kind
of
punted
for
HTTP
route
and
we're
seeing
it's
due
to
various
reasons.
There
was
some
implied
things
and
then
things
we
didn't
consider
yet,
but
I
mean
I'm,
fine,
saying
look.
We
can't
do
this
until
we
do
that.
I.
D
C
C
Hear
you,
the
use
cases
are
sort
of
used
to
kind
of
they're
like
points
in
the
space
right
and
then
you're
talking
about
you
know
what
is
the
overall
shape
of
the
space?
The
I
think
this,
like
you're
gonna,
have
to
kind
of
define
it
anyways,
so
in
the
the
task
might
not
be
as
difficult
given
how
we
have
an
existing
model.
C
D
C
C
C
Closed
selectors
you're
gonna
have
conflicts
now,
yeah
I
think
we
should
explicitly
say
that,
like
would
be
one
thing
that,
in
your
definition,
that,
instead
of
so
for
example,
I'll
give
an
example,
one
of
the
ingress
controllers
I
forget
which
one,
if
you
have
maybe
Sonia
aggress
controller,
but
one
of
some
of
these
systems
like
if
you
select
multiple
services.
That's
it
basically
interprets
them
as
like
spread
traffic
evenly
among
them,
which
is
could
be
a
natural
way
to
do
it.
But
if
it's
like
a
behavior
that
right.
B
E
C
E
C
D
B
Like
you
could
select
end
points,
but
end
points
are
created
well
and
eventually
employ
slices,
which
there
will
be
more
than
one
per
service
that
already
selected
based
on
the
service
so
being
being
able
like.
If
we,
it
seems
confusing
to
select
the
things
that
are
created
from
a
service
when
the
service
exists
is
now
you've
got
this
kind
of
indirect
mapping,
but
the
reality
is
you
want
everything,
that's
related
to
a
service,
so
you
could
have
the
mechanics
be,
for
example,
you
might
need
node
port.
You
actually
might
need
the
node
port
right.
B
Might
be
some
service
specific
thing
that
you
need
there,
but
yeah.
If
you
like,
the
way
you
have
to
select
endpoint
slices
would
probably
only
like
Generic
what
you'd
be
able
to
do.
It
is
to
select
the
label
service
name
equals
the
service
that
you
want,
which
just
seems
like
it
feels
wrong,
whereas
selecting
the
service
like
us,
you
add
the
label
clip
service,
and
then
you
select
the
endpoints,
slash
endpoint
slices
for
that
service,
and
you
know,
regardless
of
version
to
work
so.
C
I
mean
my
major
take
on
this
is
that
endpoint
slice
is
pretty
low
level
and
as
a
low-level
construct,
it
is
much
easier
to
get,
especially
if
you
have
to
select
over
multiple
endpoints
licenses,
it's
much
easier
to
get
a
situation
where
there's
going
to
be
inconsistent
settings
on
them,
for
example,
like
the
set
of
ports
is
just
you
know,
really
different
between
them
and
all.
So,
if
you
select
on
service
at
least
there,
is
that
one
unifying
thing
at
the
top?
C
C
B
And
and
the
and
the
little
pebbles
derive
their
information
from
from
the
service
right.
So
if
you're
gonna,
if
you
have
conflicts,
debugging
will
be
much
easier.
If
you
can
just
take
your
your
label
selector
and
find
the
services
matching
and
say:
oh,
you
know
the
ports
conflict
easy
versus
having
to
go
through
a
potentially
large
number
of
end
boy
slices.
We.
E
Did
discuss
I
get
the
labeling
argument
that
makes
complete
sense
I'm.
Just
if
you,
if
you
targeted
service,
your
controller
is
ultimately
going
to
have
to
look
up
the
endpoint
to
get
the
endpoints
anyway.
So
I'm
not
I,
know
I'm,
not
quite
getting
that
point,
but
I
get
the
labeling
point
yeah
well,.
D
It
will
only
end
up
looking
up
there,
so
I've
implemented
this.
By
the
way
we
have
actually
the
concept
of
a
server.
So
it's
interesting
because
we've
already
implemented
it
at
VMware
and
I
wasn't
originally
proposing
this
as
a
service
route.
It
was,
let's
figure
out
TCP
route
and
Jeremy
was
what
we
should
figure
out
for
it--,
so
you're
right.
So
we
talked
about
this
and
I
think
he
liked
the
idea
of
this,
and
so
one
of
the
things
I've
learned
with
implementing
is
that
yeah.
D
You
have
to
look
it
up
anyway,
but
we
had
the
the
notion
of
indirect
and
direct
service
routes
and
they're
backwards
from
what
you
think
or
what
I
would
think.
People
would
think,
but
direct
would
mean
essentially
a
selector
list
service.
The
endpoints
are
essentially
the
IPS
that
you
want
to
load
balance
the
backend
IPs,
whereas
indirect
would
be
the
endpoints
are
probably
the
pod
eyepiece.
They
were
selected
by
the
the
service
selector,
in
which
case
you're,
probably
actually
looking
up
the
node
eyepiece
of
nodes
that
are
conditioned
ready.
D
If
there
is
a
node
port
in
play,
so
the
you
still
have
to
have
the
service
for
the
node
port,
if
you're
not
going
directly
to
the
pods-
and
we
haven't
talked
about
it,
but
this
is
called
the
service
API.
But
one
of
the
real
nice
values
of
the
services
as
they
are
today
is
selector
services,
and
you
can
use
this
to
load
balanced
things
other
than
services,
which
is
why
I
originally
thought
of
going
directly
to
the
endpoints,
but
even
with
selector
list
services.
C
C
C
D
D
B
Think
too,
with
that
question,
so
that's
a
really
good
question
the
point
to
bring
up
like
what.
What
is
the
goal
here
and
and
kind
of
the
Assumption
I
think
has
been
that
eventually
those
Gateway
ish
parts
of
service
become
gateway
right.
If
that's
the
case,
then
in
the
meantime,
do
they
are
they
defined
in
both
places
and
if
they're
defined
in
service,
are
they
expected
to
continue
to
work
like
they
do
today,
or
do
we
just
say
if
you're
using
gateway
you
stop
using
those.
C
D
B
D
A
I'll
just
say:
thanks
for
putting
this
together,
I
like
where
it's
headed,
I
think
there's
there's
a
real
purpose
for
this
I
see
the
value
in
it
and
I.
You
know:
I
I,
don't
I,
don't
have
many
criticisms
or
anything
like
that.
I
think
always
had
some
good
feedback.
I
don't
have
much
else
to
add
other
than
thank
you.
Oh.
C
Yeah,
this
is
not
a
criticism
I'm,
just
just
no
things
to
think
about
to
make
a
proposal.
Yes,.
A
D
Nothing
wrong
with
criticism.
There's
nothing
wrong
with
criticism.
As
long
as
the
end
goal
is
to
to
produce
to
help
people
solve
a
problem.
Criticism
along
the
way
just
helps
us
navigate
that
path
a
little
bit
better.
The
only
problem
with
criticism
becomes
when
your
goal
is
to
not
help
somebody,
but
just
to
pick
apart
with
the
proposing
and
and
I've
never
questioned
whether
yours
or
Rob's
goal
bow
is
to
actually
help
so
there's
nothing
wrong.
Criticism
Jeremy,
in
the
other
hand,
can
just
shut
up
concern
aside
I.
A
You
know
one
one
thing:
I'll
mention
James
had
a
good
proposal
yesterday
that
we
talked
about
in
office
hours
that
involved
moving
route
selector
into
listeners.
I
think
that's
fairly.
That
doesn't
really
get
in
the
way
of
this.
It
would
change
a
couple
of
things,
but
I
see
the
same
approach,
working
just
as
well.
Yeah.
B
C
D
I
would
think
that
the
gateway
class
would
actually
be
a
great
place
to
define
a
while
route
types
or
whatever,
and
that
way
if
I
know
I
know,
for
example,
like
the
H.
A
proxy
controller
doesn't
support
these
route
types,
but
it
supports
these
others,
because
then
you
can
programmatically
say
like
oh
I've
got
a
gateway.
That's
that's
selecting
these
routes,
but
the
class
to
which
this
is
connected
can't
supply
those
routes,
because
right
now.
C
D
B
C
Delegation
model
delegation
in
terms
of
delegating
composing
things
but
I,
don't
know
it's
a
super-duper
use
case
to
make
it
like
a
hundred
percent
composable,
and
you
can
imagine
what
a
mess
you
could
end
up
with
like
right.
You
know
get
up
like
10
chains.
Does
anyone
want
to
want
to
create
something
like
that
and
then
what
would
it
you'd
probably
be
a
nightmare
to
understand
if
you
created
such
a
thing.
E
C
As
currently
defined
that
we
have
discussed
there's,
basically
it's
sort
of
like
two-level
right
now
there
was
a
sketch
for
composability
from
the
HTTP
standpoint
and
that
conversation
still
needs
to
happen.
But
as
it's
defined,
we
see
that
most
of
the
use
cases
will
be
satisfied
by
having
this
two-level
the
gateway
with
the
listeners
as
a
sort
of
focus
point
for
talking
about
exposing
things
and
then
sort
of
controlling
how
it's
exposed
and
then
potentially
our
routing,
which
is
it
looks
like
in
the
services
case.
C
D
Traffic
splits,
an
example
of
where,
like
I,
feel
like
we
should
either
by
completely
in
the
composability
and
say
a
listener
necessarily
goes
to
an
IP
route.
Then
a
tcp
or
UDP
route,
then
a
TLS
route
optional
in
an
HTTP
and
each
one
of
those
routes
handles
that
could
what
they're
supposed
to
handle-
or
we
end
up
with
what
we
have,
which
is
HTTP
routes,
kind
of
a
composite
of
a
bunch
of
things
and
a
TCP
route
could
composite
in
support
for
splitting
and
not
really
require
a
separate
traffic
splitting
route.
D
If
you
work,
it's
confusing
is
where
we
start
to
say
let
its
composable,
but
each
route
is
also
a
composite
of
these
different
features
and
composite
doesn't
preclude
composability.
But
now
I'm
asking
myself
well
so
the
tcp
route
supports
some
type
of
splitting
or
waiting
based
on
these.
These
these
inputs,
but
there's
also
this
discrete
traffic
split
route,
should
I,
be
using
that
and
that's
where
I
think
it
can
become
confusing
and
I
understand
why
it
was
done
why
it
was
done.
C
C
Yeah
yeah,
so
traffic
split
we
are
now
sort
of
consensus
is
moving
towards
it,
trying
to
figure
out
if
we
can
sort
of
put
that
back
up
into
the
per
protocol
route
objects,
because
people
will
want
to
split
traffic
based
on
protocol
appropriate,
for
example,
Matt,
so
that
one
we
are
working
through.
So
I
would
expect
that
at
this
point,
congressman
probably
will
disappear.
Instead,
it
will
be
in
the
route
level
which
that
completely
motivates
having
a
tcp/ip
whatever
thing
there,
because
that
is
something
that
is
completely
missing
from
kubernetes
services
today,
right.
D
Yeah
yeah
no
dealt
with
that.
The
other
thing
missing
is
you
know
knowing
whether
an
IP
is
there
I'm,
not
gonna,
get
into
that.
That's
I
have
a
whole
set
of
opinions
about
it,
but
so
my
work
we
took
way
more
time
than
I
intended
with
this
I'm.
Probably
the
Jeremy
intended
I
think
a
lot
of
good
discussion.
My
ask
is
gonna,
be
tab.
People
start
to
to
look
at
this.
Add
comments.
D
Please
Dane
I
know
that
I
had
invited
you
to
please
contribute
because
you
had
filed
a
a
PR
that
I
don't
know
if
you
saw
my
previous
PR,
but
they
could
be
twins
right,
they're,
very
similar
and
I.
Don't
think
this
precludes
a
TCP
route
later,
but
it's
just
to
really
handle
that
very
common.
In
VP
case,
you
know
if
I
just
want
load
balancers
for
an
existing
service
and
l4
load
balancer
from
an
existing
service.
What's
the
easiest
way
to
get.
C
C
Tcp
route
that
has
like
nothing
in
it,
pointed
to
the
service,
and
then
you
can
define
it
in
terms
of
that
TCP
route
in
the
Gateway
and
so
forth,
because
that
one
is
a
lot
easier
to
deal
with
than
to
say.
There's
a
separate
case
for
service
there's
a
separate
case
for
TCP
route
right
kind
of
nicely.
Try
to
avoid
that
situation.
Yeah.
B
D
Yeah
yeah
I
mean
every
listener
yeah.
If
the
route
points
directly
to
a
service,
then
you're
basically
saying
what
are
the
defaults
for
a
TCP
route,
and
that
would
I
mean
that's
actually
another
way
to
think
about
this
right.
I
think
y'all
said
something
like
that
earlier
Dane,
so
I
really
I'm
gonna,
find
you
in
reputed
share.
Make
you
work
with
us
because
really
like
what
we
need
to
figure
out.
D
F
D
I
mentioned
that
I
said
that
I
had
opened
one
awhile
back
and
closed
it,
because
I
didn't
like
that.
It
mentioned
the
name
of
the
listener,
but
that
was
when
I
thought
the
Gateway
was
a
load
balance
or
not
a
virtual
server,
as
it
were
so
I
probably
would
have
left
it
open
had
I
known
that,
but
it's
just
like
yours:
almost
we
had
the
same
pipe
names
and
everything
else
and
it
used
sni
for
hostname
matching
as
well.
D
A
A
You
know
the
the
other
thing,
I
would
say
one
of
the
things
on
the
agenda
we
didn't
quite
get
to
yet
was
how
service,
api's
and
multi
cluster
services
interact.
I
I
have
a
doc,
that's
working
progress,
I'm,
hoping
to
share
out
later
today
that
for
comments
and
thoughts,
and-
and
we
also
need
to
discuss
TCP
in
that
case
as
well
so
I
yeah,
that's
coming
and
then
also
as
I
alluded
to
earlier,
there's
an
interesting
PR
from
James.
That
I
think
could
use
some
additional.