►
From YouTube: 2021-11-03 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
D
Yes,
I
added
I
added
some
the
topics
from
mostly
from
yesterday's
specs
sake,
so
like
one,
one
of
the
things
that
we
discussed
last
week
was
using
what
the
changes
that
we
need
to
make
to
the
resource
spec
and
we
talked
about
identifying
a
client-side
telemetry,
and
so
my
understanding,
my
takeaway
from
yesterday,
was
that
the
presence
of
the
device
attributes
is
sufficient
to
identify
resources
is
coming
from
client
side.
D
I
didn't
get.
I
mean
I
didn't
get
quite
like
the
yes
like,
yes,
for
sure
answered
that
no
back
end
services
will
add
those
attributes,
so
I
don't
know
for
sure,
but
like
I
would
suggest
that.
Maybe
we
clarify
that
in
the
in
the
specification
and
see
if
there's
any
pushback.
C
A
And-
and
I
think
to
your
concern
about
what
prevents
the
you
know,
somebody
to
use
it
on
the
back
end,
I
guess
as
long
as
it's
there
in
the
spec,
you
know
we
can
point
out
that
you
know
it's
a
mistake
on
their
side
if
they
ever
do.
A
Okay,
I
I
actually
joined
late
yesterday,
but
I
wanted
to
ask.
We
also
were
thinking
about
a
client
name.
Space
right
are:
is
there
a
precedence
to
such
a
namespace?
A
D
Yeah
we
did
not
discuss
that
yesterday
and
I
was
going
to
suggest
that
we,
maybe
that
through
a
pr
as
well,
I
mean
we
talked
about
maybe
like
having
an
app.
I
saw
that
in
your
examples
of
the
logs
you
used
app.
Maybe
we
propose
app
and
see
what
kind
of
feedback
we
get.
A
Okay,
so
I
think
the
motivation
for
this
was
that
you
know
in
like
at
least
you
know
we
have,
but
I
don't
know
if
other
companies,
you
know
you
have
the
same
mechanism
as
well,
where
I
think
john
you
mentioned
that
the
end
point
to
which
you
send
the
client
side
telemetry
is
entirely
different
from
the
packet
right
is
it
does
it
also
mean
that
the
processing
is
different
or
it
is
just
the
it's
just
a
you
know,
different
endpoint,
but
the
actual
services
are
the
same.
On
the
back
end,.
C
A
Yeah,
so
so
it's
the
same
for
us
too,
and
for
that
reason
you
know
not.
Everybody
can
get
a
different
endpoint
to
to
send
the
client's
telemetry.
So
I
was
thinking
we
we
could.
We
could
stay
with.
A
You
know
multiple
different
attribute
names
like
device
and
app,
but
then
each
time
something
new
comes
up,
we
will
have
to
add
a
routing
entry
to
to
send
that
to
the
client
side
processing
on
the
back
end,
and
that
is
the
purpose
why
I
was
thinking,
have
a
client
as
the
prefix
for
all
attributes
coming
from
the
client
side,
but
I'm
not
100
clear
whether
it
should
be
there
on
all
attributes
on
the
resource
on
the
on
every
signal,
or
you
know
we
just
have
one
attribute,
maybe
at
the
resource
level
only
at
the
resource
level.
A
C
That
was
discussed
that
was
asked
at
the
beginning
of
the
spec
meeting
yesterday,
and
I
think
it
was
made
pretty
clear
by
well.
I
think
it
was
tigrin
yeah
who
said
that
the
general
approach
is
not
to
use
boolean
attributes
but
to
use
the
existence
of
other
attributes
as
that
discriminator,
but
I
actually
wanted
to
bring
something
else
up
that
might
could
be
relevant.
Okay.
I.
A
C
Imagine
that
device
like
mobile
device
versus
web
browser
also
might
want
to
be
routed
differently
in
the
collector
to
a
different
back
end
or
or
wherever,
because
the
data
from
I
have
a
feeling
that
what's
going
to
come
out
of
this
group,
is
that
the
data
for
web
browser
and
web
application
is
going
to
look
very
different
than
the
data
for
mobile
just
because
of
the
the
interaction
models,
and
so
I
wonder
whether
it
might
make
sense
to
have
the
device
as
the
thing
that
says
hey.
C
C
If
your
back
end
handles
it
the
same
way
or
you
could
reroute
them
to
two
different
places,
if
you
need
to
discriminate
between
browser
and
mobile,
but
as
I
say
this,
I
also
realize
that
there's
very
weird,
hybrid
cases
like
react,
native,
for
example,
that
are
going
to
be
living
somewhere
in
between
pure
mobile
native
and
web
browser.
E
A
Yeah,
no,
so
the
goal
is
that
on
the
back
end,
how
do
we
route
it?
Assuming
it's
a
multi-tenant
system?
How
do
we
route
the
messages
coming
from
different
end
user
devices,
irrespective
of
you
know
which
customer
it
is
to
do
a
separate
set
of
services
as
compared
to
you
know
the
messages
that
would
go
for
coming
from
the
the
backend
services,
the
customer's
backend
services.
E
A
A
E
It's
like
it
like
in
the
mobile
like
like
in.
We
also
use
like
the
package
name
ss
identifier
for
the
separating
out
the
different
mobile
apps.
So
maybe
it's
useful
to
use
the
package
name.
It's
just.
A
F
A
Sure
I
mean
there
will
be
further
segregation
yeah,
but
the
front
the
foremost
the
initial
there
is
going
to
be
a
larger
separation
between
you
know
the
backend
services
processing
and
the
in
the
client
side,
services
processing,
that's
going
to
be
a
bigger,
you
know,
separation
and
then
further
yeah.
I
I
see
the
possibility.
D
D
D
A
Yeah
and
the
device
namespace
could
include
both
mobile
and
iot.
I
see
no
harm
and
if
we
could
just
clearly
mention
that
okay.
B
B
A
So
even
these
prefixes
we
are
not
requiring
them
to
be
present
on
every
attribute
right.
I
think
it's
only
certain
resource
identifying
attributes
that
we
need
this
to
be
present.
Let's
say
browser.user
agent
as
long
as
that
is
present,
I
think
that's
sufficient,
isn't
it
it.
A
C
A
A
Only
those
mentioned
in
this
documentation,
I
think
those
as
long
as
those
are
present.
That's
sufficient.
Okay,.
A
Okay,
okay,.
D
So
I
think
I
think,
oh
I
can
take
the
the
action
on
this
one.
I
can
maybe
create
a
pr
to
clarify
that
the
device
can
be
used
to
identify
client
side
and
also
introduce
the
browser
namespace.
D
D
There's
sorry
yep,
so
I'm.
C
Well,
the
so
a
device
we're
you
know
defined.
Oh,
I
guess
you're
saying
if
you
happen
to
be
running,
if
you're
running
the
web
app
on
your
device
yeah,
I
don't
think
we.
I
don't.
I
don't
think
that
the
web
instrumentation
should
know
anything
about
the
device
in
that
case
should
it
I
mean,
I
think
the
web
instrumentation
would
just
know
what
what
browser.
B
C
B
Now
the
web
instrumentation
doesn't
actually
know
anything
about
browser
besides
the
user
agent,
and
we
don't
parse
it
in
the
web,
it's
first
in
the
back
end
or
in
the
collector
or
somewhere.
So
we
don't
really
know
browser
name
or
version
or
anything
like
that
and
we're
probably
not
going
to
parse
it
in
the
front
in
the
agent,
because
the
definitions
can
change,
so
it's
always
done
collector
side
or
somewhere
in
the
back
end.
D
C
A
Sorry
yeah,
I
think
so
yeah.
So
these
we
have
to
explicit
whatever
are
explicitly
listed
here.
Those
are
the
only
ones
that
the
spec
has
a
say
about
right,
so
the
os
will
not
be
under
the
device
namespace,
so
it
won't
be.
A
device.os
os
will
be
a
top
level
name
space,
so
it
will
be
maybe
os
dot,
name
equal
to
android
yeah.
D
Okay,
yeah,
I
know
I
get
it
so
so.
B
B
C
D
A
Next
topic:
okay,
yeah
yeah,
so
I
have
a
couple
of
questions
I
think
at
least
between
some
of
us.
I
think
we
seem
to
have
agreed
on
the
semantics
of
using
log
records
for
events.
A
So
the
two
questions
that
I
have
is
the
logs
data
model.
I
think
they
are
trying
to
mark
it
as
stable
by
the
end
of
the
year,
which
means
you
know
it's
not
stable.
As
of
today
and
the
I
this
the
same
data
model
for
different
purposes.
The
semantics
are
different.
Let's
say
the
name
is
mandatory
for
events
and
we
are
thinking
of
an
explicit
api
for
events,
so
I
don't
know
how
it
will
show
up
in
the
in
the
logs
documentation.
A
But
if
somebody
is
looking
at
the
data
model
to
me,
it
was
very
confusing
with
respect
to
the
body
attribute
body
field.
For
a
couple
reasons
you
know
body
you
know
for
logs.
If
it
is
supposed
to
be
mostly
string,
then
why
did
they
not?
A
You
know
just
use
a
message
and
you
know
because
there
are
like
I
don't
know,
what
percentage
of
cases
would
it
be,
a
string
versus
what
percentage
would
it
be
a
structured,
a
complex
structure?
So
you
know,
depending
on
whichever
is
higher,
you
know,
you
would
lean
towards
making
that
as
the
default
right.
C
C
A
little
bit
of
clarity,
so
the
data
model,
the
goal
of
the
data
model,
is,
is
to
really
support
arbitrary
log
transport,
not
necessarily
apis.
So
in
order
to
support,
I
think
google
cloud
logging
and
the
splunk
logging
apis
that
exist,
and
there
might
be
a
third
one.
I
don't
remember
that
all
provide
structured
bodies
to
provide
the
capability
of
structured
bodies
they
built
into
the
data
model,
because
there
is
going
to
need
to
be
transport
for
these
existing
legacy
legacy.
C
That
doesn't
necessarily
mean
that
the
logging
apis
and
sdks
or
people
who
are
generating
logs
natively
within
open
telemetry,
need
to
support
all
those
things
and
then,
specifically,
this
whole
idea.
This
whole
concept
of
a
structured
body
and
when
you
use
the
body
versus
when
you
use
in
attributes,
has
been
extremely
confusing
to
almost
everyone
in
the
logging
sync,
so
you're
not
alone.
This
is
definitely
something
that
has
been
very
contentious
and
very
confusing,
which
is
why
now
the
recommendation,
I
think
that
they're
pushing
the
login
stick
is
pushing
forward.
C
No,
the,
but
the
data
model
has
to
still
have
that
structured
thing
for
transport,
but
when
they
talk
about
apis
and
sdks,
then
they'll
talk
just
about
string,
it's
very
much
like
in
so
in
the
tracing
apis,
the
so
in
the
attribute
definition
in
the
data
model.
The
attribute
attribute
data
model
has
structured
attributes
with
nested
all
sorts
of
stuff
in
it
to
support
these
legacy
transports,
but
the
apis
for
attributes
in
open
telemetry
only
support
primitive
types
and
arrays.
They
don't
support
arbitrary
dictionaries
for
attribute
types.
A
Okay,
but
why
not
call
it?
Why
not
have
two
separate
fields,
message
and
body
that
way
message
will
remain.
The
string
and
body
would
be
reserved
for
those
special
cases,
so.
C
I
recommend
chatting
with
a
logging
sick,
because
I
mean
I
don't
know,
there's
been
a
huge
amount
of
argumentation
about
it.
I
haven't
been
present
for
any
of
it.
I've
only
heard
it
after
the
fact
also.
C
I've
already
pushed
really
hard
for
getting
rid
of
the
structured
body
in
the
apis
and
sdk,
just
because
I
think
it's
going
to
really
confuse
people,
as
everyone
is
confused
right,
so
it
is
really
confusing
to
have
that
structured
body
available
for
for
people,
because
we
don't
have
any
real
explanation
of
how
you're
supposed
to
use
it.
It's
just
kind
of
like
a
free
form.
Do
whatever
you
want
so,
okay,
yeah.
C
A
And
metrics
they
all
have
attributes.
So
it's
okay.
If
the
primary
content,
the
main
payload
is
in
attributes
even
for
events,
the
log
records,
the
only
concern
would
be
whether
we
need
nested
structures
and
there
is
some
alternative
for
it.
Although
the
examples
that
I
have
you
know
they
are
only
one
level
deeper
they're,
not
like
multi-level.
A
You
know
deeply
nested
structure,
so
it's
not
going
to
be
a
big
deal
to
represent
using
the
dotted
notation
the
name
space
notation,
but
I
think
we
maybe
if
we
start
writing
down
the
specific
events
and
some
sample
examples
of
how
they
look
like,
then
we
will
know
whether
we
need
you
know:
nesting
of
two
levels
or
more
so,
martin
in
in
the
example
section
in
the
plant
dock.
Could
you
add
a
few
more
examples
of
different
events
on
the
browser
side,
yeah.
A
Okay,
and
even
the
ones
that
I
have
put,
I
think
I
just
put
on
my
own
they're.
Not
they
may
not
be
the
way
they
should
be.
D
Okay,
regarding
that
I
was
I
was
wondering
like
if
like
there
will
be
lots
of
different
types
of
events
yeah
and
like
is
there
sort
of
just?
Do
we
need
to
like
define
conventions
for
all
of
them
or
like?
Is
it
kind
of
free
form
like
you
could
just
add
any
attribute?
You
want.
A
C
My
guess
is
that
all
of
those
things
are
there's
going
to
be
user,
like
application
developers
are
going
to
want
to
generate
their
own
types
of
events,
and
so
I
think
it
needs
to
be
free
form,
but
we
could
define
some
standard
like
these
are
some
standard
ones
that
instrumentation
should
support
natively.
Does
that
make
sense
yeah?
C
D
So
it
would
be
similar
to
the
conventions,
for
let's
say
the
attributes
from
spans
like
http
or
error
or
exception.
C
B
C
This
is
something
that
happens
right
on
mobile
devices,
especially
like
we
probably
want
to
define
a
network
change
event,
and
here
are
the
attributes
that
would
be
associated
with
that
event.
D
A
So
do
so
attribute
names
have
certain
conventions
with
respect
to
the
namespaces
right.
Do
they
are
they
needed
on
the
event
names
as
well
or
they're,
not
needed?
A
No
that
maybe
it's
useful,
but
I'm
not
clear
on
the
name
spacing
whether
there
will
we
will
use
dots
in
the
names
of
events.
C
A
Okay,
no,
so
if
we
do
that,
then
there
is
one
constraint
that
the
attribute
name
documentation
I
saw
it
was
interesting,
is
if
you
use
network.change
as
a
name,
then
you
can't
use
network
as
a
name.
C
A
C
A
Yeah
yeah
on
the
attribute
names.
It
certainly
makes
sense,
because
if
we
were
to
translate
this
dotted
notation
to
an
estate
structure,
then
it
would
be
easy
to
map
them
for
events.
We
probably
are
not
going
to
map
to
another
structure,
so
it
might
be
okay,.
C
Yeah,
I
think
I
think
it
would
probably
it'll
become
clear
as
we
define
them
whether
we
need
whether
we
even
need
to
worry
about
it.
Okay,
well,
we'll
have
to
see.
This
is
one
of
those
things
where
yeah
I'd
like
to
get
some
real
good,
concrete
examples
of
these
things
as
a
proposal,
so
we
can
use
it
as
a
rather
than
trying
to
guess
what
it
might
look
like
in
the
future.
A
Absolutely
so,
martin,
maybe
in
the
examples
section
you
know,
let's
try
to
put
as
many
examples
as
possible.
I'll
also
get
some
okay.
C
By
the
way,
I
know
that
there
are
semantic
conventions
right
now.
I
don't
remember
where
they
live,
but
around
network
descriptions
of
the
network.
B
C
Yeah,
we
should
as
much
as
possible
make
sure
we're
using
exactly
the
same
attribute
names
we
wouldn't
want
to
try
to
have
conflicting
attributes.
We've
actually
run
into
the
same
issue
with
metrics,
where
we
don't
really
have
a
good
way
to
say
this
is
a
standard
set
of
attributes
that
applies
for
metrics
and
traces
or
metrics,
and
spans.
C
So
I
think
it's
going
to
become
even
more
the
case
for
logs
now.
We're
really
going
to
have
like
here
is
a
standard
set
of
network
related,
attribute
names
and
values
that
are
used
across
everything,
so
that
may
require
some
work
in
the
semantic
conventions,
just
in
general,
in
their
structure.
But
I
haven't
been
involved
with
that
at
all.
Just
I
know
that
it's
something
that
has
come
up
with
metrics
and
spans
standard.
Those
standard
attribute
naming
rules.
D
It
was
so
in
the
in
that
it
was
basically
defining
the
different
types
of
events,
so
we're
gonna
see
the
examples
and
go
from
there,
but
the
I
went
where
the
idea
came
from
is
in
that
proposal
from
aws
on
where
they
proposed,
having
a
completely
new
signal
for
browser.
Sorry
for
client-side
events.
D
They
also
proposed
having
a
schema
so
and
the
you
know.
The
reasoning
for
the
schema
was
that
you
could.
There
will
be
many
different
types
of
events
and
we
can't
predict
all
of
them,
but
then
it
would
be
nice
to
have
a
way
to
validate,
and
I
thought
I
did
them
on
the
back
end.
So.
D
But
I
think
I
think
sounds
like
we
can.
Just
we
can
we'll
just
go
from
the
examples
and
see
where
we
go.
A
Yeah
I
mean,
I
think
it.
I
think.
Let's
start
with
the
examples,
and
and
then
let's
see
whether
we
need
whether
there
are
examples
for
complex
objects
and
we
would
need
a
schema
for
validation.
A
No,
no
okay,
okay,
because
it's
the
aws
team
that
started
that
proposal.
So
it
will
be
good
to
have
someone
from
aws
yeah.
They
should
know
that
you
know
we
are
mainly
you
know.
We
are
not
going
with
the
session
as
a
separate
signal.