►
From YouTube: 2022-08-16 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
B
Carlos
added
the
first
item
there
he's
not
here,
but
I
think
we
still
can
discuss
it
he's
not
the
owner
of
the
issue.
B
So
this
is
about
splitting
the
metrics
that
we
did
recently
for
the
process
network
input
output,
which
had
a
direction
attribute
and
the
the
attribute
was
eliminated
and
two
separate
metrics
were
introduced
and
bogdan
raised
the
issue
that
this
was
not
the
right
thing
to
do.
C
Yeah
I
mean
I'm
I'm
concerned
about
the
the
rules
that
we
have
and
how
do
we
apply
them
and
I'm
trying
to
make
sure
that
if
we
have
rules,
we
apply
the
rules
and
the
rule
says
if
the
total
makes
sense,
we
should
have
them
as
attributes
which,
in
case
of
the
disk,
you
tigran
discovered
that
that's
not
the
case,
because
there
are
other
possible
possible
operations.
C
Not
only
writing
reads
so
because
of
that
we
we
decided
to
split,
but
but
here
in
case
of
the
network,
I
don't
see
any
other
any
other
direction
or
any
other
thing.
So
because
of
that,
I'm
like
why?
How
are
we
just
copying?
Something.
Are
we
just
like?
What's
the
rule
here,
because
then
there
is
another
pr
where
people
are
telling
me
that,
oh,
that
rule
can
be
ignored
because
we
ignore
it
here.
That's
how
everything
started
and
look
at
the
pr
with
the
process
thing
and
I'm
like
dude.
This
is
not
possible.
B
Yeah,
I
agree
with
you
about
the
rule,
the
application
of
the
rule.
We
we
should
apply
it.
The
question
I
have
here
is,
and
probably
it's
for
riley
riley
you,
you
found
the
the
actual
matrix
the
disk
metric
where
there
was
the
the
third
value
called
other,
which
was
the
reason
we
the
justification
for
splitting
the
this
style
magic.
I
was
wondering
if
you
know
of
a
similar
example
for
the
network
network
metrics,
which
would
then
justify
this
particular
splitting
as
well.
D
B
So
if
that
is
the
case,
I
guess
then,
would
you
be
okay
with
this
in
that
case
problem
yeah,
so
it's
kind
of
yeah,
so
can
can
you
maybe
dig
that
up
riley
and
if
we
have
the
the
reference
to
that,
then
it
would
be
a
clear
justification
that
we
did
the
the
the
right
thing
and
we're
okay
with
this.
Otherwise
we
will
need
to
reconsider.
Program
is
right,
I
believe,
and
and
if
we
cannot
do
this
quickly,
we
should
probably
revert
this
particular
pr,
because
it's
blocking
the
release
right.
B
C
For
me,
I
you
don't
need
my
approval
or
anything.
You
already
have
my
approval
if
we
find
good
reasons
to
accept
from
that
rule
or
to
to
that
this
does
not
apply
to
that
rule.
Move
forward
with
that.
You
don't
have
to
be
blocked
by
me
or
anything,
I'm
just
trying
to
make
sure
that
we
are
applying
the
rule
and
everywhere
in
all
the
metrics
that
we
define
we
we
are
following
some
of
these
rules.
I
mean
the
rules
that
we
defined.
D
Thanks
for
watching,
I
have
a
question
even
regarding
disc
imagine
like
in
the
1970s
we're
trying
to
define
a
semantic
convention
and
at
that
time
people
are
using
this
query.
They
don't
have
any
control,
but
it's
only
read
and
write,
so
we
think
oh,
it
will
be
ultimately
cracked
for
next
century
and
then
after
30
years
we
discovered.
Oh,
we
screwed
up.
So
what's
the
general
thinking
like
how?
How
do
we
design
for
future
without
knowing
everything
in
the
future.
B
C
The
split
is
one
thing
or
the
other
one
is
maybe
to
name
the
attribute
in
a
more
generic
way,
instead
of
direction
name
it
operation,
for
example,
to
be
read
right
other
and
then
we
we
cover
for
future,
because
there
is
a
disk
operation
which
is
the
right
or
read
or
would
be
other
disk
operation.
C
I
don't
know
sick
for
example,
or
whatever
it
is.
I'm
I'm
not
I'm
not
an
expert
into
this,
but
then
we
we
just
added
the
new
the
new
things
there
as
part
of
the
values
of
that
thing,
correct.
D
D
D
D
C
D
Yeah,
because
that
that
like
when
you
add
together,
that's
a
sum,
it
seems
I've
only
seen
that
him
promises
like
in
many
operating
systems.
I
haven't
seen
that
it's
just
food
for
thought,
not
necessarily
saying
I'm
against
it.
It's
just
I'm
curious
like
like.
Why
did
I
do
in
place
and
do
we
think
that
you
will
lead
us
to
success
or
it's
just
a
curse
anyway?
We
we
can
switch
to
the
next
topic.
B
C
I
think,
personally,
I
think,
would
be
a
mistake
to
remove
that
rule
for
two
reasons:
one
the
protocol
was
designed
with
that
rule
in
mind,
because
otherwise
you
would
have
had
individual
points
directly
without
having
a
concept
of
a
metric,
because
there
is
no
more
metric
like
the
previous
world.
I
think
this
is
where,
where
the
old
world,
with
the
stasd
comes
in
conflicts
with
a
new
world
which
is
more
or
less
prometheus,
the
old
world
was
all
about
individual
points
without
no
relationship
between
them.
D
C
And,
and
by
dropping
that
rule,
maybe
we
can
relax
it
and
say
hey.
You
know
what
it
doesn't
have
to
be
the
sum
if
the
things
are
related
together.
Let's
combine
them
together,
because
it's
it's
optimal
for
us
and
by
having
them
group
we
can
execute
different
operations,
one
of
the
operations
that
we
can
easily
execute,
even
in
a
processing
pipeline.
Before
the
back
end,
we
can
execute
thing
if
the
things
are
grouped,
we
can
calculate,
for
example,
utilization
out
of
totals,
or
we
can
call
calculate
other
things.
B
Yeah,
I
think,
having
a
rule
is
very
useful
because
it
allows
you
to
reason
about
whether
you
want
it
to
be
a
one,
metric
or
separate
matrix.
It's.
What
I'm
hearing
from
what
riley
is
saying
is
that
whether
the
rule
should
be
about
the
aggregation
or
something
else,
and
that
that
does
sound
interesting
to
me
anyway,
I
don't
think
we
can
make
a
decision
on
it
right
now.
Maybe
maybe
we
should
open
a
separate
issue
on
that
one.
So,
anyway,
with
the
original
issue,
we're
good
right
with
the
direction.
E
B
Document,
sorry,
can
you
explain
what
do
you
want
to
be
documented.
E
Yeah
like
now,
I
think
that
now
in
the
in
the
docs,
we
mentioned
some
like
very
general
guidelines,
but
if
we
want
to
avoid
this
discussion
that
we
are
having
now
about
which
one
is
the
best
between
the
two,
but
we
should
just
verify
this,
you
know.
Otherwise
I
can
imagine
in
six
months
a
new
person
coming
from
a
certain
deal
from
that
word
and
then
just
adding
this
and
it's
like
hey,
what's
happening,
you
know
and
he
never.
He
was
checking
the
guidelines
and
he
never
saw
this.
A
A
A
I'm
here
hi,
okay,
so
yeah.
I
just
wanted
to
talk
about
a
little
bit
about
the
project
management
guidance
that
was
added
to
the
specification
recently
it
talks
about
having
a
ttc
sponsors
for
each
project,
talks
about
having
a
project
board
and
project
tracking
issue.
Specifically
from
my
perspective,
I
work
in
the
client
side.
Sig
we've
been
working
on
in
that
group
for
for
a
long
time
now,
and
we
feel
like
we're.
We
really
need
some
help
with
some
specification
issues
that
we're
blocked
on.
A
So
I
would
like
to
based
on
this
new
project
management
guidance.
I
would
like
to
see
like
what,
if
we
could
request
a
tc
sponsor
to
start
attending
our
sig
meetings
on
a
regular
basis,
and
given
that
it's
a
new
process,
I'm
not
sure
that
there
is
a
process,
but
I
just
want
to
bring
it
up.
B
Yeah
there
is
no
tc
sponsor
right
now,
right
for
rom,
no,
no
one
was
identified,
and
so
I
guess
that
means
that
the
tc
needs
to
so,
if
you're,
making
a
formal
request
for
for
a
sponsor
than
the
pc
need
to
discuss
and
and
and
find
someone
well
provided
that
this
is
an
accepted
project.
I
think
it
is.
B
It's
been
there
for
a
while
now,
but
so
the
the
project
management
guidance
was
measured
just
recently
right,
I
don't
I
I
think
it
happened,
and
I
and
I
went
on
the
vacation
after
that.
I
don't
know
if
the
border
or
issue
was
created.
Does
anyone
know?
Do
we.
D
B
Okay,
so
we
need
to
act
on
this.
I
guess,
since
we
merged
it
yeah,
let's
start,
let's
start
doing
what
the
document
says
needs
to
be
down
the
board
and
that's
a
tracking
issue
and
let's
also
discuss
in
the
next
pc
meeting
the
sponsorship
for
this
particular
sig.
E
Yeah,
okay,
so
basically
disclaimer
those
are
not
mine,
but
those
are
things
that
seem
important
enough
and
the
first
one
is
about
process
threats,
naming
I
think
there
there's
agreement,
but
there
was
a
last
minute
discussion
regarding
the
actual
name,
whether
this
should
include
the
wrong
a
runtime
section
in
the
name
itself
yeah.
It
seems
that
in
general,
people
are
happy
without
having
this
runtime
part
in
the
name-
and
I
don't
see
jim
mcd
here
to
discuss,
I
think
he
was
the
one
proposing
that
we
at
the
wrong
time
part.
E
E
F
I
can
explain
the
reasoning
that
I
developed,
based
on
reading
through
the
specification,
which
was
that
process.runtime
is
currently
has
different
domains
under
it,
which
are
by
language,
so
it's
process.runtime.java,
process.onetime.net
process,
runtime,
goaling
and
so
process.
Runtime
spreads
feels
wrong.
It
does
not
feel
like
it's
with
the
language
it
feels
out
of
place
and
it
does
not
seem
like
it
should
be
on
the
runtime
either,
because
this
is
us
looking
at
a
process
from
the
outside,
which
is
just
like
you
would
run
top.
So
you
run
top.
F
You
get
information
about
the
processes
but
you're
not
actually
looking
at
the
runtime
of
the
process.
You're
not
inside
the
process,
you're,
not
looking,
so
you
could
actually
have
process
runtime
java
threads,
which
would
be
something
that
you
would
get
from
inside
java,
in
which
case
your
space
may
be
actually
even
richer
like
the
metrics.
For
that
would
be
much
more
detailed.
You
will
see
like
easier
the
demon
you
would
have
like
more
dimensions
for
that.
F
So
I
believe
that
plus
the
threads
on
its
own
is
is
more
valid,
but
I
this
is
from
interpreting
the
specification
where
the
intent
has
been
so
far.
So
it's
in
line
with
what
I
read
from
the
spec.
E
Yeah,
I
think
that
gemma's,
the
opinion
was
that
threads
doesn't
feel
right
in
gold
and
in
golang,
but
probably
that
can
be
true-
that's
an
exception
because
yeah
the
rest
of
the
languages,
I
think
we're
fine,
even
in
python
that
you
have
for
routines,
but
you
can
just
treat
them
separately.
You
know
like
threads,
is
you
know,
process
level
and
good
routines
on
the
runtime
one.
E
Okay,
so
let's
okay
perfect,
it
seems
that
we
have
agreement
on
that
part.
Only
somebody
else
wants
wants
to
raise
a
different
point.
If
not,
let's
comment
that
I
will
add
a
comment
there
and
let's
wait
for
germany,
okay,
the
next
one
is
about
hotel,
sdk
enabled
and
I
think,
there's
there
seems
to
be
also
a
final
agreement.
Then
again
it's
about
the
the
name,
whether
it
should
be
positive
or
negative,
by
default,
disable
or
enabled-
and
I
see
bruno
was
in
the
call
hey
yes,
so
I
don't
yeah.
Let's
go.
G
I
I've
just
commented
that
I
think
that
the
the
the
interpretation
should
be
the
opposite
of
what
tyler
has
proposed,
given
that
in
most
dynamic
languages,
any
non-zero
value
is
truthy
and
like
zero
and
empty
string
and
unsaid
are
falsy,
which
would
be
the
opposite
of
what
tyler's
proposed
right,
where
one
would
be
considered
true,
but
two
would
be
considered
false
and
that
just
strikes
me
as
very
wrong.
G
G
Sorry,
the
the
definition
that
that
is
currently
there
is
that
a
boolean
must
interpret
that
true
case
insensitively
as
well.
True,
anything
else
is
false.
G
H
So
I
think
that
that's
a
good
point
anthony
I
I
guess
two.
I
guess
you
would
sometimes
consider
to
be
true
as
well.
I
didn't
think
about
that.
I
was
really
coming
at
it
from
the
perspective
of
trying
to
be
cautious.
H
In
that
definition,
I
I
will
admit
I
don't
thought
through
all
the
language
implementations,
but
the
idea
being
that
like
if
it's
true
it
should
have
some
sort
of
like
positive
action
and
by
default
it
should
do
you
know
false,
and
so
you
want
to
make
sure
the
user
is
very
explicitly
trying
to
set
it
be
true,
similar
to
like
in
a
cli.
If
you
don't
hit
exactly
the
the
y
key,
you
know
it
doesn't
interpret
that
as
a
positive
affirmation,
but
I
I
got
your
point
about
other
languages.
H
That
may
not
be
the
case.
One
of
the
things
that
I
would
ask,
though,
is
there's
a
line
in
there
specifically
saying
that
you
can
extend
the
definition
of
truth
for
the
language
itself.
Would
that
be
useful
for
those
languages?
Do
you
see,
or
is
it
still
something
that's
systematic
to
the
definition.
K
Anything
worthy
of
sorry
anthony,
I
didn't
mean
to
cut
you
off
there.
I
think
an
extending
the
definition
is
likely
to
be
more
confusing,
but
I
would
I
was
going
to
argue
that
accidentally,
false
here
is
significantly
more
damaging
than
accidentally.
True
like
if
you
accidentally
disable
your
instrumentation
in
production,
because
you
have
sdk
enabled
equals
one
instead
of
sdk
enabled
equals
true,
is
significantly
more
damaging
than
accidentally.
H
Daniel,
I
think
you're
you're
right
and
that's
why
the
definition
is
switched
right.
So
there's
the
boolean
value
now
is
to
disable
the
the
sdk.
The
positive
action
to
take
there
is
disable,
which
would
mean
that
accidentally,
sending
it
to
true
would
be
the
the
more
destructive.
K
Yeah,
I'm
looking
at
the
pr
right
now,
it's
oh
it's!
It's
it's
wrong
in
the
spec
compliance
matrix
yeah!
I.
H
But
I
think
you
you
share
the
same
concern
that
I
did.
This
is
where
I
think
a
lot
of
the
the
concern
came
from,
and
I
think
that's
why
I
wanted
to
be
very
explicit
about
the
the
problem
that
I
came
to
is
just
this.
This
default
concept
of
true,
is
you
know
if
you
don't
have
something
set
or
there's
like
a
zero
value,
it's
usually
false.
H
So
I'd
want
to
make
sure
that
the
definition
you
know
if
unset,
it's
not
ambiguous
to
the
user,
that
you
know
if,
like
you're
saying
like,
if
it
were
the
opposite
definition,
it
could
be
confused
that
you
need
to
explicitly
you
know
accident,
not
accidentally
set
false,
whereas
this
way
the
false
is
the
is
the
safe
value.
K
Yeah,
if
the
semantic
is
disabled,
then
yeah,
I
would
prefer
that
it.
I
think
I,
like
the
current
definition.
K
Yes,
disabled
is
better
than
enabled
and
having
it
be
very
explicit
that
you're
trying
to
disable
it,
you
know
having
a
set
of
values.
That
is
very
clearly.
These
are
the
only
ones
that
will
disable
it,
I
think,
is
important.
I
would
I
did
mention
at
the
beginning
of
this.
I
think
extending
it
per
sdk
is
potentially
a
mistake,
because
operators
will
most
likely
want
to
just
apply
one
configuration
across
their
whole
environment
and
they'd
probably
be
really
confusing
if
it
behaves
differently
in
javascript
than
it
does
in
ruby.
H
Yeah,
that's
a
that's
a
fair
point
that
I
was
worried
about
as
well.
I
would
also
hate
it
if,
well,
I
don't
know,
maybe
everyone's
on
the
call
from
different
languages.
I
would
hate
it
if
we
defined
true
to
be.
H
You
know
what
we
did
here,
where
it's
a
string,
that's
a
true
value
and
some
other
language
that
comes
back
and
says
like
there's,
there's
never
any
use
case
where
we
will
ever
define
true
to
be
a
you
know,
a
string
if
it's
always
a
zero
or
a
one,
and
so
I
that's
why
I
added
it,
but
I
mean
I
guess
if
we
can
rule
that
out
across
the
specification,
I
have
no
problem
saying
that
we
should
take
it
out.
I
From
from
the
implementation
perspective,
it's
certainly
possible
to
say:
does
this
value
equal,
true
and
convert
that
to
a
boolean
right?
That's
a
string
comparison
that
gives
you
a
boolean
back
right.
Bullying
is
native
to
your
language.
So
I
don't
see
that
as
a
problem,
and
I
think,
if
we're
going
to
accept
only
true
and
only
the
case
and
sensitive,
true,
I'm
less
concerned.
What
I
would
be
concerned
about
is
accepting
any
value
other
than
true
as
truthy,
but
only
certain
values.
H
I
yeah
I
mean
I,
I
have
no
qualms
of
taking
out
the
extension
of
the
boolean
value.
That
seems
reasonable
to
me.
I
honestly
think
it's
also
one
of
those
things
you
could
add
back
in
later
on
if
we
find
a
really
good
reason,
so
I
guess
I
I
agree.
I
bruno
at
this
point.
I
I
Right
so
bringing
it
back
to
my
original
point,
I
think
separating
out
the
definition
of
boolean
value
semantics
for
environment
variables
from
this
pr
would
be
a
good
idea.
Let's
get
settled
on
what
boolean
value
environment
variables
mean
and
how
they're
should
be
interpreted
then
we
can
apply
that
to
this
concept.
H
H
G
H
I
think
it
should
still
matter
the
definition
that
we're
going
to
define
is
just
one
that
unset
and
empty
are
def
or
interpreted
as
false.
I
agree.
G
Okay,
because
I
imagine
that
there
are
many
environment
variables
that
have
kind
of
an
enable
disable
type
of
behavior
and
for
what
I
understand,
there's
not
the
practice
on
using
disabled
or
enabled
is
this.
Does
this
mean
that,
from
now
on,
this
type
of
variables
that
switch
on
and
off
should
have
the
disabled
semantics.
H
G
Yeah
so
meaning
that
they
should
all
be
disabled,
or
at
least
mentioned
disabled
online
or
whatever.
H
Whatever
the
example
said,
whatever
the
safe
option
is
right,
so
like
in
this
case
like
disabled,
because
true
would
be
a
positive
action.
But
you
know
if
it's
I'm
trying
to
think
of
an
example
off
the
cuff,
but
like
saying,
like
you
know,
sample
everything,
maybe
that's
not
something
that
you
would
want
to
have
the
default
being
false
right,
like
yeah.
E
Yeah,
let's
create
a
new
issue
just
to
discuss
that
and
then
a
pr
just
to
keep
track
of
those
things,
and
just
mention
that
this
is
blocking
this
one.
G
E
Okay,
thank
you
so
much
for
that
moving
forward.
Unless
there's
a
comment
there,
I
don't
think,
there's
a
comment.
There,
scope,
scope,
short
name,
attribute
edition,
yeah.
We
we
are
basically
you
know
now
that
scopes
support
attributes.
Maybe
we
want
to
add
this
short
name.
E
B
B
So
what
I
would
like
to
see
is
I
I
think
we
need
to
decide
generally
about
how
how
are
we
naming
the
scope
attributes?
So
this
one
uses
a
prefix
scope,
scope,
dot
and
the
question
I
have
is
the
following:
are
we
suggesting
that
all
attributes
all
scope
attributes
are
going
to
have
this
score
this?
This
prefix.
B
All
right,
so,
okay,
so
with
that,
I
have
a
concern
as
well,
because
no
other
attribute
sits
in
the
in
the
I
guess
top
level
without
any
prefix
without
any
name
space.
Everything
else,
every
other
attribute
that
we
have
defined
in
the
semantic
conventions
has
some
sort
of
prefix.
So
this
one,
if
it's
called
just
a
short
short
name
without
any
prefix,
it
looks
it
looks
kind
of
kind
of
wrong
right.
It
looks
like
it
looks
like
an
exception
which,
which
I'm
not
sure,
how
do
we
justify?
B
B
So
there
we
made
a
decision
to
prefix
these
two
fields,
name
and
version
by
by
essentially
what
is
the
name
space
there
right,
hotel,
dot
scope?
B
B
I
can
see
only
non-working
solutions
here
right
either
way.
Something
seems
off
with
prefix.
It
is
off
without
prefix
it
is
off.
So
I
don't
know
what's
the
solution
here
to
be
honest,
but
I
still
don't
see
the
the
one
that
actually
is
generic
enough
as
a
rule
that
we
can
apply
to
all
upcoming,
maybe
future
attributes
and
also
fits
the
the
the.
Although
is
consistent
with
what
we
have
so
far.
B
A
J
J
Okay,
and
as
for
the
namespacing
discussion,
I
think
the
hotel
dot
namespace
would
make
sense,
because
that
one
is
about
meta
things
that
are
coming
from
hotel
itself
from
the
hotel
world,
whereas
the
non-hotel
prefixed
ones,
those
are
the
the
monitored
entities
describing
those
those
themselves.
Whatever
is
is
observed
there,
but
the
the
scope
name
and
the
the
scope
shortening
would
be
an
hotel
thing,
and
I
think
it's
fine.
If
it
goes
into
the
author,
namespace.
E
B
B
B
I
B
Maybe
that's
a
good
suggestion.
Maybe
that
can
help.
I
don't
know
in
this,
so
I
the
pr
doesn't
define
that.
I
think
it
doesn't
right.
I
think.
I
B
Yeah,
I
don't
know,
maybe
so,
if
we
have
an
attribute
like
event.domain,
for
example,
the
one
that
was
proposed
for
events
and
that
that
will
be
recorded
on
the
scope
when
we're
exporting
to
some
other
format
that
becomes
hotel.scope.event.domain,
which
kind
of
sounds
like
a
stretch.
To
me
to
be
honest,
and
I
would
much
prefer
it
to
remain
that
event.domain,
instead
of
being
prefixed.
J
E
E
L
Hello-
everyone-
I
came
maybe
a
month
or
so
ago,
but
yeah
basically,
there's
been
a.
If
you
don't
already
know,
there's
been
a
group,
who's
been
working
on
a
proposal
for
getting
profiling
accepted
as
a
supported
event
type,
and
we
have
been
yeah
working
for
a
couple
months
now
and
basically
now
we're
kind
of
trying
to.
L
I
guess
we
started
this
before
this
project
management
doc
was
created.
So
we've
already
done
a
lot
of
the
points,
but
you
know
at
the
beginning
of
that
doc.
It
talks
about
the
minimum
requirements
being
a
group
of
subject
matter
experts
or
just
like
people,
particularly
interested
in
a
topic.
We
have
that
we've
been
meeting
a
bunch,
a
portion
of
the
tc
being
aware
of
the
project
and
participating.
L
We
now
have
two
tcu
members
who
have
you
know
volunteered
to
do
so
and
then
the
last
point
on
there
is
that
the
spec,
approvers
and
broader
community
need
to
be
aware
of
progress
being
made
on
the
project
so
that
they
can
be
prepared
to
participate
when
proposals
are
ready
for
review,
and
so
that
is
the
one
that
we
have
not
done
yet.
But
we
are,
you
know.
L
That
is
why
I'm
here
now
making
the
broader
community
and
spec
approvers
aware
so
so
yeah
I
put
a
link
to
what
we
have
so
far.
We're
still
kind
of
like
finalizing
a
couple
things
there,
and
so
we're
gonna
finish
it
in
the
next
week,
maybe
either
this
week
or
next
week,
so
either
the
next
specification
meetings
or
the
one.
After
that,
we
will
hopefully
have
a
finalized
version,
a
sort
of
president
to
this
group,
but
in
the
meantime,
wanted
to
kind
of
make.
L
You
aware
feel
free
to
like
add
any
questions
or
comments.
As
you
take
a
look
at
that,
and
let
us
know
if
there's
any
thing
that
we're
missing,
we
used
the
sort
of
logs
proposal
as
a
a
combination
of
the
logs
proposal
and
just
the
hotel
sort
of
like
mission
and
vision
statements,
kind
of
emerging
of
the
two
to
kind
of
like
structure
the
the
way
that
we
built
that
document,
and
so
hopefully
it
should
align
pretty
well
with
you
know,
other
proposals
that
have
come
through
this
group
so.
B
L
Yes,
they
are
third
or
we
do
right
now,
we've
been
or
we've
moved
to
every
other
thursday.
So
it's
not
this
thursday,
but
the
one
after
that
I
mess
up
my
standardized
times,
but
it's
at
8
am
pacific
time.
Whatever
time
that
is,
I
guess.
B
E
Okay,
I
am
interested,
so
I
will
be
joining
by
the
way,
I'm
just
going
back
for
holidays,
but
yeah.
I
should
have
time
to
show
up.
I
don't
know
whether
still
as
a
tc
sponsor,
but
at
least
I
will
come
around
and
we
will
discuss
in
the
nxtc
meeting
this
part
regarding
the
sponsorship.
L
That's
all
I
have
just
check
out
that
doc
and
you
know,
especially
as
people
who
are
familiar
with,
I
guess
similar
proposals
would
be
great
to
have
some
input
on.
You
know
anything
that
we
could
add
to
make
it
stronger
or
anything
that
we
sort
of
like
missed
addressing
in
it,
but
thanks
everyone.