►
From YouTube: 2022-05-11 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
Okay,
let's
get
started
so
I
only
have
one
one
item
on
the
agenda.
A
A
So
I
linked
this
document
in
the
in
the
agenda.
We
started
the
last
week
by
there's
a
link
in
here
to
a
spreadsheet
where
yeah
like
so
I
have.
We
have
listed
different
attributes
that
that
few
few
of
us
from
different
vendors
are
collecting.
A
A
So
so,
just
looking
at
these
different
attributes,
I
started
looking
putting
putting
together
this
document,
which
organizes
the
different
attributes
into
categories
the
way
I've
organized
it
is
that
there
is
a
section
for
attributes
that
describe
the
resource
or
environment.
A
So
essentially
they
apply
to
multiple
different
events
at
the
same
time,
and
then
individual
attributes
or
semantic
commissions
for
individual
events
would
be
down
here
and
then,
underneath
that
I
have
sections
for
attributes
that
I
believe
are
common,
so
they
would
apply
to
all
different
types
of
client,
client
applications
and
then
specific
to
browsers,
specifically
mobile
and
same
for
for
events.
A
A
The
app
bundle
and
short
version-
I
wasn't
sure
if
this
one
would
apply
to
both
browser
and
mobile.
I
think
it
might.
I
think,
a
browser
application
still
might
use
a
bundle.
There
was
also
discussion
around
putting
these
attributes
on
the
service
in
the
service
name
space,
but
I
listed
them
here
for
now
like
this.
B
So
you
have
events,
but
are
there
any
considerations
on
the
spans
as
well
in
case
the
ones
that
are
there
today
are,
do
they
completely?
Are
they
enough
to
represent
our
requirements.
A
So
I'm
sorry,
I
have
not
considered
that
yet,
like.
I
think
that
the
main
the
main
span
that
I
know
is
the
the
network
calls
http
http
calls
that's
like
the
main
one,
that's
obvious,
and
that
has
already
some
semantic
conventions
for
http.
A
I
think
the
other
one
that
I
can
think
of,
I
don't
know
like
for
browser
at
least.
B
A
So
yes,
additional
of
moving
on
here,
the
autonomous
system,
they're
done
they're
a
bunch
of
different
ones.
I
think
we
have
some
differences
in
there,
but
the
the
common
ones
for
sure
are
the
the
number
and
organization
then
geo.
Also
the
same
thing.
There
could
be
a
long
list
of
attributes
here,
but
I
think
the
ones
that
are
common
common-
that
I
thought
are
definitely
the
city
country
code
and
region
code,
okay,.
B
I
I
had
a
comment
on
this
jio
attributes.
I
my
understanding
is
that
your
geolocation
apis,
both
on
the
mobile
and
the
browser,
and
I
could
be
wrong.
They
only
give
you
the
coordinates
right
and
then
you
have
to
resolve
them
to
you,
know
the
city,
country
and
region,
and
that
requires
you
know
having
a
database
yeah
the
jio
mapping
database,
and
you
know
you
won't
be
able
to
have
it
locally,
so
you
will
be
making
a
remote
call.
So
how
does
that
work?
A
Now
so
it's
going
to
answer
that
I
think
so
the
way
at
least
that
we
do
it
at
neuralic
right
now.
We
just
inferred
that
from
the
from
the
headers
from
the
http
headers,
so
I
think
from
the
ip
address,
there's
a
lookup
to
based
on
that
ip
address,
but
I
think
so
these,
like
you
know
there
is
address
available.
A
So
it
would
be
up
to
the
back
end
to
actually,
you
know
generate
these,
but
if
you,
if
you
go
through
collector,
then
and
there's
some
batching
mechanism,
that
you
know,
does
some
processing
and
then
send
sends
the
data
to
the
back
end
from
the
from
the
collector,
and
I
think
I
can
imagine
that
there
might
be
like
a
processor
that
inspects
the
http
header
in
the
collector
and
then
populates.
These
these
attributes
adds
them
to
the
signals
and
then
sends
them
to
the
back
end.
A
B
B
So
the
collector-
I
don't
know
what
everybody
thinks,
but
I
believe
that
the
collector
scenarios
are
are
going
to
be.
You
know
one-offs,
they're,
going
to
be
like
special
cases.
B
But
the
majority
of
the
deployments
of
the
rum
solutions
will
not
have
collector
between
the
agents
and
the
back
end.
The
reason
is,
all
the
agents
are
on
the
internet
and
if
the
customer
were
to
deploy
a
collector,
the
in
in
their
network,
that
will
be
possible
only
for
a
few
customers,
and
you
know
they
could
get
all
the
data
to
themselves.
B
Do
any
changes
required,
add,
modify,
remove
contents
and
then
you
know
forward
them
to
the
telemetry
back
end.
It's
it's
possible,
but
I
doubt
it's
going
to
be.
You
know
a
common
use
case,
so
I
feel
you
know
we
could
skip
the
aspects
of
that
workflow
because
we
don't
know
entirely
how
that
is
going
to
work.
B
So
so
I
think
we
should
not
worry
about
it
now.
A
Okay,
I'm
not
I'm
not
sure
that
I
agree
that
it's
that
it's
kind
of
an
edge
case,
but
we
can
definitely
put
this
as
a
secondary
and.
B
At
least
at
least
clarify
that
these
will
be,
these
are
meant
to
be
added
by
the
collector
in
you
know,
whenever
it's
deployed.
D
So
sorry,
martin,
I
have
a
slightly
different
question.
Do
we
today
want
to
discuss
all
the
possible
semantic
conventions,
or
do
we
want
to
prioritize,
maybe
three
or
four
that
maybe
this.
D
Go
back
and
ratify
like
like
at
least
we
can
really
think
about
them
and
then
try
to
flush
them
out,
because
there's
of
course,
a
lot.
I
can
already
see
your.
D
There
are
a
bunch,
but
maybe
we
should
just
pick
three
and
try
to
necessarily
order,
I'm
just
putting
an
idea
out
there,
because
I'm
sure
everyone
has
thoughts
on
every
single
one
of
these
yeah.
A
Yeah
you're
right
right,
yeah.
I
just
wanted
to
go
like
through
through
the
structure
really
quickly
yeah,
and
can
I
just
go
get
an
overview
and
then
danielle,
let's
decide
on
the
ones
that
we
want
to
focus
first
yeah.
That
sounds
good.
Thank
you.
C
Martin
one
question:
as
far
as
I
remember:
there
is
a
plan
to
merge,
attribute
names.
A
B
A
Yeah,
I
I've
been
looking
at
those,
and
I
think
we
should
definitely
take
that
into
consideration.
I
I
added
a
link
link
up
here
to
that
schema.
Awesome.
B
A
Yeah,
there's
there's
definitely
overlaps
and
I
agree
that
we
should
take
that
into
consideration.
B
What
you
could
do
is
just
for
the
purpose
of
this
exercise,
maybe
you
could
add
a
column
saying
in
an
ecs
convention
and
then
at
least
for
the
ones
that
are
common,
at
least
specify
that
hey.
You
know
this
matches
with
the
ecs,
but
for
everything
else.
It's
different.
A
A
Then
I
have
a
section
for
network
connection
network
information.
Now
I
get
into
browser
for
browser
like
there
is
a
there
is
a
current.
I
already
mentioned
this
a
couple
times
before.
There
is
a
open
pr
to
add
browser
attributes
and
I'd
like
to
actually
talk
about
this
today,
a
little
bit
and
then
I
think
we
we
want
to
capture
page
page
information,
page
url,.
B
Actually,
I'm
I'm
sorry.
I
want
to
go
back
to
the
the
app
namespace
that
you
have
at
the
beginning.
Okay,
so
I
have
a
couple
questions
here.
The
you
know
one
is
about
the
app
name
space.
Are
we
reserving
it
for
client-side
use?
Then
you
know
it
should
be
clarified.
B
You
know.
Secondly,
you
know:
are
these
supposed
to
be
used
by
both
android
and
ios
yeah?
So
I
would
think
so
I
I
am
not
familiar.
A
Yeah
so
yeah,
so
this
is
one
one
area
we've
just
kind
of
discussed
in
the
past,
but
I'm
not
really
sure
we
probably
should
discuss
you
know
further
and
make
a
decision
on
this.
Okay.
B
So
you,
you
can
add
this
to
us
comments.
You
know
for
people
to
respond.
A
And
then
so,
mobile
mobile
has
the
device
attributes
which
are
already
defined.
So
these
are
owners
on
the
resource,
and
then
we
have
then
we
can
get
into
the
events,
and
so
we
talked
about
events,
individual
events
schemas
yesterday
during
the
meeting
yesterday.
A
The
thinking
is
that
there
will
be
all
the
all.
The
events
are
going
to
have
some
kind
of
attribute
like
event
name,
which
will
which
will
which
is
required
in
order
to
in
order
to
distinguish
a
regular
log
signal
from
from
event
the
event
name.
There
was
discussion
about
it
that
yesterday
the
event
name
is.
The
idea
is
to
have
a
syn.
The
values
gonna
have
be
similar
to
span
name
or
spam
event,
name
which
it
should
be
a
low
cardinality
value.
A
Yeah,
so
were
you
in
the
discussion
yesterday,
quinn.
E
A
Yeah,
so
I
so
I
originally
thought
that
the
event
name
would
be
more
like
an
event
type.
So
you
could
you
could
look
at
that.
It
would
be
like
a.
I
think
there
was
your
proposal
in
your
in
your
proposal
from
last
year,
where,
like
it's
a
name,
spaced
unique
value
and
you
can
take
a
have
a
look
at
it
and
then
know
exactly
what
type
of
event
it
is.
A
So
I
that's
what
I
thought
originally
too,
but
it
sounds
like
with
the
bits
based
on
the
discussion
with
ted
yesterday
that
it's
it's
instead
more
just
a
like
a
like
a
string
that
describes
describes
the
event
in
from
like
a
user's
perspective
and
that's
something
that
it
would
still
be
low,
cardinality,
but
very
similar
to
like
a
span
name.
B
I
I
I
I
don't
know
there
are
a
couple
ways
to
go
about
it.
You
know
one
is
to
say
that
these
in
this
table
in
in
this
document,
for
each
event,
we
plan
to
specify
the
applicable
attributes
for
that
you
know
event
or
a
span
or
resource,
and
then
you
know
those
could
be
the
ones
generally
expected
for
that
event,
but
it's
not
a
hard
requirement.
So
it's
not
a
strict.
B
You
know
schema
validation
using
those
the
other
approaches.
I
think
when
you
get
the
instrumentation,
when
you
get
the
provider,
let's
say
a
tracer
from
a
tracer
provider,
you
specify
you
can
specify
the
schema
url.
B
B
Yeah
I
mean
it
would
point
to
let's
say
a
certain
schema
file
that
would
have
this
schema
definition
for
every
possible
event
that
the
backend
would
accept
are
are
the
the
client
would
send.
E
Yeah,
so
the
use
case
would
be
one
for
disambiguation
and
two
for
some
level
of
application
security
such
that
you
know
what
you're
ingesting
since,
since
the
data
is
coming
from
an
untrusted
source
and
yeah,
the
I
mean
the
disambiguation
is
is
problematic.
If
well,
maybe
you
could
use
the
event
name
to
some
extent,
I'm
not
sure
how
to
extend.
We
could
use
it
as
a
trusted
pointer
to
the
schema,
but
for
it
might
be
difficult
or
take
more
compute
to
try
and
infer
it
based
on
the
arguments
or
the
attributes.
A
B
So
I
it
will
be
both
right
using
the
event
name.
You
know
what
attributes
to
expect,
so
you
would.
You
would
check
to
make
sure
that
at
least
those
minimum
attributes
are
present
and
possibly
nothing.
B
Okay,
but
but
is
this
like
formally
defined
in
open,
telemetry
somewhere
as
in
I
don't
think.
B
Anywhere
in
the
open,
telemetry
documentation,
we
specify
doing
anything
like
that
like,
but
but
I
understand
your
security
concern
that
data
is
coming
from
untrusted
sources,
so
we
should
be
a
little
strict
on.
You
know
what
to
expect.
E
B
A
So
can
can
you
can
you
explain
the
concern
a
little
bit
more
like
some
I'm
just
like
thinking
like
if
somebody
sent
sent
an
event
that
that
has
has
attributes
or
does
not
have
attributes
then
like
you,
could
you
could
still
decide
like
what
they're
trying
to
send
or
like,
like?
I
don't
understand
this
message,
so
I'm
just
going
to
drop
it.
E
C
E
To
that
schema,
then
we
drop
the
event
so
that
that
doesn't
prevent
people
from
arbitrary
values
that
conform
to
the
schema,
but
it
does
prevent
people
from
introducing
arbitrary
field
types
that
you
know
might
do
arbitrarily
bad
things
to
the
system.
It's
like,
obviously,
there's
there's
plenty
of
cases
where
you
know
that
that's
not
happening
and
it's
not
the
biggest
target
to
attack
monitoring
systems,
but
it's
helpful
just
to
provide
an
extra
level
of
assurance
that
you're
getting
the
data
you
expect.
A
I
I
think,
like
I
think
this.
This
is
where
we
might
need
some
some
additional
guidance
from
the
tc.
What
ted?
What
one
thing
that
had
said
yesterday,
that
in
general,
like
the
pattern
in
with
the
semantic
conventions
and
open
telemetry,
has
been
to
not
try
to
make
decisions
based
on
like
a
like
a
enum
value
in
in
attribute
field,
it's
like
the
guidance,
has
been
so
far
like
just
the
presence
of
certain
certain
names
based
attributes.
A
So
I
think
that's
what
what
we
might
need.
I
mean
if
you
feel
strongly
that
we
do
need
that
name,
space
here
or
the
type.
Then
we
should
make
that
case.
E
Yeah,
I
think
we
should
strongly
consider
it
for
the
client,
side,
telemetry
and
and
maybe
event
name
can
kind
of
weekly
serve.
That
purpose
I'll
I'll
comment
on
the
doc
and
we
can
keep
it
in
mind.
B
Okay,
yeah,
in
fact
this
particular
attribute
will
be
detailed,
will
be
discussed
in
detail
in
in
the
log
signal.
B
It
has
implications
beyond
the
client
telemetry
right,
it's
a
generic
event
identifying
attributes,
so
it
will
be
discussed
at
length.
A
Okay,
so,
and
then
then,
I
started
listing
some
some
attributes
for
like
some
for
some
common
types
of
events
that
I
thought
we
might
be.
The
three
director
I
can
think
of
is
exception.
That's
obvious
interaction
and
a
timing.
A
Timing
type
of
event-
but
this
is
these-
are
these
are
up
to
discussion
like
I.
This
is
just
like
my
how
I
envisioned
it,
but
I'm
open
to
any
comments
or
suggestions
here.
E
So
I'm
interested
in
the
the
timing
event.
So
the
way
we
do
it
is
we
we've
been
since
we're
browser.
Only
right
now,
we've
been
trying
to
adhere
to
the
the
w3c
performance
navigation
timing
schema
effectively,
but
you
know
what
that's
not
going
to
span
all
all
types,
but
for
for
browsers,
that's
the
structure
in
which
you
get
timing
data
effectively.
A
So
there
would
be
there
would
be
some
kind
of
name
that
I'd
identify
identifies
like
the
what
kind
of
timing
it
is
and
then
there's
gonna
be
a
time
stamp,
which
is
just
obviously
the
epic
time
stamp.
But
in
addition
to
that,
I
think
there
should
be
like
the
relative
timestamp
to
the
start
of
the
navigation,
which
I
added
here.
E
E
Get
like
all
the
network
stuff
and
and
then
the
the
browser,
rendering
timings
and
stuff
like
that,
I'm
so
wondering
would
you
would
it
be
a
single
event
here
or,
and
would
you
extend
this
or
would
it
be
multiple
events
where
each
sub
right
right
timing
point
is
an
event.
B
So
it
is,
it
is
usually
only
for
api
calls
right.
B
Is
is
that
correct,
or
is
it
beyond
apis?
E
B
Okay
in
in
that
case,
I
think
at
least
for
let's
say:
iframes
are
the
the
routes.
Are
the
let's
say
api.
The
api
calls
ajax
requests
fetch
requests
for
those.
I
believe
we
will
be
sending
spans
right
for
for
the
base
page
load
and
for
the
let's
say,
sub
pages,
like
iframes
or
even
virtual
pages.
Like
the
route
changes,
I
think
we
should
define
whether
we
will
be
sending
a
span
our
event
explicitly
and
then
would
this
timings
parameters
be
sent
in
the
corresponding
spans
or
events.
B
E
E
So
the
you
know,
a
a
resource
load
is
going
to
be
a
sequence
of
of
network
events
like
dns
resolution.
First,
first
contact
with
the
server
response,
blah
blah
blah,
and
I
was
just
thinking
that
it's.
E
You
have
to
have
a
different
timing
event
for
each
yeah,
like
for
the
the
page
load
timing
for
the
resource
timing.
But
if
you
have
a
span
then
maybe
you
don't
have
to
worry
about
that.
B
No,
no
even
for
spam,
you
know
we
should
mention
that
you
know
these
will
be
included
in
in
the
spans
attributes.
B
Okay
right
because
we
need
it
for
every
api
call,
that
was
a
network
call
that
was
made
for
pete
and
to
fetch
a
resource
or
a
make
an
api
call
as
x.
Call
whatever
be
it.
You
know
we
we
need
these
timing
parameters.
A
So
quinn
also
one
thing:
one
thing
that
nev
has
been
talking
about
is
is
is
putting
like
just
stringifying
those
navigation
timing,
values
or
things
that
come
from
like
a
single
api,
just
streaming,
stringifying
them
and
sending
them
like
as
a
value
in
one
attribute.
A
Because
that's
like
that's
like
values
that
the
browser
gives
you
and
that
they
might
change.
A
So
maybe
maybe
like
for
for
things
that
are
part
of
the
navigation
timing
like
we
do
it
that
way
and
then,
like
other
events,
such
as
like
paint
timing
like
paint
paint
events
or
largest
content,
paint
or
some
custom
events,
they
would
be
sent
as
in
individual
events,
but
maybe
there
should
be
a
separate
type
of
event.
That's
for
navigation
timing,
only.
A
So
so
clearly,
this
is,
this
is
one
one
section
that
needs
is
more
more
thinking
more
discussion.
B
So
you
might
want
to
write
this
down
there.
A
A
So
yeah
so
back
to
siri's
suggestion
like
let's
just
pick
a
couple,
a
couple:
different
types
of
events
and
work
on
those.
B
I
I
think
I
I
want
to
dig
deeper
into
the
events
sent
from
the
browser,
especially
the
the
load.
Events
like.
How
do
we
identify
you
know?
Let's
say
the
base
page
was
loaded
right
and
then
the
route
change
events
and
the.
B
Navigation
might
be
hard
for
base
pages,
I
don't
know
but
yeah,
I
think,
for
let's
say
you
navigate
to
a
new
page.
Would
it
give
us
a
span
or
would
it
give
us
an
event?
I
I
know
that
there
are
examples
tray
where
you
expect
the
server
to
send
address
id
in
a
meta
tag,
and
then
the
client
is
supposed
to
send
a
spam
when
the
page
initializes,
with
whatever
partial
information
that's
available,
is,
is
that
the
standard
expecting
or.
A
A
B
B
There
are
pros
and
cons
right.
The
the
good
thing
about
sending
a
span
is
there
is
a
trace
id
sent
to
you
by
the
server,
and
you
know
if
you
could
send
a
spam,
at
least
with
partial
information.
It
still
is
helpful
to
correlate
with
with
the
back
end
side.
So
for
correlation
purposes.
It's
still
useful.
Just
you
know,
use
a
span,
but
it's
possible
that
your
back
end,
you
know,
may
not
be
able
to
send
a
trace
id.
So
in
that
case,.
B
We
could
still
send
a
span,
except
that
there
won't
be
any
trace
id.
A
Right,
so
so
that
that's
funny
right,
this
pen
is
still
still
useful.
The
reason
that
I
said
that
I'm
not
sure
is
because,
like
the
the
duration
of
the
span
is
is,
is
just
the
time
until
window
load,
which
seems
which
seems
kind
of
like
what
it,
what
is
it
really
useful.
So
I
think
the
usefulness
of
the
span,
as
you
pointed
out,
is
more
with
tying
back
to
the
to
the
back
end
trace.
B
So
actually,
this
topic
fits
into
a
section
on
instrumentation
or
as
in
how
this
is
not
like
a
telemetry
topic,
it's
more
of
a
instrumentation
topic.
This
is
how
we
have
chosen
to
you,
know,
instrument
our
browser
base,
page
load
event
and
represent
it
as
a
span,
and
these
are
the
expectations
on
the
behavior
of
the
server
that
they're
supposed
to
send
the
trace
id
in
like
a
few
different
ways.
B
As
a
header,
I
should
actually,
you
cannot
read
a
header
in
base
pages,
I
believe
so
so
maybe
a
meta
tag
or
whatever
you
should
maybe
create
a
separate
document
on
how
we
we
are
standardizing
on
the
instrumentation
aspects.
A
B
But
that's
why
I'm
saying
that
there
is,
I
mean
we
still.
It
will
be
good
in
the
long
run,
to
have
some
write-up
on
why
we
chose
this
path
like
why
a
span
and
not
event
and
and
then
you
know
to
make
it
work
correctly.
You
know
there
are
still
some
expectations
that
the
server
needs
to
fulfill
and
then
mention
that.
But
otherwise
you
know
how
will
customers
know.
B
In
fact,
yeah
in
fact,
at
app
dynamics
there
is
even
you
know,
a
contract
with
the
let's
say,
a
java
agent
that
when
a
backend
application
is
instrumented
with,
let's
say
java
agent,
the
java
agent
will
will
make
sure
it.
It
sends
that
meta
tag
or
header
or
a
cookie
right,
so
that
the
customers
don't
need
to
do
anything
explicit.
A
Yeah
I
mean
so
I
feel
like
this.
This
is
this
is
very
like
implementation
detail.
I
think
that
the
important
thing
here
is
is
like
do
we
do?
We
need
to
define
semantic
conventions
for
navigation.
B
Yeah,
I
think
I
started
this
topic
only
to
understand
you
know
the
different
events
that
would
come
out
of
come
out
for
for
each
of
these.
B
So
I
I
was
just
thinking
a
lot,
so
it
looks
like
for
all
of
these
cases.
A
span
fits
better
right
so
and
if
there
are
no
new
conventions
here
to
be
defined,
then
then
we're
good.
B
But
but
how
do
you
differentiate?
Let's
say
even
if
it's
a
base
page
versus
ajax?
How
do
you
say
it's?
This
is
an
adjacent.
This
is
not
a
jax
you.
You
still
have
to
have
some
convention
describing
what
type
of
call
it
was.
B
I'm
not
so
good.
At
this
I
mean
the
browser
aspects.
I
think
you
you'll
know
better
what
all
types
are
are
needed.
So
if
by
resources
is
it
typically
used
to
refer
to,
let's
say
images
and
css
javascript,
but
for
the
base
html?
Would
you
call
it
a
resource,
probably
not
right.
A
Yeah,
there's
there's
nobody.
B
Yeah
but
then
in
the
in
the
ui
you
would,
you
would
still
want
to
show
hey.
You
know
these
are
the
web
pages
and
they
have
these
performance.
B
B
A
A
B
A
Okay,
so
maybe
maybe
for
for
next
week
we
can.
We
can
look
at
this
in
more
detail.
A
D
B
B
Is
is
approved
once
the
apis
are
implemented.
I
think
you
know
we
would
be
implementing
these
individual
events
anyway,
but
it'll
be
good
to
list
each
year.
Each
individual
event
that
are
client
instrumentation
is
going
to
emit
it's
going
to
send
that
way.
I
think
it
also
serves
as
a
you
know,
the
for
the
purpose
of
schema
validation.
That
twin
is
talking
about.
D
I
I
just
sent
a
link
to
one
of
the
documents
that
martin
had
started
some
time
ago.
So
what
the
goal
way
to
go
over
that
or
maybe
another
document
where
we
already
have
that
list
going,
because
I
I
don't
think
we
or
we
should
just
add
to
that
list.
I
I'm
just
I
just
feel
like
this-
is
something
we
have.
A
A
Yeah,
so
for
next
week
to
answer
your
question
is:
does
I
guess
how
do
we
proceed
like
we
should?
Should
someone
like
spend
time
on
this
and
and
then
present
like
a
proposal?
Should
we
pick
pick
one
section
right
now
and
everybody
kind
of
you
know
prepare
us
for
the
discussion.
B
I,
I
would
say,
start
expanding
this
document
as
if
you
would
be
submitting
a
pr
and
then
you
know,
write
as
much
as
I
mean
in
detail
and
and
then
in
at
each
point.
I
think
we
could.
You
know,
comment
on
you
know
any
corrections
needed
clarifications
needed
and
that
now
that's
where
the
document
can
evolve
and
we'll
be
ready
to
submit
as
a
pr
you
know,
few
weeks.
B
So
I
think
it
it.
It
goes
with
what's
to
be
called
as
an
mvp
right
for,
for,
for
the
first
version
of
you
know
what
our
browser
instrumentation,
we
wanted
to
support.
You.
D
D
B
A
Well,
I
would,
I
would
invite
you
know
anyone.
Who's
who's
got
opinions
about
this
to
collaborate
on
this
document
I
so
for
for
next
week
I
yeah
we
can
pick.
You
know
we
can
pick
like.
Maybe
like
these,
these
browser,
the
interaction
and
timing,
attributes
and
discuss
them
in
detail
next
week.
B
But
but
what
are
the
open
questions,
I
think
other
than?
Is
it
more
of
what
you
listed
there
as
an
open
question,
then
I
think
we
like.
I
believe
that
we
should
discuss
offline
as
well.
B
A
What,
if
would
it
help
like
if
we
had,
if
you
looked
at
the
prototype
like
we
had
like
prototype
implementation
and
looked
at
look
at
those
those
kind
of
events
in
a
you
know
like
a
running
poc
yeah
that
should
be
fine.
They'll,
be
helpful.
B
B
A
Okay,
so
I
think
for
for
for
next
week,
maybe
I'll
I'll
I'll
work
on
a
poc
for
the
timing,
events
and
I'll
demo
it
and
in
the
meantime,
like
if
you,
if
you
have
any
suggestions
on
on
this
ahead
of
time.
Please
please
comment
in
this
dark
up.
D
Just
one
thing
I
wanted
to
ask
like
for
the
areas
that,
let's
say
you
know
the
geo
or
outside
of
the
events
which
I
know
is
a
much
bigger
discussion
like
for
exceptions
right,
we
don't
need
to
do
anything
different.
We
want
to
follow
the
same
semantic
conventions
as
what
is
defined
in
hotel.
Do
we
need
to
do
anything
about
that,
or
does
that
just
become
a
little
right
up
in
the
pr
that
we
will
follow
this,
because
I
feel
like
geo
is
a
similar
thing.
I
was
just
going
through
the
ecs
one.
D
It
has
everything
right
like
it
has
lat
long.
It
has
the
works.
So
is
that
what
is
expected
in
the
pr
just?
We
will
follow
this.
B
So
the
ecs
is,
is
a
is
a
master
list
right,
so
it
would
have
conventions
for
probably
anything
and
everything,
whereas
we
are
only
concerned
about
what
our
agents
will
send.
A
No,
no,
no
so
so
this
was
so
when
I
was
put
into
this
together.
The
geo
and
the
network
like
these
and
autonomous
autonomous
systems,
specifically,
they
don't
exist
like
in
the
in
the
semantic
formations
for
right
now,
but
they
might
like
once
the
ecs
is
like
merged.
So
I
think
at
that
point
like,
if
there's
overlap,
we
would
not
be
introducing
new
new
fields.
D
B
But
it
is
still
only
the
ones
that
the
either
the
agents
are
or
the
collector,
which
is
still
at
the
customer
site.
You
know,
is
the
one
sending
it
and
anything
that
you
do
after
you
receive
the
data
in
the
back
end
is,
is
not
our
concern.
D
B
Yeah
yeah,
I
think
the
client
side
aspects
plus
the
mvp
like
what?
What
do
you
want
in
the
first
like
a
goal.