►
From YouTube: 2022-03-22 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
C
Okay,
I
think
we
can
start
so.
I
have
the
first
item.
I
prepared
a
change
to
the
spec
that
adds
plain
http.
As
an
alternate
transport,
I
tried
to
make
minimal
changes
to
the
spec,
but
I
wonder
if
what
I
have
there
actually
is
clear,
or
we
need
more
clarifications
to
explain
how
what
the
differences
are
when
the
hdb
transport
is
used,
because
the
original
spec
was
written
all
with
websocket
in
mind.
C
So
it
would
be
great
if,
if
you
guys
can
have
a
look
and
read
and
see
if
it
does
make
sense,
not
just
the
change
itself,
but
the
other
parts
of
the
spec
as
well
right.
So
there
is
these
descriptions
of
the
operations
everywhere
with
the
sync
sequences
of
the
requests
and
responses.
I
wonder
if,
if
each
in
of
those
sections,
we
need
any
sort
of
comments
that
explain
any
differences
that
that
that
may
be
in
the
operation
of
the
all
the
requests
and
responses
when
the
http
plain
http
is
used.
C
so
would
be
good
to
have
some
eyes
on
this,
because
I'm
not
completely
sure
myself
that
I
that
the
change
I
have
there
is
completely
clear
and
then
covers,
is
not
ambiguous
and
covers
all
everything
that
we
want
to
have
there,
and
anybody
had
any
any
thoughts
on
this.
Did
you
have
a
chance
to
think
about
this?
This
was
an
open
issue
for
for
a
while.
So
I
don't
know
if
anybody
has
any
thoughts,
opinions
about
this-
that
we
can
talk
about
now,
if
you
do.
C
D
Yeah,
the
so
the
first
one
we
ran
into
some
issues
with
the
agent
disconnecting
and
then
trying
to
reconnect
the
reconnect
works
great.
The
problem
is
that
when
it
reconnects
it
doesn't
identify
itself.
So
there's
no
agent
description
sent
there's
no
status
report
sent.
That
is
all
kind
of
queued
up
in
in
the
start
function
and
so
after
disconnect
and
then
reconnect
from
the
server's
perspective.
This
is
a
brand
new
connection.
You
know
there's
no
memory
of
where
this
came
from.
D
The
implementation
not
adhering
to
the
spec
yeah
I
wanted
to
before
proposing
a
change.
I
wanted
to
make
sure
we
were
on
the
same
page
and
had
a
discussion
about
it.
C
Yeah,
I
think,
you're
right.
I
think
that's
that's
what
I
remember
from
the
spec.
If
you
can
maybe
also
locate
the
place
in
the
spec
that
says
it
needs
to
be
done
so
and
if,
if
there
is
nothing
in
the
spec
that
that
would
be
a
good
addition
to
the
spec
and
then
I
sure.
C
D
Okay,
okay
and-
and
I
think,
actually,
we
kind
of
cleared
everything
up
with
the
remote
address
and
header.
I'm
finally
going
to
header
out,
I
think,
there's
in
general
with
the
callbacks,
for
example,
the
all
right.
Sorry,
just
look
at
the
actual
callback
again.
D
The
there's
a
little
bit
of
a
a
disconnect
where,
like
with
on
connected
you're,
given
a
connection,
but
the
only
thing
you
can
do
with
the
connection
is
to
send
and
it's
not
clear
what
you
would
send
or
who
you're
sending
it
to,
because
you
don't
have
an
instance
uid
at
that
point,
you
don't
really
have
any
information
about
the
agent.
So
I'm
not
sure.
D
I
noticed
that
the
reference
implementation
doesn't
use
that
callback,
and
I
noticed
that
that
wasn't
used
in
the
sensu
code
that
was
shared
a
while
ago
either.
I'm
not
sure
what
really
to
do
with
that.
Obviously
it's
easy
to
ignore
it,
but
it
just.
I
just
thought
it
was.
C
C
Callbacks
right,
one
is
on
connecting
which
I
think
is
useful
for
stuff,
like
authentication
to
gets
the
the
request
right.
You
can
verify
headers
and
the
stuff
the
other
one
on
connected.
I
don't
remember
why
I
added
it
there,
so
maybe
it's
actually
purposeless,
I
guess,
but
it
will.
D
C
C
So
I
guess
at
least
for
that
purpose,
it's
useful,
but
once
we
got
the
the
address-
and
I
guess
so
the
header-
I
think
I'd
like
to
understand
if
there
is
a
way
that
we
can
generalize
this,
because
in
grpc
I
believe
there
are,
there
is
an
equivalent
to
headers
right
that
you
can
send
with
with
the
grpc
stream.
If
I'm
not
wrong,
I
don't
know,
what's
the
name
for
that
thing,
is
it
headers
as
well?
You
know
metadata.
C
And
it's
also
a
map
of
strings
to
strings
right,
so
it
kind
of
is
similar
to
the
http
headers.
C
B
C
C
And
the
metadata
grpc
metadata
when,
if,
if
we
decide
to
add
grpc
streams
as
a
transport,
it
is
for
the
streams
it's
it
is
sent
once
right,
not
for
every
message,
but
it's
sent
once
when
the
stream
is
established
right.
Is
it
correct?
Do
you
know
I
kind
of.
C
D
There's
just
a
little
bit
of
a
disconnect
at
the
moment
because
the
you
know,
let's,
let's
consider
the
case
of
like
mutual
tls,
where
you're
receiving
a
client
certificate
that'll
be
available
on
the
http
request,
and
you
can
use
that
for
authenticating,
but
you
couldn't
use
any
identifiable
information
in
there
because
you
don't
have
anything
to
share
it
on
you,
don't
have
a
connection,
you
don't
know
what
the
you
don't.
You
haven't
received
a
status
message
or
agent
description.
D
Yet
so
you
don't
so
there's
a
little
bit
of
a
disconnect
between
the
the
on
connecting
which
you
can
use
for
authentication
yeah,
and
then
you
can
say
okay,
this
agent's
great.
I
can
talk
to
it,
but
I
don't
at
that
point.
You
don't
know
what
agent
it
is,
and
so
I
think
you
know
just
thinking
about
how
these
these
different
things
were
connected.
It
seemed
like
if
we
could
have
a
little
bit
more
information
preserved
on
the
connection
to
understand.
D
D
C
C
Where
is
that
it
should
be?
In
the
example,
I
think.
C
I
don't
see
it.
Where
is
that
it
should
be
somewhere
anyway.
I
can.
I
can
check
it
after
the
call,
but
I
think
you're
right
anyway,
you're
right,
because
you
would
want
well
it's
at
least
this
certificate
is
actually
probably
accessible
in
the
on
connecting
callback,
but
it
yeah
you're
right.
If
you
don't
know
what
what
the
idea
of
the
thing
is.
C
Well,
you
don't
know
anything
about
the
connecting
thing
except
the
certificate.
Maybe
it's
not
that
useful
right.
Unless
you,
you
use
unique
certificates
for
each
of
the
connecting
clients
anyway,
I
agree
that
headers
would
be
useful.
Let's
see
if
we
can
actually
name
it
properly.
I
guess
it's
more
of
more
of
a
naming
exercise.
You
can
name
it
properly.
It
should
work
for
the
consider.
A
C
Headers
are
just:
are
they
just
a
map
of
strings
to
strings
or
if
we
ignore
the
mutation
part,
or
there
is
more
to
that.
C
Okay,
so
let's
do
this:
let's
check
the
let's
check
what
we
did
in
the
collector.
This
should
be
solved
sound
somehow
there,
because
we
had
the
exact
same
problem
and
then
we'll
see
how
we
model
this
here.
D
Should
be
doable
and
my
consideration
for
using
this
was
really
to
be
honest,
to
pass
the
instant
cuid
up
within
a
header
so
that
I
can
correlate
these
things.
So
you
know
speaking
of
our
own
implementation,
there's,
so
maybe
there's
there's
a
better
solution
to
that.
Overall
problem
of
how
to
correlate
who's
getting.
C
D
Right
there's
at
that
point
I
I
guess
I
would
say
that
there's
there's,
there's
still
a,
I
think,
a
question
for
us
in
the
on
connecting
how
to
correlate
that
to
when
a
message
of
the
on
message.
Callback.
You
know
the
thing
that
we
were
talking
about
a
moments
ago,
identifying
actually
who
is
connecting
now
and
the
headers
can
give
you
can
you
can
cheat
a
little
bit
by
sending
some
metadata
up
in
headers
that
you
can
then
correlate
to
metadata.
That
appears
in
messages.
C
C
A
A
C
C
Okay,
so
let's
do
that
I'll
I'll
check
with
with
jurassic
or
I
will
look
at
the
collector
club
base
and
we'll
borrow
the
idea
from
there
and
we
can
use
it
here.
B
Yeah,
but
by
the
way
I
quickly
check-
and
if
this
helps
I
post
that
in
the
pr
like
the
the
snippets
of
code
that
we
or
links
to
code
that
we
do
use
for
extracting
headers
from
grpc
and
http.
Currently
in
the
collector.
B
C
A
I
think
I
have
one
question,
but
I
think
maybe
maybe
according
to
the
spec
but
me
if,
if
you're
logged
and
asked
so
I
think
we
I
don't
see
the
mention
of
how
the
agent
is
installed,
the
first
time
when
the
agent
installed
the
first
time.
I
don't
see
any
data
that
is
like
the
implementers
are
free
to
like
talk
about
it.
C
Yeah,
it's
outside
of
the
scope
of
this
spec,
doesn't
mandate
any
specific
behavior
for
for
setting
up
the
agent
right
for
installing
it
it
does
mention.
I
mean
it
touches
it
a
bit
in
the
there's
a
section
about
accepting
the
client
certificate
for
the
first
time
and
trusting
trust
on
first
use
and
all
that
stuff.
It's
kind.
C
Doesn't
doesn't
actually
make
it
a
mandatory
behavior
in
any
way,
it
just
says
that
it's
a
possible
option,
something
like
that
is
a
possibility
that
the
protocol
allows
doing
that,
but
it's
not
a
requirement
in
any
way.
So,
essentially
it's
an
implementation
detail
for,
for
a
particular
agent
agent,
specific
behavior,
the
the
respect
tries
to
stay
away
from
that.
I
don't
know
if
we
need
to
be
more
specific,
more
prescribing
here,
I
I
initially.
I
hope
it
to
be
more
flexible
here,
rather
than
more
prescribing.
D
I'd
be
happy
to
talk
some
more
about
shutdown
and
my
thoughts
on
it.
I
know
I
missed
the
meeting
two
weeks
ago
and
I
can
at
least
describe
what
what
what
our
use
case
is
for
it.
Yeah
yeah
sure.
Let's
do
that,
so
we
basically
were
with
a
if
you
imagine
so,
a
future
state
where
we
have
a
supervisor,
that's
using
op-amp
that
is
connected
and
that's
running
the
collector
as
a
another
process
or
some
process.
D
The
idea
with
shutdown
is
is
not
necessarily
to
I
mean
it
could
be
interpreted
differently,
but
not
to
shut
down
the
supervisor
but
to
shut
down
the
collector
just
to
free
up
resources,
basically
put
a
pause
on
collecting
telemetry
data
for
that
particular
system
that
that
agent's
running
on
and
then
a
restart
would
tell
the
collector
to
start
up.
So
you
could
imagine
you
know
thousands
of
pages
distributed
across
the
data
center.
D
C
I
understand
if
you
look
at
the
spec,
the
word
supervisor
is
not
mentioned
actually
in
the
specifications.
So
if
we
do
that,
then
somehow
we
need
to
introduce
it.
I
guess
right
either
we
make
it
a
possible
model
of
operation
where
you
do
have
a
supervisor
and
in
that
context
the
shutdown
command
now
has
a
specific
meaning
or
unless
we
do
that.
In
that
case,
it's
unclear
right.
How
do
you
what's
the
semantics
of
shut
down?
If
you
don't
mention
the
supervisor
at
all
right,
that's
the
part
that
is
not
clear.
D
Yeah,
so
that
was
part
of
the
intention
with
adding
the
agent
capability
of
support
shutdown.
So
you
know
many
agents
might
not
support
shutdown,
in
which
case
you
wouldn't
offer
that
as
an
option
in
the
agent
management
system.
C
A
capability
not
tied
to
the
supervisor,
but
it's
something
that
the
agent
admits
it
can
do.
It
says
I'm
capable
of
shutting
down,
so
you
can
shut
me
down
now.
Whatever
that
means.
D
I
know
that's
not
helpful,
but
you
know
I
don't
know
you
know
if
there's
a
better
way
to
describe
that
capability
or
if
shutdown
you
know,
certainly
does
sound
like
terminate
or
you
know
something
not
like
pause,
but
I
don't
know
what
what
better
way
to
add
an
another
message.
Basically
to
this.
C
Right
to
restart
so
that
that
should
be
the
part
of
the
semantics,
the
shutdown
needs
to
be
defined
in
a
way
that
implies
that
the
connection
remains
active,
at
least
that
that
should
be
in
the
specification.
Even
if
you
don't
say
how,
if
there
is
you
don't
talk
about
the
supervisor,
I
wonder
if
you
say
so,
is
there
maybe
a
different,
better
wording
like
it's
not
shut
down?
Maybe
a
different
terminology
stop
or
something
yeah,
something
like
that.
D
At
the
moment,
our
implementation,
it
will
just
be
to
send
a
new
config
down.
That
does
nothing
and
then
we
want
to
start
it
back
up
we'll
send
a
config
down.
That
does
something
so
there's
it's
not
it's
not
that
there's
not
a
solution,
but
this
would
be
a
way
to
preserve
the
config
on
the
system,
leave
it
in
place
but
to
terminate
the
collection.
C
C
C
C
B
B
D
D
Is
this?
Is
this
something
that's
interesting
to
people
or
I
don't?
I
don't
want
to.
We
have
a
workaround
and
we
have
a
solution
to
to
support
this.
I
I
don't
think
it's
necessary,
but
it
I
do
think
it's
useful,
but
if
it's
not
useful
in
general
to
the
rest
of
the
community,
there's
no
need
to
push
it.
E
D
D
D
And
I'll
take
a
stab
at
proposing,
stop
and
first
as
a
as
a
change
to
the
spec.
In
addition,
it's
back
and
then
we'll
have
a
pr
to
follow,
which
should
be
pretty
straightforward.
Okay,.