►
From YouTube: Ambient Mesh WG Meeting 2023 05 17
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
All
right
so
I
this
was
under
the
future
topics,
and
is
this
Ian.
B
This
was
just
in
response
to
Lynn's
topic
from
last
week
of
getting
ambient
mesh
to
Beta.
I
just
wanted
to
sort
of
take
the
temperature
of
the
community
early
on
whether
we
would
tolerate
having
like
release
candidate,
Forks
or
or
forked
crates
in
Z
tunnel
at
beta,
and
if
that's
okay,
then
we
don't
need
to
track
it.
But
if
that's
something
that
folks
feel
strongly
about,
then
we
should
probably
track
it.
C
I
think
it's
definitely
not
great,
but
if
they
hyper
doesn't
or
at
least
1.0,
then
hey
I,
don't
you
know
I
don't
want
to
take
a
hard
dependency
on
on
someone
else.
If
foreign.
C
B
Yeah
I
think
that
makes
sense.
The
intent
was
really
just
so
that
nobody
was
surprised
by
this
in,
like
the
last
weeks
before
we
were
trying
to
go
to
Beta
just
make
sure
everyone's
aware,
so
they
can
speak
up
if
they
feel
strongly.
C
C
Says
safety
for
production
use
I,
don't
know
if
they
really
claim
that
for
hyper
1.0,
yet
I'm
guessing
they'll
make
progress
by
the
time
we
go
beta.
But
it's
hard
to
say.
B
C
C
It's
all
like
migration
type
work
like
upgrade
guides,
deprecating
things
adding
like
they're
doing
like
some
shims
to
make
transition
easier,
so
they're
like
backboarding,
some
of
the
1.0
stuff
into
the
Old
Branch,
so
that
you
can
kind
of
do
a
smoother
upgrade
things
like
that.
They
have
a
big
like
get
aboard
and
stuff
that
they're
trying
to
get
directions
on.
As
far
as
I
know,
it's
just
like
kind
of
things
that
anyone
could
do.
B
Yeah
I
think
John's
right,
A
lot
of
the
stuff.
They've
said
like
we're
hoping
for
contributions
and
and
if
it's
something
that
we
see
value
in
you
know
as
the
as
the
istio
community,
then
then
I
think
John's
right.
We
can
look
to
make
those
contributions.
We
we're
developing
that
that
rest
expertise
in
the
community.
A
All
right
sounds
a
lot
like
that's
a
no
does
anyone
else
in
the
community
have
things
to
discuss.
F
Keith
yeah
I'll
I
have
to
have
a
quick
question
around
the
this
goes
back
to
Lynn's,
strap
ambient
match
to
betadoc
I'd
like
to
do
some
stuff
to
help
out
with
the
apis
part
of
it.
F
I
know
that
we
did
some
special
last
week
on
authorization
policy
in
the
direction
there,
but
the
call
to
action
for
the
API
section
of
that
doc
refers
to
another
doc
called
API,
so
I
know
John
and
Lynn
worked
on
at
one
point:
there's
a
lot
of
information
in
that
Doc
and
it's
really
difficult
to
tell
what
is
you
know,
what's
been,
what
has
consensus
What's
Done
Etc
can?
F
Is
there
any
hope
of
that
dock
being
updated
in
in
cleaned
up
or
should
I
just
shouldn't
just
start
pulling
things
out
of
that
dock
into
separate
dots
for
review?
For
example,
I
could
take
the
information
for
authorization
policy
and
put
that
in
a
separate
dock.
Do
you
think
that
would
help
things
move
quicker
because
it's
just
trying
to
figure
out
where
the
work?
Thank
you.
C
And
then
it's
somewhat
worried
about
splitting
out
the
dock,
because
they're
all
kind
of
coupled
I
say
we're
doing
parent
refund
authorization
policy.
We
ought
to
do
it
on
request
authentication
for
example,
but
certainly
contributions
to
the
doc
would
be
the
full
I
did
say:
I
was
going
to
go
clean
it
up
a
bit
and
then
I,
Didn't,
Do,
It
I.
Think
other
said
that
they
were
going
to
review
it
and
there's
no
comments.
C
So
so
we
definitely
need
some
more
more
attention
on
it,
but
I'm
not
sure
that
new
docs
is
the
solution
necessarily.
D
One
thing
that
may
be
useful
is
to
start
a
samples
directory
or
test
directory
and
put
everything
that
is
supported
in
in
ambient
in
in
yaml
files
that
are
made
easier
to
understand
and
kind
of.
So
we
kind
of
have
a
visual
effect
and
and
kind
of
we
can
even
test
the
particular
configurations
exist
and.
D
Because
there
are
not
so
many
of
the
apis
I
think
I
mean
it's,
it's
kind
of
it
will
be
useful
also
for
the
users.
F
Okay,
so
I
will
go.
There
are
lots
of
old
comments
on
the
dock
on
the
8bit
API
stock.
Specifically
I
will
link
that
in
the
meeting
notifications
I'm
talking
about.
F
E
Don't
you
think
it
would
make
sense
to
do
schedule
a
walk
through
at
the
dock,
for
anyone
who
wanted
to
participate.
E
Like
or
like
you
said,
there's
a
lot
in
there
yeah.
It
would
be
hard
to
cover
it
in
this
meeting.
C
A
We
have
45
minutes.
C
Was
there
any
hidden
agenda
items
anyone
want
to
discuss
or
if
not
I
say
we
go
for.
D
E
C
E
And
so
there
are
two
ways
to
exchange
this
information
right,
because
we
need
this
information
to
produce
useful
Telemetry,
login
and
so
on
and
so
forth.
Right
one
is
to
send
this
information
around
in
the
data
path,
and
the
second
option
is
to
look
it
up
from
some
Central
Authority
and
not
pass
around
the
data
path
right.
E
D
No
I
want
to
say
it's
not
exclusive,
so
I
think
there
are
a
lot
of
discussion
about
Telemetry,
where
we
are
asked
to
pick
a
choice,
but
Telemetry
is
kind
of
fluid.
It's
it's.
If
the
peer
is
sending
baggage,
we
obviously
should
read
honor
it
and
take
information
to
the
baggage.
If
the
client
is
not
an
istio
client
is
not
sending
baggage.
What
can
we
do?
I
mean
we
should
definitely
have
some
way
to
look
up
telemetry
to
something.
E
E
Well,
we
don't
have
it
right,
we're
trying
to
choose
our
options
here.
Yeah
and
I
generally
agree
with
costan
about
the
approach
of
use
it.
If
the
data
path
gives
it
otherwise,
look
it
up
from
an
authority.
E
E
If
it's
not
provided
in
the
data
path,
doesn't
see
a
lot
of
information
about
the
origin,
then
the
amount
of
telemetry
that
you
get
is
restricted
right.
It's
restricted
to
what's
in
the
the
certificate
handshake
right,
so
there's
a
kind
of
there's
a
tiering
of
fidelity
of
information
about
peers
in
the
exchange
where
the
minimum
guaranteed
amount
is
well.
If
they're
participating
in
an
mtls
handshake,
the
minimum
amount
is
in
the
the
client
the
peer
presented
certificate.
E
E
E
D
G
Why
this
work
was
motivated
is
because
we
already
ignore
package
in
the
mesh
at
ambient
Z
tunnels,
because
we
trust
IPS,
so
we
send
baggage,
but
we
don't
use
it.
So
it's
best,
then,
for
that
already
and
I
think
we
also
need
better
controls
about
between
networks
and
clusters.
I
agree
about
that,
and
it
should
be
something
that
is
more.
G
You
know
not
not
on
and
off
it
has
to
be
about
which
destination
it's
going
to,
because
I
think
there's
also
a
requirement
to
not
send
the
package
two
destinations
that
don't
need
them
and
to
have
this
fine
gain
controls.
We
need
a
solution
that
basically
doesn't
require
baggage
in
general
and
only
uses
it
sometimes.
A
A
E
A
G
E
D
Yeah
I
I
think
this
whole
proposal
about
doing
the
metadata
exchanges,
probably
far
more
important,
waypoints
and
gateways
where
we
have
a
lot
of
short
HTTP
requests.
I
mean
I,
don't
think
the
overhead
of
baggage
in
in
Connect
is
a
big
deal
and
connect
probably
is
going
to
be
used
by
zitana
I
mean
it.
It's
probably
lower
priorities
than
than
solving
the
problem
for
for
the
high.
D
You
know
certain
requests
in
and
if
we
have
an
implementation
of
the
metadata
exchange,
probably
we
can
just
use
it
because
it's
probably
the
most
useful
since
it
works
with
non-esteo
workloads
and
it's
lower
overhead
and
simpler
and
drop
the
baggage
until
we
have
a
more
concrete
use
for
it.
What
do
you
simply.
C
F
C
One
issue
with
that,
though,
is
that
we
don't
it
doesn't
work
with
multi-network,
because
we
don't
know
if
the
request
is
from
our
Network
or
not.
So
we
get
some
IP
address
and
we
look
it
up.
But
who
knows,
you
may
not
know
yeah,
we
may
just
get
the
we
may
say
it
knows
what
this
IP
address
is,
and
it
returns
a
bunch
of
billias.
D
But
John
it
is
not
bogus
ever
I
mean
it's
always
either.
You
know
something
that
your
pilot
knows
about,
because
it's
in
your
network,
you,
you
cannot
have
you
know
a
request:
go
between
board
a
and
Port
B
into
different
networks
directly
either
they
are
in
the
same
flat
Network
or
they
are
not.
If
they
are
not.
It
goes
through
the
to
the
east
west.
C
C
We
need
to
pass,
we
don't
even
know
well
two
things,
one.
We
don't
even
know
that
it
should
be
in
the
other
network
that
we
should
look
up
because
we
just
get
the
IPS,
so
we
could
fix
that.
But
then
we
have
to
have
the
client
tell
us
what
network
they're
in
we
also
have
to
tell
them.
Have
them
tell
us
what
their
IP
address
is
in
the
client
request,
because
it's
tunneled
through
the
other
thing
that
as
far
what
Lou
was
going
to
say,
is
that
there's
split
brain
potentially
so.
E
D
E
Yeah,
no,
no
so
I
I
think
the
only
question
right
now
is:
we
need
some
signaling
mechanism
from
the
control
plane
to
the
data
plane
to
tell
it
to
use
baggage
in
certain
cases
right
what
what
are
those
cases
today
right?
So
we
we
say
that
for
a
given
endpoint
that
we're
trying
to
reach
or
a
gateway,
we
have
to
tell
Z
tunnel
whether
to
emit
package
or
not
right.
It's
pretty
simple
right.
What
the
constraint
is
right,
Z
Tool
is
supposed
to
be
pretty
homuncular
right.
It's
just
like
it
does.
What
it's
told.
D
I
I
I
would
I
would
restrict
it
a
bitly
to
say
that
who
should
emit
this
package.
Maybe
it's
it's
only
for
multi-network
cases.
I
don't
want
to
to
do
kind
of
so
if
it
has
to
go
to
a
multi-net
or
maybe
we
can,
since
we
anyway,
we
know
you
need
to
forward
to
the
special
Gateway.
D
E
C
G
C
No,
that's
not
always
possible,
they
can
send
if
they
choose
to
not
send
it.
The
server
may
not
get
Telemetry.
They
may
not
be
happy
about
that,
but
in
many
cases
they
can
probably
look
it
up
for
metadata
server
like
I'm,
not
sure
how
not
sending
the
baggage
makes
it
better
that
clients
don't
send
the
baggage
the
end
result's
the
same.
We
don't
have
the
baggage
right.
We
already
know
that
we
cannot
rely
only
on
metadata
lookup
for
split
brain
cases
right.
E
So
do
we
have
a
right,
so
the
concrete
answer
would
be
performance
right,
like
it's
too
expensive
to
it,
but
right
now
we
don't
have
any
evidence
that
it's
actually
concretely
too
expensive,
so
I
kind
of
agree
with
John.
But
unless
we
have
evidence
that
it's
a
real
performance
overhead,
we
should
probably
send
it
now.
We
could
have
a
debate
about
the
how
we
send
it
right
now,
right
and
obviously
their
interoperability
issues
with
the
various
options.
A
G
E
C
C
I,
don't
think
it's
fair
I
I,
don't
think
they're
equivalent,
because
one
is
tied
to
an
HTTP
request
which
is
cheap
and
the
other
is
tied
to
a
connection
which
is
expensive
and
we're
not
sending
eight
kilobytes
in
baggage
right.
It's
it's
a
much
smaller
set,
which
maybe
means
that
we're
not
putting
enough
in
baggage,
which
maybe
is
another
problem,
but
at
least
right
now
we're
only
setting
I
think
four
attributes.
G
C
G
D
G
D
G
C
But
that
was
it's
kind
of
Apple's
oranges
right
that
was
not
baggage
that
was
protoba
for
flat
buffer,
whatever
whatever
we
ended
up
using
it's.
E
C
E
It's
what
it
seems
like
here
is
that
we
actually
need
an
evolvable
mechanism
for
describing
how
we
want
to
exchange
package
right
because,
like
there
are
lots
of
different
ways
to
do
the
exchange
in
the
data
panel
right,
like
once
per
request
once
per
TCP
connection,
once
per
Tunnel
right
once
per
pre-negotiated
IP
right
because
right-
and
they
all
depend
on
the
originator,
knowing
some
information
about
the
destination
to
choose
the
optimal
baggage
exchange
mechanism.
Right.
D
I
I
I'm,
less
worried
about
performance
and
more
worried
about
interoper
and
insularity
of
you
know,
defining
yet
another
not
invented
here
protocol
and
system
for
multi-network
Keys,
which
is
only
case
where
baggage
may
make
sense.
Maybe
we
should
take
a
look
at
the
existing
standards
and
not
use
baggage
for
this
particle,
I
mean
what
you
proposed
Louis
with
sign
jot
and
other
things
may
be
very
valid
Federation
it's.
You
know
something
also
we
want
to
explore,
but
at
least
for
single
Network
do
we
have
any
reason
to
keep
using
package.
E
So
I
think
right.
Basically,
we
have
an
array
of
baggage
exchange
mechanisms
that
needs
to
evolve
based
on
based
over
time,
and
we
have
two,
maybe
that
we
want
to
support
initially
right,
one
which
is
the
just.
We
send
it
all
the
time
in
HTTP
connect
as
a
header
and
the
other
is
we
don't
send
it
and
you
would
get
it
from
you're
expected
to
get
it
from
the
metadata
server
and
then,
if
we
need
a
third
one,
because
people
are
complaining
or
the
performance
overhead
is
sending
in
Connect
all
the
time
is
too
much.
E
C
D
So
like
entirely,
not
always
I
mean
it's
it's
it
in
multi-network.
If
you
have
split
brain
order,
I
mean
it
is
that
it's
I
think
the
idea
of
how
to
find
metadata
would
appear
once
the
internet
in
general.
In
the
general
problem.
It's
a
very
complicated
one,
and
it
has
some
solutions.
I
mean.
Typically,
you
do
PTR,
you
do.
You
know
geolocations.
There
are
kind
of
Solutions
in
place
to
get
metadata
about
your
appear
on
the
internet
and
that
broadly
use
their,
not
perfect.
Of
course,
we
are
probably
in
the
same
situation.
D
I
mean
either
we
are
centralized
and
istio
D
can
know
the
history
from
the
other
network
can
get
metadata,
and
you
know
you
have
a
discovery
server
that
is
across
the
mesh
and
then
we
have
no
problem
or
we
are
in
this
kind
of
split
brain.
You
know
uncorporating
Federated
untrusted,
they
don't
trust
each
other
and
we
need
what
we
said
initially
I
mean
some
jot
and
and
some
more
integration
yeah.
What
what
baggage
from
boundaries
is?
Probably
the
right
solution
but
I,
don't
not
necessarily
our
baggage.
D
We
need
to
look
up
for
for
more.
You
know
how
metadata
is
derived
on
the
wild
internet
if
we
are
in
this
situation,.
C
I
would
be
fine
with
the
news
baggage
only
for
cross
Network
I.
Think
that
sounds
a
little
well
in
my
minor
solves
a
lot.
I
can
sense
of
this
product.
That
talked
about
an
answer,
but
in
terms
of
performance,
the
overhead
of
crowd
crossing
a
network
is
already
large,
much
larger,
so
adding
a
little
bit
more
on
that
doesn't
seem
terrible
and
the
other
concern
I
think
was
that
clients
need
to.
C
It
raises
the
bar
for
clients,
but
the
bar
to
do
multi-network
as
a
client
is
also
higher
than
normal
communication,
so
I
mean
in
some
sense
it's
like
these.
Two
things
are
already
bad,
so
why
not
make
it
a
little
bit
worse,
but
it's
reasonable,
so
I
I
wouldn't
mind
that
approach.
One
thing
I
will
say
is
we
had
previously
said
we
would
trust
metadata
server
over
baggage
I.
Think
in
order
to
do
this,
we
would
probably
always
trust
baggage
if
it's
there.
C
Otherwise,
we
need
no
way
for
the
client
to
tell
us
what
network
they're
from
which
is
a
little
wonky,
because
otherwise
we
may
we
may
incorrectly
look
something
up,
but
otherwise
I
think
it
makes
sense.
Personally,.
E
E
So
the
only
thing
I'm
a
little
bit
worried
about
is
being
prescriptive
about
the
boundary
definition
like
same
network
or
not
same
network,
same
cluster,
not
same
cluster
I.
Think
we
want
to
be
a
control.
Planes
may
vary
right
and
how
they
make
that
interpretation
and
I
think
we
want
to
allow
for
that
variation
and
the
way
to
do
that
is
still
to
put
this
into
the
API.
C
E
So
let's
say
you
have
two
very
large
clusters
on
the
same
network
right
and
you
don't
want
to
replicate
endpoint
Discovery
between
them
all
right.
So
right
each
is
dude.
Each
sdod
is
only
reading
its
local
cluster
right
and
then
I
use
service
entry
to
expose
an
endpoint
in
the
other
network
in
the
other
cluster.
It's
still
in
the
same
network
right.
So
it's
not
about
the
network
boundary
anywhere.
E
C
E
D
One
of
the
discussions
on
the
side
channel
was
about
IPS,
as
you
know,
not
very
good
identities
and
so
forth,
and
now
we
are
discussing
remedy
and
you
know,
cross
namespace
and
cross
network
with
overlapping
IPS,
and
all
that
should
we
consider
putting
the
board
the
host
name.
The
fully
qualified
hostname
with
some
mechanisms
to
identify
clusters,
always
is
a
request,
is
different
from
from
baggage
I
mean
it's
not
about
arbitrary
Telemetry.
D
It's
that
you
know
universally
unique
and
you
know
kind
of
fully
qualified
identity
of
each
peer
from
each
you
can
you
can
look
up
and
and
do
other
things.
D
Yes,
probably
there
as
well,
but
again,
the
multiple
identities
we
use
IP
for
some
things.
We
use
host
names,
we
use
speaker
certificate,
I
mean
it's
normal
for
something
to
have
multiple
identities,
but
from
protocol
level
I
mean,
since
we
are
discussing
what
should
be
in
the
in
the
headers
or
not.
D
Log
it
use
it
to
look
up.
Normally
is
a
protocol
I
mean
you
know.
When
you
do
connect,
you
have
fully
qualified
hostname,
not
IPS
and
so
use.
We
had
some
discussion
before
with
John
I.
Don't
think
we
reached
a
conclusion
or
agreed,
but
it's
clear
that
when
you
do
connect,
many
systems
use
fully
qualified
host
names,
not
IPS
and
Authority
or
or
part
of
the
payload
outside
of
history.
I.
D
D
E
The
example
example
I
just
gave
right
where
the
Clusters
were
independent,
they
could
talk
because
they
were
part
of
the
same
identity
domain.
They
were
on
the
same
network.
They
had
asymmetric
knowledge
of
each
other.
How
do
you
guarantee
that
their
identities
don't
collide?
What
I
can
see?
Would
you
use?
Yes.
D
That's
that's
a
that's
an
important
part
of
of
what
I'm
talking.
We
need
some
way
to
name
the
the
Clusters,
as
you
know,
instead
of
in
class
of
local
everywhere,
to
give
us
their
way
to
your
you
know.
Each
cluster
has
a
name
in
our
system
that
is
unique
because
how
multicluster
is
implemented,
and
so
basically
each
of
them
will
get
its
own
suffix.
D
If
you
look
at
there
is,
there
is
a
now
GK
feature
to
have
vpc-wide
DNS,
where
again
each
cluster
is
named,
and
then
it
you
get
a
really
unique
fully
qualified
domain
name.
E
D
Yes,
this
can
be
integrated
with
DNS
properties,
but
I
think
we
are
kind
of
doing
it
for
users
because
remember
cluster.
The
cluster
name
is
actually
part
of
internalized
implementation.
We
always
have
inject
the
cluster.
We
always
pass
the
cluster,
it's
using
authentication,
because
that's
how
we
validate
the
jot
token.
So
doctor
we
have
a
cluster
names
that
it's
you
know
the
secret,
the
part
of
the
secret
that
is
driving
multi-clusters.
E
D
D
A
D
E
Well,
baggage
still
allows
us
to
have
consistent,
Telemetry
right,
like
as
long
as
we
can
say.
We
need
baggage
to
be
exchanged
in
these
situations
right.
That's
why
I'm
arguing
for
having
this
be
a
feature
of
the
control
plane,
because
then
we
can
choose
that
the
control
plane
can
make
that
decision.
C
E
C
E
C
C
C
C
C
E
E
The
only
information
you
have
is
what's
in
this
search
right,
so
you
have
a
limited
baggage
and
then
your
Telemetry
system
has
to
adapt
to
limited
baggage
such
as
it
is,
and
we
can
try
and
address
making
limited
baggage
have
better
Fidelity
by
putting
more
stuff
into
the
search
right
which
deposits
appeal
like
because
it's
verified,
it's
signed,
right,
dot,
dot
and
you
know
it's
not
like
certs
aren't
already
fast
and
they're
exchanged
like
cert
is
the
logical
place
for
all
of
this
to
go
right.
E
It's
a
unified
identity,
main
it's
exchanged
once
by
each
peer
and
the
flow
right.
It
has
the
right
life
cycle,
semantics
identity
shouldn't
be
switching
unless
the
cert
is
actually
rotated
right,
like
it
has
all
the
right
properties.
The
problem
is,
how
do
you
put
it
in
there
right
and
standardizing
that
with
a
bunch
of
different
Cas
that
may
or
may
not
want
to
do
it,
but
right?
That's
it
right.
Everything
else
is
a
workaround
to
the
fact
that
we
can't
put
it
in
the
cert,
or
we
can't
put
it
inefficiently.
F
A
E
E
E
D
E
E
E
D
Yeah
no
I
agree,
I
think
it's
it's
a
pretty
complicated
problem
in
the
most
General
case,
but,
of
course,
to
get
started
and
for
the
initial
stuff,
since
I,
don't
think
was
about
multineto
right
now,
I
think
we
can.
We
can
make
some
progress
with
the
simplified.
E
G
E
D
A
E
If
we
can
set
like
reasonable
answers,
the
other
three,
the
three
parts
and
when
we
test
it,
it
provides
good
coverage
for
typical
scenarios.
Then
I
think
it's
reasonable
to
take
it.
A
D
C
Yeah
I
think
my
biggest
open
question
is
like
how
we're
actually
going
to
program
this
I'm,
not
usually
in
favor
of
putting
things
in
the
XDS
API
that
have
nuclear
configuration
for
them,
but
in
general,
I,
think
I'm.
On
the
same
page,.
E
E
G
E
G
I
think
it
would
be
weird
if
open
telemeter
collectors
have,
you
know,
listens
to
work
like
Discovery
routing,
because
it's
just
somewhat
unusual,
but
also
the
schema
might
need
to
be.
You
know,
adjusted
depending
on
what
what
we
agree
together
might
need
to
use
an
open,
Telemetry
names
for
certain
Fields,
because
that's
the
standard.
E
Right
I
mean
right
now
what
we
did
in
the
work
of
the
discovery.
Api
is
we
put
workload
metadata
into
its
own
message
right
so
that
it
could
somewhat
evolve
separately
and
including
the
nomenclature
right,
so
we
should
be
able
to
bring
that
message
and
the
hotel
requirements
into
alignment.
E
So
maybe
you
want
to
go
and
make
proposed
some
updates
to
that.
At
least
that
brings
that
part
of
the
schema
into
alignment.
Even
if
the
outer
structure
is
not
ideals,
so
they
would
be
closer
together
because.
G
Well,
I
also
don't
want
to
have
premature.
You
know
decision
made
so
I
think
it's
okay
to
for
this
API
to
evolve
first
and
then
we
can,
you
know,
adjust
later
okay,
I,
don't
know.
What's
the
your
desire
for
the
compatibility
I
think
it's
pretty
hard
to
make
sure
the
first
version
of
apis
is
the
right
one.
Anyways.
E
Yeah,
that's
true!
Well,
let's,
like
let's
just
flag
the
fact
that
we
would
like
to
adopt
or
align
with
Hotel
semantics
and
Syntax
for
the
metadata
portion
of
the
API
or
at
least
go
through
that
process
right.
So
it
looks
the
same
Ben
to
answer
a
question
right,
I
think
it's
not
for
collectors,
not
Hotel
collectors.
E
It's
for
other
agents
that
participate
in
the
data
path
that
are
not
necessarily
Z
tunnel
to
be
able
to
do
this
right,
because
they're
going
to
need
to
fetch
metadata
about
their
peers,
so
that
then
otel10
collects
the
stats
that
they
emit
right.
So
they
need
an
API
to
do
that
right.
It's
it's!
The
it's!
The
reverse,
DNS
lookup
with
right.
F
E
G
D
E
E
So,
let's,
let's
stick
with
our
one
API,
but
let's
try
and
bring
it
into
alignment
with
the
the
conventions
of
hotel.
If
we
can
and
just
put
them
like
put
some
documentation
on
the
API
talking
about
how
this
might
be
used
for
other
use
cases
and
and
then
we
can
have
a
broader
conversation
with
the
community
and
see
how
that
discussion
evolved.
E
E
E
D
That's
that's
a
bit.
You
know
there
are
different
specs
different
lists
of
names
and
different
levels
of
stability
and
tracing
is
super
well
defined
and
stable.
There
is.
There
are
specs
for
a
lot
of
things
with
different
level
of
implementation
of
adoptions.
That's
really
the
problem.
E
D
A
G
D
Yes,
we
need
an
organization,
basically
I,
don't
know
if
cncf
owns
some
organizational
oid
name
for
ASN,
but
Google
at
least
is
using
its
own
Google
Pandora
to
add
support,
name
and
other
things.
So
it's
it's
either
a
vendor
donates
and
oid,
or
we
have
an
organizational
to
ID.
E
E
D
A
E
I
thought
all
the
the
reasonable
start.
Libraries
would
expose
all
of
the
ASL
anyone
names
items
in
the
search
and
their
values.
They
don't
process
them,
they
don't
interpret
them
right.
That's
the
that's
the
thing
that
would
be
dangerous
from
a
security
perspective
right.
G
G
G
E
D
D
E
E
If
we
can't
put
it
in
the
handshake,
the
only
other
place
is
to
put
it
as
an
internal
API,
and
we
know
that's
the
thing
that
will
interrupt
the
least
right,
because
you'd
have
to
persuade
Envoy
to
implement
this.
You
know:
exchange
metadata
endpoint
inside
the
tunnel,
write
a
post
method
right
that
had
some
well-known
semantics.
E
D
Yeah
I
I
agree.
Maybe
we
should
also
look
back
to
the
to
the
Federation
ideas
where
we
standardize
some
way
to
Federate
the
reverse.
Lookup,
like
the
proper
PTR
in
DNS.
E
A
D
E
Like
we
have
that,
but
right,
and
so
we
can
Define
the
scope
in
which
that
will
work.
But
we
also
can
Define
situations
in
which
it
won't
right,
where
we
have
asymmetric
knowledge
of
endpoints
and
their
metadata,
and
that's
going
to
force
us
right.
Then
you're
into
like
Loosely,
coupled
Federated
systems
and
like
gossip
protocols
and
all
that
kind
of
stuff
right
and
that's
a
lot
of
complexity.
On
top
of
a
situation
where
we
already
have
a
top-down
allocator
of
IDs
right.
That
works
in
a
Federated
manner,
which
is
the
ca
system.
E
E
D
Yeah,
what
what
let's
discussed
with
a
spiffy
and
having
if
only
spiffy,
was
a
wordproof
identity.
We
would
have
you
know
a
fully
qualified
name
in
certificate
and
we
could
use
it
to
look
up.
But
it's
a
service
account
and
that's
not
helping
too
much.
D
E
So
I
still
suggest
we
take
a
harder
look
at
Circ
offline.
We
can
try
to
capture
some
of
that
in
the
GitHub
issue.
E
And
we
can
see
what
we
can
reuse
and
we
can
see
where
there
are
gaps,
and
we
can
see
what
existing
metadata
mechanisms
that
we
can
use
without
necessarily
breaking
everybody
right,
because
that's
the
problem
with
search,
obviously
is
there's
some
parser
out
there
that
doesn't
like
a
field
and
decides
to
blow.
D
E
But
okay,
so
if
folks
have
other
ideas
about
baggage
exchange,
please
put
them
on
the
GitHub
issue.
I
think
there's
like
three
or
four
different
options
already
captured
there,
and
we
may
need
to
turn
that
into
a
dock,
to
get
all
the
eyeballs
on
it
to
see
how
the
community
feels
about
it.