►
From YouTube: SIG Gateway API GAMMA Bi-Weekly Meeting for 20220906
Description
SIG Gateway API GAMMA Bi-Weekly Meeting for 20220906
A
Hello,
everybody
welcome
to
the
september
6th
instance
of
the
gamma
gateway
api
gamma
meeting.
This
meeting
is
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
to
be
nice
if
to
people,
if
you
need
help
with
that,
it
is
on
the
kubernetes.org
from
kubernetes
community
github
repo,
I'm
gonna
go
ahead
and
share
my
streams.
We've
got
a
couple
of
agenda
items
today
and
some
fun
things
to
talk
about.
A
As
always
like
I
mentioned
this,
is
our
public
agenda
I'll
place
a
link
to
it
here
in
the
chat?
Feel
free?
Please
add
an
agenda
item
or
and
make
sure
you
add
yourself
to
the
attendees
list,
just
for
a
record
of
your
attendance
and
can
see
all
the
wonderful
people
who
like
to
talk
about
gateway,
api
and
service
mesh
things.
A
The
the
first
topic
we
have
on
our
agenda
is
kind
of
a
transition
and
a
bit
of
a
confession
on
my
parts
for
some
administrative
failures.
A
So,
a
while
ago
I
opened
up
this
that
I
made
this
document
and
opened
up
a
issue
for
this
get
1294
for
mesh
service
binding
and
it
I
meant
for
it
to
be
kind
of
the
second
get
that
we
tackled
after
mesh
representation.
A
But
after
the
last
gamma
meeting
we
kind
of
realized.
We
there's
only
so
much.
We
can
do
the
mesh
representation
before
we
need
to
actually
like
have
a
vision
for
how
we're
going
to
bind
services
to
routes
and
and
things
of
that
nature,
the
other
way
around.
And
so
what
was
going
to
start
with
putting
some
effort
into
this
service
binding
document.
A
And
so
I
started
some
some
lights
light
work
on
this
and
but
then
mike
morris
said
that
he
had
some
thoughts
that
he
dumped
in
a
second
dock
which
is
specific
to
http
route
mesh
binding,
and
I
started
reading
this
dock
and
I
was
like
this
actually
encompasses
most
of
what
I
wanted
to
to
discuss,
and
it
has,
I
think,
the
added
advantage
of
being
concrete
for
folks
to
be
able
to
reason
about
a
particular
route
http
route
instead
of
trying
to
start
with
a
pattern
for
all
the
different
extra
resources.
A
I
I
think
it
makes
a
lot
of
sense
to
start
with
with
http
routes
and
then
iterates
toward
a
pattern
that
works
for
the
other
resources
and
easier
to
talk
about,
because
we're
being
concrete,
so
kind
of
what
I'm
proposing
is
that
we
essentially
retire.
This
talk
and
either
move
to
this
hrough
http
route,
doc
or
copy
it
over.
So
it's
in
one
spot,
but
I
want
to
get
other
folks
opinions
on
this
see
flynn.
You've
got
your
hand
raised,
go
ahead.
B
So,
with
respect
to
your
documents,
I
think
that
switching
over
and
working
from
that
document
is
great.
I
have
no
opinion
on
whether
that
involves
copying
it
into
something
with
a
different
name
or
just
changing
references
to
it.
B
With
respect
to
the
agenda,
I
was
going
to
propose
the
times
that
we've
gone
through
in
other
instances
of
this
meeting
to
talk
about
particular
gaps.
We
have
managed
to
absorb
all
of
the
available
time,
and
so
I
would
kind
of
like
to
invert
the
order
of
things
on
this
agenda
and
maybe
talk
a
little
bit
first
about
working
poc
stuff,
so
that
that
can
hopefully
inform
discussion
around
the
http
route,
binding
stuff.
A
I
actually
really
really
like
that.
I'm
gonna
and
I'd
like
to
kind
of
do
that
moving
forward
for
other
meetings
to
to
safe,
get
discussion
for
last
to
make
sure
that
other
stuff
can
breathe.
I.
B
A
Okay,
so
I'll
take
a
note
to
do
that
and
then
in
that
case
I'll
turn
it
over
to
you
shane
for
your
even
item.
C
I
don't
want
to
necessarily
drive
I'm
really
hoping
this
just
turns
into
a
discussion,
but
it's
kind
of
a
follow-up
to
something
we
talked
about
in
want
to
say
it
was
the
last
meeting
and
so
I'll
kind
of
point
it.
I
guess
I
said
you
first
keith,
just
like
we
kind
of
discussed,
or
at
least
touched
on
the
topic
of
starting
to
have
a
poc,
that's
built
as
part
of
the
gap.
C
D
For
me,
I
think
that
having
pocs
is
a
great
idea
that
works
well
for
things
that
are
smaller
and
more
contained
before
something
of
the
scale
of
what
we're
talking
about
with
here,
like
having
a
working
poc
is
going
to
involve
like
building
up
the
whole
thing.
I
mean
john,
you
got
your
your
yeah,
you
still.
C
Already
has
one
so
I
agree
if
you're
saying
like
every
time
the
proposal
changes
week
to
week.
We
want
to
update
it,
that's
the
extreme,
but
if
we
want
some
variant
of
something
like
we
did
already
do
this
in
istio
and
you
know
we
expect
to
change
it.
Obviously,
once
we
have
something
formalized
here,
but.
A
I
guess
my
question
is:
what
are
what
specifically
are
we
hoping
to
gain
from
a
poc,
and
I
don't
mean
that
like
sarcastically,
I
know
the
benefits
to
seeing
things
are
are
numerous,
but
is
there
a
particular
goal
that
you
have
in
mind
for
doing
a
poc
as
part
of
the
gap
or
as
part
of
and
where
we
insert
that
in
the
get
process?
C
It
occurs
to
me
that
we're
this
is
big,
and
that
is
part
of
why
I
feel
like
the
poc
might
be
helpful.
So
for
those
of
us
who
are
going
to
be
implementing
this
but
are
otherwise
very
busy
having
everything
conceptual
and
in
english,
descriptions
of
what
we
want
to
do
is
necessary.
Ultimately,
but
it's
possible
that
having
a
poc
could
get
us
get
us
there
faster
and,
if
not
faster,
it
might
be
fun
and
that's
just
kind
of
where
I'm
at
right
now.
E
No
you're,
not
okay,
I
know
just
quick
gamma
poc
involves
a
lot
of
stuff,
I
mean
for
low
level,
networking
avoid
perception
and
happy
table
and
a
lot
of
stuff.
I
would
rather
see
each
implement
vendor.
That
is
part
of
this
group
create
their
own
implementation
with
their
own
infrastructure,
because
that's
really
a
problem
infrastructure,
not
a
few
apis,
we're
adding.
How
do
you
intercept?
E
How
do
I
use
site
or
not,
sidecar
and
and
then
have
you
know
something
and
try
to
sort
out
what
works
commonly
well
or
what
is
very
difficult
to
intermittent
implementation.
So
we
we
take
it
out
of
the
or
we
discuss
it.
D
Yeah,
so
I
think
I'm
assuming
you're
done
yeah,
so
I
think
if
so
I
think
pocs
are
nice,
but
I
think
the
the
thing
that
would
also
help
shane
is
probably
us
having.
I
was
going
to
suggest
something
like
separately,
that
we
had
some
something
like
an
agreed
on
set
of,
like
sort
of
slight
slightly
more
deep
dive,
like
specific
use
cases
that
you
want
to
be
able
to
hit
with
with
a
mesh
that
binds
a
http
route
to
a
service.
D
Right
like
something
like
you
know,
hey
for
as
a
producer
of
a
service.
I
want
to
be
able
to
bind
a
http
route
that
that
routes
traffic
for
a
certain
path
to
two
different
to
in
a
weighted
way.
F
D
Two
different
to
do
different,
like
kubernetes
service
deployments
right
for
purposes
of
canary
testing,
or
something
like
that
right,
like
very
specific
use
cases
that
pro
that
almost
every
service
mesh
is
going
to
do
that
that
we
say
okay,
given
this,
given
this
binding
implementation,
how
would
you
do
what
would
the
conflict
look
like
you
know,
for
for
these,
like
two
or
like
two
or
three,
maybe
use
cases
very
specific
use
cases,
and
I
think
the
good
thing
there
is
that
that
gives
us
shame
what
you're
talking
about
that.
D
We
have
some
sort
of
concrete
thing
that
we're
talking
about
we're,
not
just
being
like.
Maybe
it'll
work
like
this,
like.
How
does
it
work
for
these
two
specific
things,
and
what
does
the
conflict
look
like
because
I
mean
personally,
I
found
that
a
lot
of
the
time.
It's
when
you
start
writing
down
the
animal
for
something.
That's
when
you're
like.
Oh,
that
totally
doesn't
work
or
you
know.
How
does
this
work
or
you
know
this
thing
here-
is
going
to
be
really
unclear.
A
D
We
should
do
things
a
little
differently
and
that's
that's
opposed
to
the
that's
sort
of
a
work
example,
rather
than
a
poc
with
actual
working
code.
I
guess
the
thing
that
I
was
trying
to
say
before
is:
if,
if
it
involves
doing
a
whole
bunch
of
actual
implementation,
then
it
kind
of
depends
on
where
the
implementations
are
at
and
if
they're
ready
to
do
that
like
for
ceiling.
D
Right,
like
yeah,
we
don't
even
have
any
gateway
api
stuff
implemented
yet
so
I
can't
I
can't
do
a
pocket
because
I
don't
have
the
infrastructure
yet
there's
like
quite
a
bit
of
work
to
get
there,
so
I'm
not
gonna
be
able
to
be
useful
in
that
respect,
but
it
can
be
useful
in
terms
of
doing
work.
Examples.
A
I
flynn
you're
next
with
and
now
I
want
to
bring
up
that,
I
think
flynn.
You
actually
started
some
of
this
direction
in
the
past.
With
that
hackmd
article
go
ahead.
B
Yeah,
I
was
gonna
say
that
one
of
the
reasons
that
I
like
the
idea
of
trying
to
do
this
with
a
focus
on
a
poc,
whether
it
is
you
know,
yaml
stuff
or
whether
it's
code
gets
all
the
way
back
to
this
idea
of
yeah.
Let's
pick
some
use
cases
and
use
it
to
narrow
the
scope
that
we're
working
on
for
the
first
release-
and
this
has
often
gotten
us
into
the
question
of
what
versus
how.
B
But
you
know
I
I
feel
like
we
may
have
a
little
bit
more
consensus
there
in
that
it
seems
that
people
have
this
idea
that
okay,
we
should
be
able
to
bind
http
routes
to
some
sorts
of
things,
and
we,
I
think,
can
reasonably
start
asking
questions
like
all
right.
What
kinds
of
things
do
we
need
to
support?
What
will
that
look
like?
I
think,
that's
an
entirely
reasonable
set
of
questions
to
be
asking
right
now.
B
C
That
all
makes
sense
to
me
and
everybody
had
good
thoughts.
I
am
trying
not
to
throw
too
many,
I'm
not
trying
to
throw
wrenches
in
the
gears
trying
to
play
a
supportive
role
and
like
help
where
I
feel
like
there
might
be
a
need.
C
So
I'm
happy
to
kind
of
take
this
myself
and
be
like
okay,
everybody
had
some
good
thoughts
and
go
take
a
look
at
the
the
istio
poc
that
I
didn't
know
existed
personally,
but
not
to
say
that
we
shouldn't
have
further
conversation
about
it,
but
I
think
that'd
be
for
me
a
good
next
step.
A
I
think
one
of
the
pieces
of
feedback
I
had
personally
from
the
hack
and
b
document.
The
first
time
is
that
there
there
was
there
hadn't
been
that
consensus.
Yet
I
think
we
were
everybody
can
have
different
directions.
We
didn't
have
the
straight
vocabulary
of
the
gap
that
we
wrote
and
so
I'm
a,
I
think,
we're
in
a
better
position
now
to
perhaps
go
back
in
that
direction.
For.
A
Yeah
I
mean
that
that
that's
I
mean
that
that's
the
big
you
know
one
of
one
of
the
problems
we're
trying
to
solve.
That's
not
technical
at
all.
It's
it's.
How
do
you
start
from
nebulous
requirements,
everybody
in
a
different
page
and
work
together
to
come
towards
something?
That's
somewhat
common
and
agreed
upon,
and
this
is
this
is
difficult.
This
is
what
is
of
our
time.
So
no
no
worries
there.
A
Yeah
I
nick
go
ahead
before
I
go
ahead.
D
Yeah,
I
was
gonna
say
that
yeah
I
was
gonna,
say
something
else,
but
yeah
to
address
that
I
think
yeah.
One
of
the
things
that
I
was
trying
to
say
was.
D
I
think
that
in
that,
in
the
gap
that
we're
going
to
review
later,
I
think
that
doing
the
exercise
off
for
each
of
these
options
we're
going
to
check
you
know
these
two
use
cases
and
putting
it
in
that
gap
is
a
really
good
way
to
sort
of
compare
and
contrast
the
different,
the
different
options
in
a
concrete
way,
rather
than
a
more
sort
of
conceptual
way,
and
I
think
the
I
lost
the
other
thing
I
was
going
to
say
it
will
come
back
if
it's
important.
C
Sounds
like
a
couple
of
action
items
that
we
have
then
on.
This
would
be
one
and
this
could
kind
of
be
for
everybody,
but
I'll
certainly
do
it
go.
Take
a
look
at
the
istio
poc
so
far,
which
I
just
kind
of
clicked
on
the
link,
and
I
doubt
it's
too
like
it
doesn't
look
like
it's
actually
that
beef,
which
is
good
and
then
two
if
somebody
could
kind
of
start
migrating,
some
of
the
hack,
md
stuff
and
integrating
it.
I
guess,
is
the
right
word
with
the
relevant
gap.
B
Yeah,
I
can
take
that
one
keith
I'll,
probably
ping
you
tomorrow
about
that
I'll
ping,
you
on
slack.
A
E
Yeah
on
the
on
the
istio
poc,
you
may
notice
mesh,
you
know
the
attachment
parent
ref
is
nothing
exactly
what
we
want
it
to
be,
and
it's
just
a
placeholder
that
we
put
to
have
something
to
attach,
but
that's
what
we
are
hoping
that
the
gap
will
achieve.
You
know
any
kind
of
standard
attachment
point
in
the
service
or
whatever
super
service
we
decided
before
as
soon
as
it's
defined,
I
think
we'll
be
very
happy
to
switch
to
it.
A
Yeah
absolutely-
and
I
I
think
it's
a
good
starting
point
as
well.
One
thing
I'll
say
before
you
nick
is
I'm.
It
came
to
my
mind
when
shane
remember
what
he
said,
but
he
said
something.
Then
you
know
a
gap
is
kind
of
the
phone
deliverable
of
what
we,
what
we're
doing
here
in
gamma-
and
I
I
just
realized,
noticed
myself
falling
into
this
trap
of
you
know
we
don't
necessarily
have
to
start
with
with
gaps.
A
If
that's
not
going
to
be
the
best
way
to
go
about
figuring
the
questions
we
need
to
get
answered,
doing
the
doing
the
work
to
prove
things
out,
we
may
very
well
find
that
we
don't
have
enough
for
a
clear
gap
yet
and
we
need
to
you
know,
go
to
something
else
and
then
come
back
to
it.
So
I'll
say
that.
D
A
D
Nick,
oh
yeah,
so
I
remember
the
two.
The
things
I
was
gonna
say
so
the
first
one
is
yeah.
D
So
I
think
when
we
go
to
the
the
discussion
of
the
current
get
document,
I
think
like
I
feel
like
it
would
be
really
useful
to
sort
of
kick
that
off
with
a
let's
sort
of
talk
about
a
couple
of
the
use
cases
that
we
can
then
use
for
examples
that
will
then
help
flynn
for
when
he's
bringing
his
hack
into
things
in,
and
I
think
also
the
other
thing
is
that
I
wanted
to
say.
D
Is
the
it's
really
important
to
remember
that
when
we
were
doing
the
initial
round
of
gateway
api
stuff?
We
took
like
many
many
many
times
longer
to
do
this
right
like
if
I
understand
that
it
can
feel
really
slow
and
frustrating.
But
I
promise
you
that
this
is
much
less
slow
and
frustrating
than
it
was
when
we
were
doing
the
initial
gabriel
pi1
like
it's
so
much
better.
D
Yeah
yeah,
so
that's
it!
If
I,
if
I'm
like,
I
think
we
should
do
this
first,
usually
it's
because
on
the
initial
gateway
api
stuff
we
had
times
when
we
would
talk
about
things
and
then
I'm
like.
Oh
yeah,
that's
right
when
we
were
doing
that.
The
thing
that
helped
us
was
having
some
concrete
examples,
or
you
know
agreeing
about
this
sort
of
stuff
before
we
got
to
like
we.
What
we
did
before
was.
D
We
would
argue
about
this
for
like
three
or
four
months,
and
then
you
know,
then
then
we
would
come
back
to.
Maybe
we
should
write
down
some
concrete
examples,
so
yeah!
That's
why
I'm
trying
to
be
like?
Let's
do
those
things
now.
A
Absolutely
do
we
have
any
last
comments
on
this
agenda
item.
We've
got
some
really
good
actions
out
of
this,
and
I
really
appreciate
you
bringing
this
up
shane.
Any
last
tops
of
conversation
before
you
move
on
to
discussing
the
actual
gap
and
taking
nick's
advice.
There.
A
Okay,
one
kind
of
housekeeping
note
is
I'm
gonna
be
switching
over
to
the
mesh
binding
dock,
so
I'm
not
gonna
be
able
to
take
a
really
good
notes
in
in
the
meeting
notes
agenda.
So
if
somebody
wants
to
volunteer
to
take
some
meeting
notes,
then
I
really
appreciate
that
so
anyway.
So
what
you
say.
A
Yes,
I'll
do
that?
Oh
appreciate
it.
Thank
you.
There'll
be
suggestions,
but
I'll
just
accept
them,
afterward,
okay,
so
yeah!
This
is
the
http
route
mesh
binding
gap
that
might
created.
I
like
it's
a
lot
more
concrete
than
what
I
was
originally
gonna.
Do
I
don't
see.
A
Particular
specific
use
cases,
but
in
lieu
of
that
I'm
actually
going
to
go
to
our
our
original
gap
and
see
if
we
have
any
there.
Some
reference.
A
It's
a
service
producer;
okay,
this
isn't
super
specific,
but
it's
it's
probably
one
of
the
most
basic
ones.
I.
A
Yeah,
I
agree
but
yeah
as
a
service
producer.
I
I
wanted
to
deploy
a
canary
version
of
an
application
that
splits
traffic
based
on
http
properties,
so
as
we're
waiting
through
this
this
this
gap
and
talking
through
it
that's
kind
of
let's
try
to
I'm
going
to
try
to
frame
that
as
the
the
goal
for
for
conversation
is
traffic
splitting
based
on
http
properties.
A
So
let
me
get
the
correct
talk
all
right,
so
I'm
going
to
use
the
same
rules
as
the
personas
and
that
that
gateway
api
does
and
they're
binding
to
services,
I'm
going
to
skip
goals
for
now,
with
the
use
case
straighten
my
freshman.
Let's
talk
just
talk
through
some
of
the
approaches
that
are
declared
here.
A
This
looks
very
similar
to
istio's
implementation
of
gateway,
api
yeah
for
for
binding
with
a
a
mesh
resource.
Even
though
an
istio
is
not
going
to
be
a
resource,
it's
just
a
kind
mesh,
and
so
what
this
would
be
is
on
each
http
route.
The
parent
ref
would
be
binding
to
a
cluster-scoped
mesh
object
as
to
find
in
the
method
representation
dock.
From
that
we
hashed
out
last
week.
A
This
could
be
mesh,
this
could
be
mesh
class.
The
name
is
not
important,
but
it's
the
cluster-wide
definition
of
the
of
the
mesh
that
you
are
going
to
be
binding
to,
and
one
of
the
to-do's
here
to
figure
out
is
how
does
this
work
with
explicit
host
names,
or
you
know,
because
it's
http
and
as
as
well
as
kind
of
balance,
the
transparent
proxy
behavior
for
routing
kubernetes
services
defined
as
a
back
and
ref.
A
There
are
some
decisions
to
be
made
there
as
far
as
priority
and
things
of
that
nature.
So
keep
that
in
mind
for
this
approach
and
likely
every
approach
honestly
as
we're
dealing
with
http
the
the
other.
A
Another
approach
is
to
instead
of
binding
to
a
cluster-scoped
mesh
resource,
it
would
bind
the
the
the
http
rep
would
bind
to
a
service
resource
and
that
service
resource,
notably,
would
be
the
same
as
the
backend
rev
at
least
one
of
the
back
end
refs
for
that
http
route,
and
this
actually
gives
us
our
our
traffic
splitting
use
case
right
here
and
some
sample
yammel.
A
This
option
would
is
kind
of
dependent
on
the
front
end
role
of
the
kubernetes
service
resource,
as
we've
talked
about
at
length,
the
the
front
and
back
and
duality
of
kubernetes
service
and
we're
gonna
use
the
kubernetes
dns
name
as
the
canonical
address,
for
which
the
traffic
will
be
redirected
by
rules
defined
in
the
http
route,
so
yeah,
so
not
using
a
host
name
specifically,
but
using
the
front
end
of
this
service
resource
as
defined.
A
Now
this
this
gets
interesting
when
you
start
thinking
about
different
trust
domains,
I'm
assuming
that
there's
there'll
be
a
namespace
piece
here
as
well
or
if
you
inherit
this
name
space
but
yeah.
That's
that's
that
option.
Just
more
thinking
about
that.
It
goes
on
to
it
goes
on
to
discuss
the
examples.
B
It's
correct
me
if
I'm
wrong
here,
but
when
you
start
talking
about
the
kubernetes
dns
name
as
the
canonical
address,
etc,
I
don't
think
you're
implying
using
the
kubernetes
dns
service
to
look
things
up.
Necessarily,
you
could
just
as
easily
be
using
that
as
a
key
to
find
endpoint
slices
for
example,
or
things
like
that.
A
So
I
so
I
didn't
write
this,
but
based
on
what
it
says
it
does
seem
to
imply
using
the
well
let's,
let's,
let's
read
here.
Actually,
writing
was
something
to
redirect
nine
of
traffic
to
the
foo.
Okay,
the
backend
endpoints
specify
the
service
electric
field,
so
this
actually
does
seem
to
be
using
endpoints
rather
than
the
front
end.
So
maybe
this
is
yeah
that
dns
piece
doesn't
seem
to
be
used
here
at
all.
This
definitely
seems
like
the
oh
okay,
so
for
the
transparent,
I
see
what
it's
saying
so
for
the
transparent
proxy.
A
You
know
for
the
proxy
to
recognize,
requests
and
intercept
them.
It
would
be
using
the
dns
name
kind
of
as
a
matcher,
but
then
for
actual,
like
traffic
writing
to
determine
you
know
what
hosts
what
endpoints
are
being
are
having
traffic
forwarder
to
it.
On
behalf
of
this
service,
we
would
use
endpoints
in
the
service
selector
so
that
that
should
be
reworded,
but
it
does
appear
to
be
talking
about
both.
B
F
Right
so
there's
a
duality
right
when
you
address
services
and
we
need
to
choose
which
one
we
mean
is
a
cr
kubernetes
service
generates
both
a
vip
and
a
dns
name.
Both
are
generated.
F
You
could
choose
to
do
a
hostname
match
in
http
routing,
based
on
the
dns
name
alone,
regardless
of
what
the
ip
was
right,
which
could
be
really
dangerous
to
do
by
the
way.
But
maybe
that's
what
you
meant
to
do
right
as
a
service
producer,
but
you
couldn't
do
that
for
any
iep
other
than
the
ips
that
you
owned.
B
F
We
you
have
to
be
clear
about
which
of
those
two,
and
we
also
have
to
clear,
be
clear
about
who's,
doing
the
routing
when
we
make
that
choice.
F
If
the
routing
was
occurring
in
something
that
either
producer
owned,
it
would
probably
be
okay
to
do
either
if
the
writing
was
occurring
in
something
that
I
didn't
own,
like
a
client
sidecar
routing
on
the
hostname
alone,
right,
regardless
of
ipmatch,
is
a
risky
thing
to
do
right.
It
would
be
like
me
like
a
worse
example
of
that
would
be
producer.
Writing
a
host
matching
rule
for
star
as
the
host
name
and
capturing
all
http
traffic
for
everybody
right.
D
Is
always
available
and
as
kostan
says,
the
host
name
is
really
you're
using
the
hostname.
D
For
the
lookup,
where
you
don't
need
to
worry
about
details
of
like,
has
the
ip
changed
or
something
like
that,
the
it
does
feel
like
the
this
is.
This
is
a
case
where
we
need
to
talk
like
where
we
kind
of
need
to
talk
about
like
okay,
I'm
going
to
get
conceptual
here.
Sorry,
I
like
service,
like
what
is
a
service
right
like
what
is
the
service
that
we
are
talking
about
binding
things
to
what
is
its
identity
like?
D
What's
the
one
thing
that
identifies
that
service
as
opposed
to
some
other
service
right
like
in
terms
of
the
user
experience?
It's
the
name
right,
like
it's
a
name.
It's
it's
a
way
you,
but
in
terms
of
the
actual
identity
of
the
service
from
a
traffic
routing
point
of
view,
it
is
an
ip
like
an
ip
or
set
of
ips
like
usually
a
vp
is
going
to
be
again
itself
a
representation
of
a
set
of
endpoints.
D
You
know,
and
it's
a
way
to
have
a
stable
ip
address
that
manages
a
non-stable
pool
of
endpoints,
and
so
the
you
know
like
yeah.
So
I
think
that
the
thinking
is
saying
like
a
service's.
D
Is
it's
is
at
sort
of
the
most
fundamental
level,
and
then
we
can
build
additional
identity
constructs
on
top
of
that.
But
having
that
be
sort
of
the
disambiguating
key
is
like
the
the
important
thing
that
we
need
to
talk
about
here,
and
this
comes
down
to
like
what
is
the
front
end
of
the
service
and
the
front
end
of
the
service
is
then,
in
this,
in
this
sort
of
what
I'm
talking
about
here.
The
front
end
of
the
service
at
its
heart
is
a
vip.
A
Yeah,
I
I
completely
well
yeah,
I
I
agree
for
the
most
part.
I
I
do
want
to
make
sure
that
we're
not
that
we're,
not
forgetting
the
variety
of
use
cases
where
host
name
is,
is
very
important.
D
A
No,
no
you're
good.
I
I
I
I'm
sure,
I'm
sure
you're,
aware
of
this,
but,
like
you
know,
there
are
a
lot
of
of
constructs
where
it
you
know,
htcp
the
host
name
is
being
used
as
a
you
know,
a
way
to
front
multiple
internal
services.
The
java
world
is
very
accustomed
to
to
things
like
that.
Grpc
grpc
is
huge
for
a
host
name.
A
I
I
struggle
to
think
about
it
as
any
more
decomposed
than
a
compound
primary
key
between
hosts
and
http
specifically,
but
I
I
think
I
have
to
think
about
it
as
like
a
compound
primary
key
between
ip,
really
like
ip
membership
within
a
higher
level
vip,
but
ip
plus
host
name,
and
I
I
I
feel
like
I've.
I
think
we've
talked
about
this
in
the
other
in
the
main
game
api
meeting,
but
it
feels
like
there's
a
kind
of
a
series
of
matchers
where
it's
iap.
A
First
then,
host
name,
but
both
must
be
said.
There
are
both,
must
match
rather,
and
I
think
anything
less
than
that
you
either
lose
a
lot
of
the
of
the
advantages
and
a
lot
of
the
use
cases
for
http
in
the
post
name
case,
and
the
others
is
like
pure
hostname,
as
louis
mentioned
earlier,
is
very,
very
dangerous.
So
I
feel,
like
you've
got
to
have
both
when
you
term,
but
it
comes
like
service
identity.
B
And
you
know
casino
said
this
in
the
chat.
Actually,
I
wanted
to
point
out
that,
no
matter
what
we
decide,
we
think
a
service
identity
really
is
to
a
user.
The
host
name,
the
name
that
goes
with
the
service-
is
the
only
thing
they're
going
to
be
thinking
about,
and
so
in
a
very
real
sense.
We
have
to
recognize
the
fact
that
the
end
users
of
the
thing
will
be
thinking
of
services,
as
named
with
their
names.
B
B
B
Don't
don't
dude,
but
the
other
thing
I
was
going
to
say
also
was
it's
interesting
to
me
to
hear
people
say
things
like
really
the
identity
is
the
because
I
don't
know
in
my
world
the
identity
is
really
a
cryptographic
key,
not
so
much
the
ip
address
anyway,
but
yeah
in
terms
of
routing
traffic.
To
the
thing,
the
thing
that
you
route
to
has
to
be
an
ip
address.
I
absolutely
accept
that,
and
I
think
that
that's
an
important
thing
to
bear
in
mind.
B
D
Okay,
so
yeah
to
go
back
to
what
I
was
saying,
the
I
I
left
it
sort
of
on
a
deliberately
provocative
statement
on
purpose
like
they.
I
think
it's,
the
part,
that's
really
important
here
is
like
yes,
the
actual
identity
of
the
service
is
going
to
be
some
composite
of
a
number
of
things
about
the
service
right
like
ip
host
name
like
the
kubert,
like
some
sort
of
kubernetes
object
name,
but
I
think
it's
pretty
reasonable
that
people
might
want
to
be
able
to
define.
D
You
know
rules
in
terms
of
like
some
kubernetes
resource,
but
like
community
service,
for
example,
but
like
and
and
then
there's
also
you
know,
some
sort
of
cryptographic,
identity
or
something
like
that
is
probably
going
to
be
important
at
some
point.
I
know
we
said
before
that
we
don't
want
to
mandate
that
we
talk
about
the
mtls
like
as
part
of
this
description,
because
that's
the
implementation
did
help
with
the
mission
which
I
agree
with,
but
as
kosta
said
in
the
chat
like
you
know
there,
there
are
going
to
be
stuff.
D
That's
like
you
know,
certs,
to
connect
to
the
service
and
some
stuff
like
that,
that's
bound
to
the
service.
That
is
literally
what
I'm
talking
about.
When
I
talk
about
the
back
end
properties,
in
that
other
gap,
right
like
there
is
a
set
of
properties
that
are
sort
of
tightly
bound
to
the
actual
pods
that
are
running
that
you
know
that
are
pretty
tightly
bound
to
that,
and
so
the
service.
D
Is
going
to
span
all
of
those
things,
but
the
point
that
I
was
trying
to
make
is
at
the
end
of
the
day,
the
thing
that
this
api
is
all
about
is
actually
getting
traffic
to
pots,
and
so
at
its
lowest
level.
There's
probably
a
better
way
to
say
this:
the
service
identity
is
the
vip
of
some
is
a
single
ip.
D
That
is
like
a
representation
of
a
set
of
ips
right,
like
you
can
talk
about
it
as
a
set
of
ips
or
a
single
ip,
but
like
that
we
could
say
it's
a
set
of
ips
and
that
that
then
means
oh,
you
don't
have
to
have
vips,
but,
like
the,
I
think,
the
you
it's
probably
better
to
try
and
make
it
so
that
almost
every
implementation
I
can
think
of
is
going
to
end
up
having
a
single
ip
as
like
a
proxy
for
some
for
the
set
of
the
actual
ip
products
costing
over
to
you.
E
Yeah
to
sorry
to
disappoint
you
you've
seen
someone
mention
grpc.
We
have
this
proxies
jrpc
support
where
there
is
no
deep
involved
at
all,
because
proxies
grpc
and
any
kind
of
native
implementation
of
the
mesh
is.
You
know,
dialing
a
particular
service
with
hostname
and
there
is
no
no
resolution
of
to
vip.
In
this
case,
we
only
need
if
we
need
to
go
to
iptable
or
some
interception
mechanisms.
Otherwise,
if
it's
native,
the
hostname
directly,
can
be
mapped
to
you
know,
mesh
apis
and
and
load
balancing
decisions.
E
In
the
internal
implementation,
we'll
talk
with
kubernetes,
via
whatever
your
xds
or
whatever,
and
get
the
load
assignments
to
where
it
should
send
the
traffic
I
mean
the
actual
destination
which
can
be
you
know,
real
end
points
can
be
in
a
different
class
can
be
anywhere,
but
that
there
is
there
is
no
cluster
vip
involved
and
when
I
said
the
set
of
tips,
I
meant
multi-cluster
use
cases
where
you
have.
E
D
So,
but
but
like
it's
still
reasonable
to
describe
that
set
of
endpoints
like
buy,
buy
a
pseudo
ip
of
some
sort.
Right,
like
you
know,
even
if
you're
not
actually
routing
traffic
to
it,
then
like
you
need
to
be
able
to
have
some
bucket
that
you
put
those
endpoints
in
and
like
in
that
in
the
case
of
the
specific
uk
you're
talking
about
it's
a
specific
grpc
hostname
but
like
hostname
is
like
is
pretty
much
always
like
like
a.
D
I
don't
want
to
use
the
word
proxy,
but
like
a
a
stand-in
for
for,
like
an
ipad
address
right
like
at
some
level.
E
Yeah,
but
we
are
talking
about
two
different
kind
of
ip
addresses
vips,
which
are
basically
some
synthetic
cluster
ip
in
kubernetes
and
we
are
talking
actual
destination
ips
and
when
you're
talking
destination
ips,
we
are
talking
video
about
local
assignments.
Where
you
know
you
send
me
three
endpoints
where
I
send
the
traffic,
but
doesn't
mean
that
it's
the
same,
so
we
need
to
make
a
distinction
between
endpoint,
ips
and
and
service
ids.
I
think.
D
Yeah,
okay,
but
but
the
but
making
that
decision
in
distinction
doesn't
help
us
to
talk
about
what
is
the
services
identity,
but,
like
you
know,
the
thing
that
I'm
trying
to
get
here
is
like.
What's
the
thing
that
that
tells
you
that
service
foo
is
different
from
service
bar
right
like
what
are
the
things
that
tell
you
that
service
foo
was
different
from
service
bar
right
like.
D
This,
but
that's
what
I'm
saying
like
what
I'm
trying
to
do
is
to
break
the
service
identity
down
into
the
one
thing
that
everybody
is
going
to
have
to
support,
no
matter
what
features
you
have
available
in
your
mesh,
and
that
is
an
ip
right.
Maybe
a
set
of
ips
right,
like
being
the
endpoint
addresses
but
like
having
it
stand
in
as
an
ip
is
like.
D
That's
the
one
thing
that
everybody's
going
to
have
to
agree
on,
because
everybody
is
doing
ip
routing,
but
like
nobody's
suggesting
that
we're
going
to
do
you
know
mesh
routing
via
ipx
right
like
yeah,
or
something
like
that
right
so,
like
that,
what
I'm
trying
to
say
is
like
we
got
to
break
this
down
to
the
most
fundamental
things
that
are
not
like
the
the
things
that
only
some
implementations
are
going
to
support
like
what
is
the
core
support?
What
is
the
core
thing
that
everybody
has
to
do
right?
Like
that's,
that's
the
question.
A
So
another
way
to
phrase
what
you
just
said
nick
is
we're
specifically
focused
on
the
routing
problem.
At
this
point,
I
didn't
identity.
Service
identity
is
a
very
loaded
term,
especially
in
mesh
world,
but
when
it
comes
to
allowing
some
network
some
network
device
to
make
a
routing
decision
you
buy
for
just
whatever
implementation,
we're
talking
about,
there's
got
to
be
something
with
which
we
can
refer
to
a
destination
and
at
l4
you
know,
that's
an
ip
just
you're
in.
B
A
Right
and
the
thing
is,
you
know
the
other,
the
other
side
of
that.
Can
you
hear
me.
B
A
True
but
yeah
the
other.
The
big
thing
with
mesh,
though,
is
that
you're
able
to
to
use
l7
context
for
this
routing,
for
these
routing
conversations
right
that
that's
one
of
I
think
the
non-negotiables
for
anything,
that's
going
to
talk
about
service
message.
Cases
like
you
you've
got
to
be
able
to
elevate
to
l7
and
use
that
context
for
routing
decisions.
A
So
at
the
same
so
so,
while
yes
at
the
end
of
the
day,
a
routing
destination
is
going
to
be
a
ip,
I
don't
think
you
can
ignore
hostname
as
well.
So,
like
we've
kind
of
been
talking
around
this
for
a
second,
I
think
we're
getting
close
like
circling
the
drain.
Here,
it
sounds
like
there's
general
consensus
that
we
need
both
and,
at
this
point,
we're
trying
to
figure
out
how
to
represent.
That
is.
Is
that
is
that
fair?
We
started
talking.
A
We
started
on
this
talking
about
this
particular
binding
approach,
where
it's
referencing
a
service
kind.
I've
got
other
issues
with
this,
and
lee
wynn
had
some
some
good
comments
in
the
chat
about
this
as
well.
It
sounds
like
we
all
know.
We
need
to
find
somebody
to
represent
both
in
in
in
the
api.
Somehow
does
it?
Is
that
fair
to
say.
D
I
am
not,
I
am
not
for
a
moment
suggesting
that
users
will
be
putting
in
the
the
ip
as
as
right
like.
What
I
am
saying
is
that
the
constructs
that
implementers
will
need
to
do
use
ip
as
a
key.
I
like,
because
the
problem
is,
if
you
are
saying
everything
is
going
to
be
a
host
name,
what
host
name
is
that
is
that
the
short
host
name,
that
is
just
the
service
name?
Is
it
the
one?
D
That's
dotso
dot
namespace.service.cluster.local,
like
john
called
out
earlier
that
bringing
cluster
to
the
local
then
as
a
defined
part
of
the
api,
then
means
that
you
change
that
you're
100
screwed
right
like
if
we
say
it
has
to
be
the
host
name.
Then
the
problem
is
that
you
are
stuck
defining
which
host
names
are
the
canonical
hostnames.
E
No,
if
I
think
we're
on
the
same
page,
I
mean,
if
you
are
saying
that
users
will
never
put
ips
inside
yamaha
synchronous
image
internally
with
whatever
we
do.
It's
not
you
know
everyone
can
do
whatever
they
feel
necessarily
process.
Jrpc
may
not
use
ip
other
would
use
ips,
but
what
we
need
to
agree
and
have
consensus
is
that
users
will
not
type
ips
enamels
unless
they
really
immediately
if
they
have
a
very
special
case.
D
Yeah,
that's
absolutely
what
I
was
saying,
but
what
I
was
trying
the
point
I
was
trying
to
get
to
is
like
if
users,
if
users
are
putting
a
domain
name
in
their
yaml,
then
how
do
you?
How
do
you
pick
like?
How
do
you
disambiguate
those
domain
names
is
the
same
domain
name
is
used
in
two
different
places
and
the
answer
that
I'm
trying
to
say
is
that's
the
ip.
This
is
like
this
is
about.
How
do
you
break
down
the
you?
What
happens
when
you
have
conflicts?
What
happens?
How
do
you
do
conflict
resolution?
E
You
know
the
overlapping
ips
are
a
problem
I
mean
here.
Rit
is
not
sufficient,
it's
network
plus
ip,
because
you
have
support
for
the
overlapping
network.
So
unless
we
have
moved
to
ipv6
again.
D
Sure,
okay,
but,
like
you
know
again,
I
understand
that
there
are
a
million
edge
cases
that
are
going
to
screw
things
up
right,
like
definitely
but
the
whole
thing
that
I'm
trying
to
say
is
because
there
are
a
million
million
edge
cases
that
are
going
to
screw
things
up.
We
need
to
all
agree
on
like
what
are
the
disambiguation
things
right
like
what
are
the
disambiguate?
What
is
the
front
end
of
the
service
right
like
we.
D
On
if
we
can't
agree
on
what
the
front
end
of
the
service
is,
then
we
are
never
going
to
be
able
to
write
an
api,
because
we
all
have
different
ideas
about
what
a
service
is,
but,
like
the
you,
like,
you
can't
write
an
api
when
people
have
different
have
different.
You
know,
because
the
api
will
end
up
ambiguous
if
you
have
different
ideas
about
what
the
what
some
fundamental
concept
is
right
and
the
front
end
of
the
service
thing
that
the
thing
that
the
the
rules
target
right
is.
D
That
is
the
thing
that
we
need
to
agree
on
right,
so
the
binding.
The
reason
this
is
relevant
to
the
binding
discussion
is
that
if
you
can't
agree
on
what
the
front
end
of
the
service
is
and
what
because
then
you're
never
going
to
be
able
to
agree
on
how
to
bind
the
services,
because
the
services
must
bind
to
something
that
ends
up
as
at
the
front
end
of
the
service.
D
That's
what
that's!
Why
that's
why
I
introduced
this
topical
discussion
right
like
so?
That's!
That's
all
I'm
trying
to
say
is
that
you
I
I
think
I
have
just.
I
do
route
this
conversation,
I'm
sorry,
you
know,
but
like
I
think
that
there's
this
is
sort
of
the
fundamental
thing
that
that
is
important
to
understand.
E
Well,
I
I
think
we
agree,
we
are
not
completely
disreverent,
I
mean,
I
think
we
just
need
to
be
a
bit
flexible
because
you
know
proxy,
japanese.
In
other
cases,
we
may
not
actually
expose
an
ip,
but
that's
probably
implementation
specific
and
we
don't
have
to
worry
about
it.
But
I
agree
with
you
that
the
conceptual
level
is
that
you
have
a
service
name
that
will
have
a
beep
except.
C
C
F
B
B
I
don't
know:
is
that
unambiguous?
Is
that
ambiguous
to
people
on
the
call,
or
does
that
have
a
meaning
that
makes
sense
to
us
as
humans,
even
though
there
may
be
different,
you
know,
implementations
may
need
to
do
different
things
to
to
cause
that
reference
to
be
in
effect.
Did
that
question
make
any
sense
are.
B
A
What
I
I'll
just
briefly
say
that
this
is
kind
of
what
I
was
thinking
about
in
in
chat
where
in
my
head
I
was
doing
a
lot
of
conflating
between
host
name
and
front-end,
because
those
are
two
separate
jobs
that
are
happening.
One
is
a
disambiguator
like
for,
or
one
is
a
field
in
http
routing,
and
one
is
something
that
the
user
is
referencing
and
those
aren't
synonymous
most.
A
I
think
a
question
we
need
to
answer
is:
what
does
an
implementation
need
to
do
with
this
parent
ref
versus
this
back
and
draft
because,
like
what?
What
are
we
trying
to
signify
because
and
it's
a
little
different
with
mesh,
because
you
are
kind
of
you're
talking
with
two
into
internal
services?
So
what's
the
role
of
parent
ref?
In
that
reality,
I
think,
is
something
we
need
to
answer.
Let's
go
ahead.
Nick.
D
So
I
kind
of
agree
a
little
bit
with
what
lewin
said
in
the
chat
that,
having
the
same
thing
be
a
parent
ref
and
a
backhand
ref
feels
oddly
circular
to
me,
I
I
think
I
haven't
been
able
to
put
it.
In
those
words,
I
think
thank
you
and
for
writing
putting
it
in
those
words
that
that's
that
has
made
me
uncomfortable
the
whole
time
like,
but
the
the
circularity
of
having
the
same
thing
be
like
the
parent
of
the
tree
and
the
and
a
leaf
of
the
tree
is
really
weird
to
me.
D
I
know
at
a
conceptual
level
that
it's
that
we're
talking
about
like
the
front
end
versus
the
back
end
and
those
are
two
kind
of
distinct
things,
but
that's
what
I
think
I've
said
before
I
feel
like.
If
they're
two
distinct
things,
then
they
should
be
two
distinct
things
right,
like
there
shouldn't
be
one
thing
representing
two.
C
C
So
much
though,
in
our
implementation,
we
actually
have
two
ways
of
doing
it,
where
you
use
an
annotation
to
decide
whether
you
use
the
front
end
or
the
back
end,
as
we've
we've
called
it
out
in
these
docs.
This
is
a
problem.
I
think
that
needs
a
little
bit
more
definition,
not
just
for
mesh,
but
in
general,
in
gateway,
api.
A
I
agree
yeah,
and
I
think
that
to
your
point
and
nick
stanley
wins
like
the
the
the
service
parent
ref
is
seems,
definitely
seems
to
be
fulfilling
the
front
end
role
here
is
what
seemed
to
be
implied,
but
then
to
see
that
same
service
reference
as
a
back
end
is
is
strange,
and
we
need
to
be
clear
on
what
roles
is
service
fulfilling
in
any
given
usage.
B
E
It
is
a
bit
terrible
because
4v2
can
also
be
attached
to
http
route
and
then
it
may
forward
to
service
foo,
and
then
it
kind
of
gets
messy.
So.
D
E
Need
to
put
some
restrictions
of
how
deep
it
can
go.
I
mean
if
the
service
with
part
of
the
back-end
ref,
it
means
that
it's
a
back-end
rep
and
we
are
only
referring
it
as
a
collection
of
endpoints
and
it's
not
a
front-end
that
will
be
routed
if
we
can
make
this
disappear
to
the
user.
I
think
we
are
good.
D
So
I
think
the
yeah
I
think
it
has.
It
has
some
isomorphism
to
like
the
the
delegation
of
patient
appearance
I
like
which
we
talked
about
in
the
main
gateway
here.
I
think,
how
do
you
stop
there
from
being
like
an
arbitrary
nest,
a
number
of
things
and
then
because
if
you
have
an
arbitrarily
nested
number
of
nodes
and
if
they're
forming
a
graph,
then
having
cycles
in
that
graph
of
config
can
be
very
bad.
D
D
What
happens
right,
like
you
know,
and
there's
there's
no
easy
way
to
break
that
loop,
and
so
the
yeah,
like
the,
and
I
think,
yeah,
that
luin
has
pointed
out
that
the
personas
the
personas
are
are
tricky
the,
and
I
think
that
that's
a
really
good
thing
that
that
I
actually
had
on
my
mental
list
of
things
to
talk
about
and
it
slipped
out
that
the
personas
can
really
help
us
focus
in
here
about
like
who
owns
the
config,
and
then
that
tells
you
where
it
should
live
right,
like
that.
D
You
know,
if
you
think
about
who
owns
the
the
config
of
the
mesh
versus
who
owns
the
config
of
the
the
front
end
of
the
service,
then
that's
a
good
way
to
break
up
like
where
those
things
should
live
and
what
resources
they
should
be
right,
like
I
think,
we've
had
a
few
mentions
here
to
like
what
happens.
If
you
have
this
reference
across
namespaces,
I
think
it
is
absolutely
key
that
a
lot
of
this
stuff
does
not
allow
crosstalk
space
references.
It
has
to
live
in
the
same.
D
C
D
To
sort
of
refer
to
a
back
end
across
namespaces
because
there's
a
ticket
to
like
crazy
amounts
of
stuff
about
who
owns
what
and
that's
that
comes
back
to
the
you
know,
who
owns
the
config
and
who
and
who
should
be
responsible
for
the
different
parts
of
the
conflict.
A
B
Part
of
way,
early
on
what
I
was
saying,
so
you
know,
I
would
actually
propose
that
we
start
by
saying
we
don't
have
a
mesh
resource.
We
don't
have
a
mesh
class
resource,
see
how
much
trouble
we
get
into
some
of
that
has
to
do
with
that
difference
in
personas
we
were
talking
about.
B
It
enables
us
to
focus
on
one
persona
and
really
zero
in
on
that
and
play
with
it
for
a
bit,
and
especially
because
I
don't
think
it's
very
difficult
for
me
personally
to
see
a
strong
use
case
for
mesh
and
mesh
class
until
we
are
talking
about
a
world
in
which
you
can
run
multiple
meshes
in
a
cluster
which
is
a
non-goal
right.
This
second
or
a
deferred
goal
right.
D
So
I
don't
disagree
but
in
my
mind
the
the
split
of
the
personas
that
makes
the
most
sense
to
me
is
that
the
cluster
administrator
owns
the
mesh,
even
if
there's
only
one
in
the
mesh
and
so
the
cluster.
The
custom
administrator
is
a
different
person,
a
lot
of
the
time
to
the
application
developer.
E
D
D
It
means
that
you
have
a
really
clear
split
between
the
thing
that
is
owned
by
the
mesh
by
the
by
the
cluster
operator
and
the
thing
that
is
owned
by
application,
and
that's
one
of
the
reasons
I
tend
to
favor
those
things.
I'm
not
saying
we
should
sort
of
settle
that
now.
I
just
wanted
to
have
said
that
that's
the
way.
A
Yes,
I
love
async
going
to
have
to
cut
things
off.
There
is
recommended
over
time,
but
really
appreciate
it,
everybody
I
it
sounds
like
to
me.
The
action
items
here
for
folks
to
discuss,
asynchronously
and
and
just
be
thinking
about,
is
to
dig
into
the
personas
and
think
about
parent
ref
and
in
in
the
context
of
service
binding
and
what
the
persona
split
is
and
what
are
the
implications
of
one
on
the
other.
We've
got
a
couple.
A
You
know
several
different
approaches
here,
some
with
a
cluster
sculpt
mesh
resource,
some
with
a
service
resource,
some
with
a
service
binding
resource
that
we
didn't
get
to
and
the
even
what's
the
perspective
of
that
service,
binding
resource
is
not
is
immediately
clear.
A
Even
so,
there's
a
lot
of
this
good
stuff
to
dig
into
I
I'm
gonna
leave
this
document,
as
is,
and
I
would
love
to
chat
with
folks
in
slack
on
github
discussions
or
or
wherever
in
comments
here
on
the
dock,
and
just
let's
throw
a
lot
of
questions
at
this
and
see
and
see
where
these
break
or
these
break
down.
I
had
a
lot
of
discussion
today
over
just
one
of
these,
so
let's
keep
that
going.
The
next
meeting
will
be
on
september
13th
at
8
a.m.
A
Pacific
time,
looking
forward
to
seeing
those
of
you
who
can
make
it
then,
but
we're
done
thanks.
Everybody.