►
From YouTube: 2023-01-17 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
B
Okay,
I
think
we
can
give
people
another
minute
or
so,
but
I
went
ahead
and
put
some
agenda
items.
If
anyone
else
has
relevant
agenda
items
anything
to
bring
up,
please
add
them.
Now.
B
B
Let's
go
ahead
and
dive
in
so
the
first
kind
of
item
Tyler.
Maybe
you
or
Anthony
can
speak
to
this,
but
I
just
wanted
to
make
sure
we'd
capture
any
discussions
or
any
kind
of
crossover
from
the
previous
e-related
meeting,
and
then
some
feedback
I
got
from
that
meeting
as
well.
B
I
said
it
might
potentially
help
to
give
them
a
defined
lifestyle
topics
or
some
sort
of
agenda
we'd
like
some
of
their
feedback
on
so
you
know
in
this
meeting
we
should
put
together
some
some
sort
of
list
that
we
want
some
additional
feedback
on,
but
yeah
Anthony
tell
her
anything
from
last
week.
C
D
D
E
C
I
think
the
the
place
where
we
potentially
need
more
discussion
is
around
the
the
shape
of
that
event
to
carrier
cloak.
You
know
whether
we
want
to
have
that
what
should
be
the
bounds
so
like
go
has
event
to
carrier,
but
I
think
node
has
events
to
context
or
something
similar
to
that
which
goes
one
step
further
and
applies
the
propagator
in
in
one
go.
So
how
do
we?
How
do
we
specify
what
the
bounds
of
that
is,
so
that
we
can
have
consistency
across
implementations.
D
So
my
my
preference
or
my
my
recommendation
would
be
to
have
the
specification
not
include
that
at
all
and
that
this
event
to
carrier
verbiage
could
be
implementation
specific.
It's
not
like
it.
It's
an
abstraction
that
I
think
is
encapsulated
well
and
doesn't
really
need
to
leak
out
of
the
ins.
The
instrumentation.
C
So
I
think
one
of
my
objectives
here
is
to
have
consistency
amongst
the
implementations
of
the
Lambda
instrumentation
across
various
languages,
so
I
think,
to
the
extent
that
they
are
exposing
to
end
users
Hooks
and
interfaces
to
interact
with
the
its
rotation.
Those
should
be
consistent.
D
D
Okay,
so
maybe
maybe
we
can
clarify
by
end
user
I
think
somebody
that
is
actually
running
the
application,
not
necessarily
the
one
that
is,
writing
the
instrumentation.
C
D
So
what
what
cases
would
they
need
to
interact
with
that
unless
they
were
writing
the
instrumentation.
D
D
They
they
likely
care
about
and
want
to
have
visibility
into
it,
but
I
feel,
like
the
implementation
of
this
event
to
carrier,
isn't
something
that
they
likely
care
about.
B
I
think
this
topic
clearly
needs
a
bit
more
discussion
and
maybe
some
wider
Sig
involvement-
I'll
be
honest:
I
don't
have
the
full
context
of
it,
so
I
can't
fully
contribute
to
it,
but
if
we
could
maybe
do
some
work
to
kind
of
share
the
current
state
and
if
people
could
take
some
time
to
review
this
issue,
we
can
discuss
more
either
at
the
end
or
offline
about
what
we
want
to
do
here.
B
Are
there,
could
you
all
share
a
little
bit
about
the
fast
demo
for
a
second,
not
sure
if
that
was
discussed
in
depth,
but.
C
Yeah
so
I
think
the
the
question
here
was
around
should
we
be
looking
to
add
functions
as
a
service
as
part
of
the
existing
Hotel
Community
demo,
or
should
we
be
looking
for
additional
Standalone
demos
that
can
be
used
to
illustrate
how
to
use
these
rotations
we're
providing
in
a
context
that
isn't
quite
as
large
as
the
the
community
demo
yeah.
B
One
thing
we
talked
about
previously
with
a
community
demo
is
actually
having
like
implementations
of
it
available.
So
there
would
be
like
an
AWS
kind
of
set
of
scripts.
So
then
we
can
Azure
set
of
script,
so
it
would
actually
deploy
to
like
the
full,
like
resource
set
and
not
just
essentially
the
kubernetes
like
a
container
or
a
Docker,
or
something
like
that.
So
I
think
we
definitely
would
be
interested
in
talking
about
it.
B
I'd
be
curious,
you
know
how
that
would
actually
work
or
what
y'all's
preferences
would
be,
but
yeah
I
think
the
demo
six
probably
open
to
discussing
it
at
least
and
seeing
what
we
can
do
to
help.
D
Requisite
for
that
would
probably
be
to
get
an
open,
Telemetry
owned
account
yeah.
B
That's
the
exact
next
item,
so
I'm
doing
some
work
kind
of
offline
to
try
and
get
a
AWS
account.
That
seems
like
we'll
need
one
for
China
and
for
the
rest
of
the
world,
but
Morgan
opened
a
ticket
with
a
cncf.
That's
coming
to
give
a
quick
update
here
and
I
have
no
disability
into
it
whatsoever.
Only
projects
like
overall
open,
Telemetry
maintainers
can
actually
see
the
ticket,
but
ideally
they
they
answer
the
ticket
and
give
us
these
accounts.
B
It's
a
bit
of
an
yeah
I'm,
not
sure
how
long
it's
going
to
take,
but
we
do
have
cost
estimates
and
things
like
that
too.
So
a
bit
of
a
waiting
game.
C
B
There
is
some
sort
of
like
spreadsheet
that
seems
out
of
date.
It's
like
oh
Lolita,
Morgan,
some
other
people,
Ted
et
cetera,
but
anyway,
so
we
have
it.
We
have
a
ticket
open,
I
can't
track
the
progress
of
it,
but
I'll
keep
kind
of
pinging,
Ted
and
Morgan
to
see
if
we
can
move
that
along.
B
B
Both
you
know,
based
on
a
previews
and
maintainers
and
also
add
in
some
new
project
contributors
as
well,
so
Anthony
I
think
you
Alex,
lay
wing
and
I
forget
who
the
other
fourth
person
are
or
like
officially
on
the
repo
right
now,
but
there's
no
sort
of
like
approver
or
maintenance
or
maintain
or
breakdown,
and
then
Tristan
and
two
of
the
folks
from
Cisco
are
interested
or
volunteered
to
help
on
the
approved
inside
and
then
from
Cisco.
B
There
will
be
one
approver
and
one
potential
maintainer,
so
I'm,
not
sure
kind
of
y'all's
thoughts
around
that
we
can
open
issues
to
nominate
them
and
things
but
Anthony
Alex.
What
would
you
consider
like
the
current
repo
breakdown
of
universe,
approved?
Reverse
maintainer
things
like
that.
F
Yeah
I
mean
I,
think
it'd
be
great
to
get
more
approvers
in
the
repo
I
think
we
probably
want
to
see
some
amount
of
traction
for
reviewing
PRS
at
the
very
least
before
we
Mark
people
as
approvers.
If
I'm
not
mistaken,
I
think
that's
part
of
the
community
guidelines.
C
Yeah,
so
my
thoughts
on
this
initially
are
I.
Think
the
the
current
maintainer
group
is
full
of
a
bunch
of
people
who
were
put
there
to
bootstrap
and
are
no
longer
active
should
probably
be
reduced
to
Alex
and
I
as
far
as
bootstrapping
approvers,
since
there
are
currently
no
approvers
outside
of
the
maintainers
I
I
agree.
C
Without
this
part
of
the
process,
people
need
to
be
reviewers
that
approvers,
if
we're
going
to
try
to
bootstrap
approvers
I,
think
I
would
consider
others
who
are
maintainers
on
one
of
the
relevant
sdks
to
move
into
that
position
without
an
intermediate
step,
but
otherwise
that
would
be
weird.
B
Okay,
yeah,
that
makes
that
makes
complete
sense.
So
maybe
we
can
create
tracking
issues,
one
per
potential
approver,
and
then
we
can
start
linking
any
sort
of
contributions
they
make
to
that
issue.
And
then,
once
you
know,
maybe
they
hit
like
three
contributions
or
something
like
that
or
we
can
talk
more
artistic
but
they've
kind
of
Hit.
The
the
commitment
level
necessary
so.
C
B
We'll
have
a
great
public
audition
for
that
any
other
comments
around
a
previous
maintainers
feel
free
to
nominate
yourself
or
you
know,
to
start
doing
some
of
the
contributions
and
review,
work
and
I
think
you'll,
you
know
be
nominated
through
the
community
as
well
so
open
to
anyone
who
has
an
interest
in
a
willingness
to
contribute
here.
Foreign.
B
So
we
have
different
kind
of
various
states
of
the
current
implementations.
I
think
Alex
had
an
item
to
publish
kind
of
a
a
rough
draft
feature.
Matrix
I,
don't
think.
We've
assessed
all
the
implementations,
but
just
as
a
starting
point,
Alex
I'm,
not
sure
if
you
had
some
time
to
do
that,
but
I
know
we
do
have
some
engineering
resources
that
we'll
be
doing
some
various
investigations.
So
if
you
know
of
any
gaps
that
maybe
they
say
could
help
out
on
that'd
be
good
to
call
out
to.
F
I
have
not
had
any
time.
I
will
make
this
my
priority
for
later
today.
It
should
be
an
easy
readme
change,
but
yeah.
B
B
Yeah
no
problem
feel
free
to
send
it
to
me
now.
I'll,
potentially
just
add
it
to
the
repo
as
well.
So
I
think
we
have
someone
doing
some
JavaScript
assessment
work
and
then
Java
has
already
been
assessed
by
us
as
well
so.net
and
Java,
or
you,
know.net
and
python
could
potentially
use
some
feature
assessments.
If
anybody
particularly
interested
in
contributing
to
that
side
of
it
and
coordinate
with
Alex
and
some
others.
B
Whole
class,
so
I
I
think
Alex's
Matrix
should
cover
that
and
just
being
able
to
Alex.
He
can
maybe
share
a
copy
at
the
table
or
something
like
that
on
a
slack
channel
for
now.
That
would
probably
be
helpful
as
a
starting
point
too,
or
just
put
it
on
google
doc,
real,
quick
anything
that
you
can
just
share
out.
We
can
foreign.
E
Can
I,
can
you
guys
repeat
what
exactly
are
the
points
that
you
guys
are
looking
for
inside
these
language,
Matrix.
B
Alex,
you
just
want
to
share
your
screen
and
kind
of
talk
about
what
you
did
and
where
we're
at
and
how
you
thought
about.
It
might
be
helpful
to
do
kind
of
context
sharing
for
everyone
else.
F
Yeah
I
mean
I,
think
I,
don't
like
I
said:
I,
don't
have
anything
right
now
to
share,
but
I
can
I
can
get
a
PR
going
and
then
I'll
put
a
link
in
the
in
the
slide
channel
to
follow
up
on
there.
I
think,
essentially,
what
I've
started
doing
is
I've
gone
through
different
different
layers,
different
language,
implementations
of
the
layers
and
just
tested
some
of
the
some
of
the
functionality,
either
Auto,
instrumentation
or
context
propagation,
or
even
support
for
things
like
disabling,
like
AWS
context,
propagation
in
different
languages.
F
C
Yeah
one
thing
I
want
to
add
to
that:
is
you
know
most
of
these
provide
a
means
to
do
that
for
the
trace
provider,
many
don't
for
meter
provider.
C
F
B
F
Things
like
the
like
the
the
context,
the
custom
context,
extractor
that
was
supported
in
some
languages,
but
not
all
of
them,
so
I
think
there's
another
feature
that
should
be
compared.
F
F
I
think
once
we
have
the
I
mean
it
should
definitely
be
consistent
across
implementations.
It's
for
me.
It's
just
a
question
of
whether
this
is
done
before
or
after
I.
I
would
say
that
the
consistency
should
be
across
all
languages,
but
whether
or
not
they're
complete
will
only
be
able
to
determine
once
the
spec
has
been
reviewed.
F
B
Yeah
that
makes
sense
awesome
thanks
for
adding
some
context
there
Alex
so
Tristan.
This
might
be
for
you
and
Tyler
I
kind
of
forget
what
this
was
tied
to
to
be
honest,
but
I
think
we
have
some
ongoing
spec
issues.
It
seems
like
we
were
semi
discussing
them
already
with
this
issue,
but
I
know
I,
guess
for
everyone
else's
context.
Tyler
and
Tristan
are
doing
some
spec
assessment
if
you're
interested
in
helping
them
out
or
contributing
to
that.
B
Please
reach
out
and
coordinate
with
them,
I'm,
not
sure
what
the
holiday
and
other
things,
how
much
time
they
had
in
the
last
week
to
actually
dig
into
it.
G
Yeah
not
much
one
thing:
I
noticed
that
spec
issues
speaks
to
directly
is.
G
B
Yeah,
that
makes
sense,
oh
quickly,
going
back
to
the
last
Point
for
the
feature
Matrix
so
Tristan.
Do
you
think
we
potentially
want
to
do
this
for
the
Ruby
implementation
that
you
all
have
as
well
or
you
know,
I
think
there
probably
need
to
be
some
sort
of
donation
process
first
and
then
making
sure
it's
consistent,
so
just
wanted
to
make
sure
we
addressed
that
so
I
know
you
brought
it
up
on
the
slack
Channel.
G
Oh
yeah,
yeah
I'm,
not
sure
if
there's
necessarily
A,
if
needs
to
go
through
the
donation
process,
I
think
it
would
likely
be
kind
of
not
a
rewrite
sort
of
a
rewrite
just
to
put
it
into
because
it's
not
kept
in
the
same
repo
but
I
I
can't
just
copy
it.
Not
because
it's
not.
It
is
open
source,
but
it
would
just
be
a
different
structure,
so
I'll,
probably
just
sort
of
re-implement
it
in
the
open,
the
Upstream
repo
and
then
make
a
PR.
B
Okay,
any
other
specific
spec
related
like
issues
comments.
Anything
like
that.
B
Okay,
leave
that
for
now
so
this
is
one
I
think
Tyler
brought
up
recently.
I
should
have
went
to
specific
comment,
but
I
know
for
a
lot
of
function:
scenarios
they're,
they're,
essentially
async
scenarios
as
well.
They
involve
cues
and
multiple
lambdas,
multiple
functions,
Etc,
so
Tyler
has
a
proposal
Tyler.
If
you
could
potentially
link
it,
that'd
be
super
helpful
to
fix
the
context
propagation
or
at
least
a
semantic
conventions
around
the
context
propagation
of
some
messaging
scenarios.
B
Not
all
does
it
specifically
be
around
like
non-backing
scenarios,
so
if
there
was
just
a
Lambda,
followed
by
a
queue
followed
by
another
Atlanta,
his
proposal
is
to
do
some
sort
of
like
parent
child
relationship.
There,
I'm
not
sure,
is
like
for
other
vendors
or
contributors.
Have
you
all
noticed?
B
You
know
async
being
deeply
related
to
this
shouldn't
Sig
have
an
opinion
or
like
push
them
a
specific
way.
I
did
messaging
Sig
around
async
scenarios,
I'd
love
to
hear
some
thoughts
and
suggestions.
H
I
know
like
I'm
on
the
same
team
as
Anthony,
but
we
do
see
like
anecdotally,
quite
a
lot
of
people
trying
to
use
this
kind
of
architecture.
H
You
know
it's
not
always
Lambda
to
like
Q2
Lambda.
You
know.
H
Sometimes
it's
you
know
whatever
goes
in
front
of
the
messaging
service
to
a
Lambda
and
that
context
propagation
is
hard
and
usually
the
answer
we've
given
in
the
past
is
like
you're
gonna
have
to
handle
that
context
propagation
for
yourself
by
like
injecting
and
then
like
retrieving
the
context
manually
I
want
to
say
there's
like
more
than
one
issue
open
related
to
this
and
I
wonder
if
it
needs
to
be
solved
very
much
outside
the
context
of
just
Lambda
like
and
how
this
works.
D
Just
with
how
I
linked
directly
to
the
the
one
that
was
that
I
commented
on
yeah,
just
don't
scroll
when
you
open
it,
it's
a
very
large
comment
and
this
one
somehow
for
some
reason
got
collapsed
anyway.
D
D
A
lot
of
it
comes
down
to
span
links
versus
parent-child
relationships.
B
B
D
H
Awesome
I'll
see
if
there's
any
other
issues
we
have
maybe
in
like
SDK
refunds
related
to
this
too,
that
we
may
be
sharing
with
people
and
add
it
here.
B
So
we're
kind
of
back
to
the
event
to
carrier
discussion
I'm,
not
sure
if
we
potentially
need
to
take
a
step
back
and
make
sure
everyone
else
is,
you
know
kind
of
on
the
same
level,
so
they
can
all
equally
participate.
B
So
yeah
I,
guess
you
know
we
have
30
minutes
I,
don't
want
to
waste
anybody's
time.
So
where
would
we
like
to
spend
like
kind
of
our
discussion
Focus
here,
like
as
a
group.
D
So
I
personally
wasn't
involved
in
any
of
the
the
prior
development,
so
I'm
just
coming
in
into
this
from
you
know,
just
a
a
new
set
of
eyes.
So
I
don't
understand
the
the
the
history
around
why
it
was
developed
that
particular
way.
D
So,
in
terms
of
in
terms
of
consistency,
I
understand
what
Anthony
was
trying
to
get
at.
You
know:
there's
definitely
some
benefits
in
having
consistent
terminology
and
and
such
between
different
implementations,
I
mean
that's
the
big
motivation
around
the
whole
semantic
conventions
and
a
lot
of
the
the
aspects
of
the
specification.
D
C
Generally,
the
hotel
specs
have
always
been
very
much
of
the
opinion
that
if
we
give
you
a
name
that
you
should
use,
you
can
choose
to
disregard
that
if
it,
if
there's
a
better
idiomatic
name
in
your
language,
for
the
the
concept
or
thing
I,
think
that's
fine.
What
I
would
want
to
avoid
us.
Having
is
where
we're
currently
at
where
some
of
the
implementations
have
something
akin.
C
Where
you
can
have
a
hook
that
you
provide
to
the
instrumentation
that
it
will
call
to
get
a
context
out
of
an
event
and
others
have
an
implementation
where
you
can
provide
a
hook
to
that,
it
will
call
to
get
a
carrier
out
of
the
event.
Those
should
cover
the
same
portion
of
the
implementation
space.
D
D
So
you
could
you
repeat
that
last
part
where
you
said
some
of
the
implementations
have
a
function
that
get
a
context
out
of
the
event.
C
C
Correct
yeah
and
my
preference
certainly
is
that,
if
the
event
to
carrier
and
edit
stop
at
having
the
author
of
the
application,
provide
a
hook
that
can
extract
a
carrier
from
that
event
and
that
carrier
can
then
be
handed
on
to
context
propagation
which
is
handled
by
the
instrumentation,
which
is
configured
with
a
set
of
propagators
and
may
have
additional
knowledge
about
what
needs
to
go
into
that
carrier.
Before
the
context.
D
So
I'm
not
quite
sure,
I
follow.
Maybe
it
would
make
sense.
Do
you
want
to
just
share
your
screen
and
kind
of
sketch
out
a
little
bit
of
you
know
some
of
the
the
code
execution
flow
or
something
like
that?
Or
would
you
rather
I
try
to
do
that
so
that
we
have
something
a
little
bit
more
visual
to
discuss.
C
D
So
let's
say
that
we
have
an
event
and
we
have
a
propagator
right
and
what
are
some
other
nouns
that
we
have
to
deal
with
here.
D
So,
given
an
event,
there's
some
something
that
we
are
trying
to
pass
between
the
event
to
the
propagator
right
and
then
the
results
of
that
we
want
to
have
be
the
context,
correct
sure
so
at
least
with
Java,
and
maybe
we
can
just
really
quickly
discuss
some
of
the
different
ways
that
this
is
implemented.
So
in
Java
it
calls
event
dot,
get
headers
and
then
passes
that
into
the
propagator
right.
C
D
Propagator,
so
so
this
is
kind
of
happening
directly
right,
so
the
event.get
headers
returns,
some
header
value
in
I
think
it's
a
map
of
strings
in
in
the
AWS
SDK.
D
Okay,
so
let's
split
it
out
this
way,
so
we've
got
the
the
carrier
in
this
case
is
equal
to
event,
dot
headers
and
then
here
we're
just
passing
the
carrier.
D
D
I
think
you've
got
the
what's.
It
called
the
event
to
carrier.
C
What
are
their
yes,
so
that
this
is
then
from
the
perspective
of
the
instrumentation,
so
the
the
Lambda
wrapping
instrumentation
is
invoking
event.headers
or
event
to
carrier
and
then
passing
the
result
to
the
propagator
correct.
That's
the
the
context
within
which
we're
acting
event.
D
To
carrier
would
be
an
implementation
of
something
like
event:
dot
headers.
C
In
in
the
go
implementation,
the
signature
for
event
to
carrier
is
a
slice
of
bytes
to
a
carrier,
so
that
is
responsible
for
decoding
the
event
itself.
It
there
is
no
headers
available
at
that
point
and
I
I
think
that
there's
probably
something
missing
from
the
Java
example.
You've
got
there
as
well,
because,
like
event,
headers
would
be
available
for
an
HTTP
event,
but
it
may
not
necessarily
be
available
for
an
sqs
event
or
for
some
events
that
is
representing
you
know.
D
I
I'm
not
sure
I
think
that
that's
just
always
available
there's
a
set
of
headers
that
are
on
all
events
in
Java
I
could
be
wrong,
though,
do
you
want
me
to
do.
D
G
Events
always
have
because
the
event
itself
isn't
HTTP
specific.
It's
just
a
blob
of.
A
C
It
may,
but
that's
particularly
to
the
event
and
there's
a
prior
step
in
the
Java
instrumentation,
if
I'm
not
mistaken,
where
you
need
to
tell
it
what
type
of
events
to
unmarshall
the
incoming
event
into
so
there's
there's
a
separate.
You
know
not
necessarily
a
vet
to
carrier,
but
events
to
domain
objects,
sort
of
thing
that's
happening
there
because
for
every
event,
invocation
the
the
actual
thing
that
you're
given
by
the
Lambda
API
is
just
a
slice
of
bytes
right.
C
It's
a
it's,
probably
Json
encoded,
but
it's
a
slice
of
bikes
that
you
can
process
in
any
way
you
want,
and
there
are
a
lot
of
convenience
handlers
for
common
use.
Cases
like
an
HTTP
event
coming
through
API
Gateway
or
something
coming
to
rescue
us.
D
But
here
you're
saying
that
there's
some
event
bites
that
turns
the
that's
responsible
for
parsing
those
bites.
So
in
that
case
the
the
lambdas
also
likely
going
to
do
parsing
of
that
does
that
create
a
lot
of
like
a
duplicate,
parse
parsing
of
that
event,.
C
I,
don't
believe
it
does
in
well.
No,
yes
that
and
they
produce
duplicate,
parsing
I,
don't
know
how
you
avoid
that,
though,
like
unless
you
are
handing
the
event
handler
something
other
than
the
Raw
event,
which
is
just
a
slice
of
bites.
D
Right
so
in
the
the
Java
SDK
generally,
the
way
that
a
Lambda
Handler
is
implemented
is
the
Lambda
Handler
is
specifies
a
a
type
of
an
object
and
then
the
Lambda
runtime
does
the
deserialization
before
it's
passed
to
the
Lambda
Handler,
so
at
least
in
Java
that
that
duplication
of
deserialization
doesn't
happen
because
of
where
it's
done.
D
So
in
Java
the
Handler
is
dealing
with
a
a
an
event
object.
Instead
of
that,
byte
array,
like
what
you're
saying
go,
has
to
deal
with.
C
But
in
that
case
the
the
event
to
carrier
implementation
then
could
be
custom
processing
on
the
events
type
that
handles
on
marshalling
into
that
event
type
and
populating
the
headers
field
or
whatever
it
is
right
so
yeah.
So
it's
split
up
into
separate
places,
but
it's
accomplishing
the
same
thing.
Sure.
C
Or
ability
to
do
things
like
like
that?
Javascript
has
a
hook
for
events
to
context
where
it
calls
that,
with
the
event
and.
D
C
D
I
see
so
right
now,
you've
got
this
and
then
it's
just
going
straight
to
the
context
and
then
that
event
to
context
is
doing
the
is
event
to
context
calling
the
propagator.
D
Okay,
does
the
JavaScript
SDK
also
have
to
deal
with
the
event
bites.
D
Sorry
I
said
hello
because
it
wasn't
sure
if
my
power
just
went
out
or
something
but
anyway
sorry,
okay,
so
still
not
sure
about
that
part.
But
foreign.
D
D
D
So
I
I
sympathize,
Andrew
the
like
having
this
additional
step
of
needing
to
do.
The
the
deserialization
definitely
lends
itself
to
the
need
for
having
another
level
of
abstraction.
C
Yes,
unless,
unfortunately,
it
is
Json
and
gravity
particular
field
out
of
that
works,
for
you
like,
like
I,
think,
there's
a
default
implementation
that
ships
with
the
the
go
instrumentation
that
works
for
events
that
come
as
HTTP
requests
for
the
API
Gateway.
It's
like
we
can
have
common
implementations
but
yeah
if
you've
got
a
custom
event
type
and
the
dominant
implementations.
A
C
D
D
Yeah
I
I'm
pretty
sure
that
this
is
all
it's
doing,
but
I
will
double
check
on
that
and
get
back
to
you.
D
So
if
we
have
this
event
to
carrier,
that
would
make
sense
that
this
these
two
would
need
to
change
to
kind
of
align
with
that.
D
C
Yeah
I'm
totally
good
with
the
Java
approach
of
having
that
be
implicit
in
the
contracts
for
the
the
type
that
gets
passed
to
the
Handler.
If
that
sort
of
extraction
has
to
already
have
happened,
but
I
think
that
the
important
part
is
breaking
the
the
connection
between
the
user
provided
events
and
the
contact
propagation.
C
B
C
Pr
for
this
I'm,
not
sure
where
the
appropriate
place
to
put
it
is
like
right
now,
I
think
there's
a
bunch
of
documentation
on
how
the
Lambda
handlers
should
function
in
the
semantic
conventions,
which
feels
a
little
weird
to
me.
I,
don't
know
if
we
need
a
separate
spec
document
for
Lambda
instrumentations
for
all
the
things
we
want
to
be
consistent
across
them
or
if
having
that
in
the
semantic
conventions,
is
fine.
I.
B
F
Yeah
I
think
we
had
this
discussion
last
last
week
and
I
I
think
it
based
on
this
conversation.
This
does
seem
like
it
should
be
somewhere
else.
I
would
put
it
honestly
in
this
specification
repository
since
the
spec
is
implemented
across
the
languages,
and
this
code
lives
in
all
the
repos
for
each
different
language
right,
not
all
inside
the
Lambda
Repository.
C
Yeah
I
think
one
one
thing
that
putting
it
in
the
land
of
repo,
at
least
temporarily
could
help
with
is
just
getting
movement
since
I.
Don't
know
that
any
of
us
have
the
ability
to
actually
affect
changes
in
the
spec
repo
yeah.
F
D
So
I'm,
looking
at
this
specification
repo,
so
there's
the
specification,
repo,
there's
a
specification
folder
and
then
it
lists
you
know,
baggage,
common
compatibility
context,
logs
metrics
protocol
and
so
like
the
the
current
AWS
SDK
stuff
is
under
Trace
semantic
conventions
and
then
there's
instrumentation
and
then
AWS
Lambda
stuff.
There
I
am
wondering
if
there
should
be
like
an
instrumentation
section,
underneath
the
specification
folder
to
help
align.
You
know
cross-cutting
stuff
across
instrumentation.
B
And
quick
question
classical
which
implementation
will
you
be
working
on
assessing?
Will
it
be
the.net
or
the
python
one
just
so
we
have
that
track.
E
I
was
thinking
initially
to
take
a
look
at
the
python
one.
Okay,.
D
H
C
B
B
We
can
add
this
to
the
agenda
for
tomorrow
Tyler.
What
would
you
like
title
like
spec,
reorganization
or
I?
Don't
know
what
was
an
earthquake
called
us
Lambda
rationalization
of
the
spec.
B
B
Okay,
well,
that
should
be
discussed
and
we're
in
depth.
I
think
we
clearly
need
some
more
time
to
rationalize
it.
I'll
be
curious.
What
severins
kind
of
feedback
is
I'm
sure
he'll
have
some
thoughts.
There.
C
C
So
I
know
a
couple
of
people
from
the
Lambda
service
team
in
Dublin
have
expressed
interest
in
participating
we've,
given
them
the
information
and
participating,
whether
they
will
I
do
not
have
any
insight
right
now.
B
Okay,
yeah
Tyler
I
think
maybe
helpful
if
you
pinged
I,
think
it
was
Lubin
who
voted
who's
potentially
on
the
AWS
Dublin
team,
so
I
at
least
know
he
was
interested
in
participating,
probably
didn't
get
a
chance
last
week,
but
that
would
be
someone
to
potentially.
B
Great,
do
we
want
to
or
Tyler
do
you
want
to
cover
any
event
to
carrier
related
information?
Are
you
all
discussed
it
the
previous
week,
but
maybe
you
can
just
provide
a
summary
of
kind
of
like
our
our
current
state.
There.
D
Yeah
I'm
gonna
refresh
my
memory
on
how
the
Java
instrumentation
Works,
so
I
can
follow
up
on
that
tomorrow,
too,.
B
Okay,
we
still
need
someone
on
the.net
side.
Let's
see
so
I
trusted
and
Tyler
is
anyone
anything
specific
on
the
the
spec
that
y'all
would
like
to
discuss
or
maybe
I
know.
We
can
have
like
an
open
item
for
more
contributors
to
work
with
y'all,
but
if
there's
anything
you're
starting
with,
let
me
think
maybe
0.2
that'd
be
helpful.
D
So
one
of
the
things
that
Tristan
and
I
are
starting
is
we
wanted
to
create
a
kind
of
an
Excel
spreadsheet
that
defined
the
various
terminology
that
the
spec
uses
and
how
that
maps
to
the
the
different
you
know:
environments,
the
different
AWS,
sorry
Lambda
versus
gcp
versus
Azure.
So
if
we
have
some
folks
from
some
of
those
other
companies
that
can
that
are
familiar
with
that
terminology,
that
might
be
helpful
if
they
can
help
us
map
those
terms.
E
B
Yeah
that'd
be
great:
I
can
try
and
reach
out
to
lewd
Miller
again,
at
least
for
Microsoft
I
know,
I've
been
at
least
kind
of
poking
her
to
get
some
sort
of
functions
involvement
there.
B
B
D
B
B
Okay,
I
think
we're
we're
about
six
minutes
left
pretty
much
that
time
is
there
anything
else,
any
other
items
that
people
want
some
eyes
on
some
attention,
I
think
it's
like
our
week,
two
of
our
overall
six
weeks,
bro
so
relatively
on
track.
Let's
just
keep
in
mind
we're
hoping
to
have
any
spec
proposals
changes.
What
have
you
ready
by
the
beginning
of
March?
Thank
you.
D
Cool
okay,
great
chat
today,
Anthony
thanks
for
going
along
with
my
weird
pseudo
code,.
B
Awesome
well
thanks
so
much
for
joining
everyone
for
those
who
are
joining
tomorrow.
Thank
you
for
that
as
well.
I
won't
be
there,
but
yeah
feel
free
to
talk
in
the
slack
Channel.
Let
me
know
if
you
all
need
any
support,
have
any
questions
or
anything
like
that.
Let's,
let's
keep
working.