►
From YouTube: 2022-03-08 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
How
are
you
I'm
doing
good?
Actually,
I'm
in
a
similar
time
zone
for
this
week,
you're
you're,
visiting
yeah,
I'm
in
redwood
city?
Actually,
sean
porter
might
join
me
in
in
the
room
here
in
a
bit
so
cool.
A
B
A
Okay,
so
maybe
we
should
start,
I
I
have
put
a
couple
items
there
in
the
agenda.
The
first
one
is
about
the
detached
signatures,
so
you
know
this
is
not
really
an
area
of
expertise.
For
me,
I'm
not
quite
sure
that
this
is
the
right
thing
to
do.
The
the
spec
was
previously
saying
that
just
verify
the
the
content
of
the
file.
However,
you
want
it's
the
responsibility
of
the
agent,
but
I
think
it
kind
of
ignored
some
of
the
reality
around
how
this
this
verifications
work
right.
A
A
I
guess
what
I'm
looking
for
here
is
some
sort
of
validation,
confirmation
from
people
who
do
have
experience
with
with
signing
packages
more
experience
than
I
do
to
see
whether
this
is
the
right
thing
to
do,
whether
this
is
going
to
work
or
no.
I
don't
know
if,
if
anybody
had
a
chance
to
have
a
look
at
that,
I
see
you.
Oh
I
see
you
approved
it
just
a
couple
hours
ago,
I'm
trying
like
do
you
yeah.
B
A
That
would
be
great
if
anybody
is
an
actual
expert
here,
I'm
not.
It
would
be
great
to
have
the
feedback
to
understand
that
this
is.
This
is
the
right
approach,
but
I
I
did
my
best
as
far
as
I
could
understand
how
these
things
work.
It
should
be
the
right
case,
but
I
don't
know
anybody
else.
Maybe
in
this
call
nose.
A
Okay,
sorry,
okay,
all
right,
okay,
so
the
other,
the
second
one
that
I
posted
there
somewhat
related
to
that,
but
different
in
the
in
the
spec.
Again
when,
when
we
pushed
messages
about
files
to
be
downloaded
from
the
server
to
the
agent,
it
included
the
url
to
download
from
and
a
hash
of
the
content.
A
But
it
didn't
specify
the
hashing
method,
and
then
it
claimed
that
the
hash
could
be
used
by
the
agent
to
verify
the
download,
which
is
weird.
How
do
you
verify
if
it
doesn't
say
what
the
hashing
method
is
right?
So
I
think
andy
commented
that
that
he
read
it
as
a
as
an
intent
that
it's
going
to
be
agent
specific
right.
So
the
the
server
and
the
agent
have
this
pre-existing
knowledge
about
what
the
hashing
method
is
for
the
particular
agent
which
which
I
think
it's
a
possible
approach.
A
A
Maybe
shot
to
56
right
and
make
it
independent
of
the
agent
right
so
that
then,
the
actual,
downloading
and
verification
of
the
downloaded
file
can
be
part
of
the
library
that
we
are
implementing,
rather
than
we
offload
this
responsibility
to
each
particular
implementation,
which
again
is
going
to
be
doing
almost
exactly
the
same
thing.
Maybe
exactly
the
same
thing,
and
we
were
just
not
benefiting
from
from
having
this
definition
in
the
spec
and
just
doing
that
the
implementation
in
the
in
the
in
the
library
itself,
rather
than
in
each
particular
agent.
B
256
and
perhaps
we
should
be
more
flexible
and
instead
of
specifying
like
single
field
for
that
algorithm,
maybe
we
should
just
specify
the
field
for
the
algorithm
name,
so
that
would
provide
more
flexibility
to
the
agent
and
server
to
support
even
multiple,
like
hashing
algorithm,
because
one
thing
is
that
I
one
thing
about
hashing
algorithm
for
me
is
that
every
now
and
then
there
is
like
a
new
one
that
replaces
the
previous
one,
and
I
know
that
shot
256
is
very
strong,
but
this
this
still
might
change.
C
So
if
you
have
a
presumed
single
type,
you're
going
to
have
a
hard
time
coordinating
that
upgrade.
If
we
do
go
to
sha
1024
right
that
somehow
you
got
to
figure
out,
you
know
it's
going
to
make
it
more
difficult
to
make
that
leap
frog.
Even
if
you've
only
got
the
you
know
the
one
h
and
then
one
distribution.
A
Yeah
you
we
could,
let's
say
later
other
field
which
specifies
the
method
and
define
that
if
the
value
is
missing,
it
means
shot
256
right,
something
like
that.
It
could
be
added
in
a
backwards
compatible
way.
So
I
understand
that
maybe
it
would
be
necessary
in
the
future,
so
we
we
keep
that
possibility
open
right
it
doesn't
that
door
is
open.
We
do
not
have
to.
A
I
guess
we
do
not
have
to
decide
right
now.
Unless
we
see
the
need
to
actually
have
multiple
hushing
methods
right
now
is
there
a
need?
I
think
there
is
no,
probably
I
don't
know
I
mean
this
kind
of
places,
a
requirement
on
your
on
your
distribution
server
right.
Is
it
a
dif
requirement
that
is
difficult
to
fulfill?
A
Do
we
need
to
give
the
flexibility
to
the
implementations
to
make
this
decision
or
it's
fine,
to
impose
a
specific
one
kind
of
my
gut
feeling
is
not
not
such
a
big
deal
like
if
you
have
a
file
somewhere,
you
don't
know
what
the
sha-256
is.
You
can
just
maybe
download
and
calculate
and
then
send
the
message-
maybe
not
the
best,
not
very
efficient
way,
but
it's
it's
still
possible
right,
not
impossible.
A
C
I
don't
know
that
it
necessarily
needs
to
be
specified,
but
I
I
don't
I'm
there
like
again.
This
is
something
I
don't
know
a
lot
about,
so
I
think
there.
If
we
specified
that
hey
it's
going
to
be
shot
256.
It
gives
somebody
an
opportunity
to
scream
that
hey.
They
need
something
different
and
tell
us
why.
A
D
So
if
I
may
suggest,
let's,
let's
call
it
the
default
algorithm,
it
can
be
sha,
256
or
whatever,
and
that
leaves
it's
very
open
to
suggestions
that
it
can
be
changed
in
the
future
or
in
in
a
particular
implementation.
C
A
B
A
C
Think
if
I
was
looking
in
the
documentation
that
I
saw
that
it
was
a
default
and
I
wanted
to
do
something
different.
That
would
probably
lead
me
on
a
bit
of
a
chase.
So
I'd
want
to
make
sure
that
it
was
clear
that
it's
a
default
and
if
there's
reason
for
it
we'll
add
the
the
knobs
in
for
it.
But
there's
no
real
way
to
set
it
right
now.
C
B
Yeah,
I
I
I
just
commented
that
in
the
spec
pr
as
well,
but
my
suggestion
would
be
to
have
a
separate
field
with
the
name
of
the
hashing
culprit.
Even
if
this
black
always
shot
256,
it
gives
out
the
flexibility.
If
someone
will
want
to
use
something
as
in
the
future,
and
not
that
many
extra
bytes
in
the
message.
A
B
Well,
I
think
it's
like
for
the
agent
and
server
to
decide
like
how
they're
going
to
handle
that
case.
I
think
that
it's
like
hashing
algorithm
are
so
common
thing
that
there
will
be
like
no
no
surprises,
maybe
like
just
new,
stronger
algorithm,
that
some
organizations
might
prefer
in
the
future
and
will
implement
it
into
their
like
server
and
client
implementations.
A
B
Yeah
but
yeah,
but
I'm
thinking
that
there
should
be
like
two
strings.
One
string
is
the
the
name
of
the
algorithm
and
the
other
string
is
the
actual
hash.
So
now
the
when
the
agent
ex
gets
the
name
of
the
algorithm,
it
should
be
like
a
name
it
understands.
If
it's
a
name,
it's
it's,
not
understanding.
It
cannot
do
anything
about
this
hash.
A
D
If
the
string
is
not
recognized,
stringed
algorithm,
I
think
it
should
handle
it
the
same
way
as
if
the
hash
value
would
be
incorrect,
which
of
course
means
rejecting
the
the
the
file.
C
Could
we
do
a
hybrid
of
having
the
field
that
says
shot
at
256
and
having
that
part
of
the
spec
for
the
first
version
that
you
know
it's
there,
it's
clear
what
it
is,
it's
clear
that
that
could
be
upgraded,
but
right
now
the
only
thing
we
support
is
shot
256.
We
don't
have
to
worry
about
that
that
whole
tree
of
decision
making.
A
A
So
my
my
question
here
was
about
what
actually,
what
does
does
it
mean
to
shut
down
an
agent?
What
is
the
expected
behavior
here,
the
semantics
of
the
command
are,
are
a
bit
unclear
to
me
and
is
not
here
right.
He
had
an
opinion
about
this
one.
So
I'm
not
sure
what
do
you?
What
do
you
guys
think
can
we
is
it
possible
to
define
it
in
a
way
that
is
meaningful,
like
shut
down,
go
away
forever?
What
does
that
mean?
What
does
that
mean?
It's
not
quite
clear
to
me.
A
If,
if
the
agent
is
supposedly
the
agent
is
installed
somewhere,
where
it's
probably
automatically
started
at
put
time,
does
this
mean
you
have
to
disable
the
that
capability
does?
Is
it
equivalent
to
uninstalling,
essentially
the
agent
right,
because
it
needs
to
go
away
forever,
or
is
it
just
to
shut
it
down
just
for
this
session?
If
you
restart
the
machine,
then
it's
going
to
be
back.
B
Yeah,
it's
a
good
question
like
what
are
the
use
cases
for
that
commands.
I
believe
that
uninstalling
should
be
like
a
separate
command
because
it
should
be
not
about
just
shutting
down
but
also
cleaning
up
the
resources
removing
from
auto
start
scripts,
and
things
like
that
and
my
understanding
and
or
like
how
I
would
anticipate
like
the
shutdown
or
restart
commands
are
being
used,
is
that
this
is
when
there
are
some,
maybe
some
performance
or
resource
usage
issues
and
temporarily
the
agent
needs
to
be
shut
down
to
reduce
the
the
impact
on
the
infrastructure.
A
So
the
restart-
I
guess
I
understand
right,
supposedly
you
wanted
to
to
to
be
starting
afresh
right.
So
maybe
it's
I
don't
know
doing
something
wrong.
My
memory
leaks
are
consuming
lots
of
memory.
Somehow
I
don't
you
restart
it,
it's
more
or
less
understandable.
The
shutdown,
as
you
said,
temporary
right.
But
how
long
is
that
right?
What
what
exactly
does
it
mean
for?
How
long
is
it
going
to
be
until
the
next
machine
restart
or
what
does
that
mean?
A
A
A
A
A
D
D
A
B
B
D
A
Imprimic
you're
saying
start
right:
even
you
can
have
a
start
command
in
that
case.
If,
if
we
assume
there
is
a
supervisor
which
can
shut
down
just
the
agent
the
sub
process,
then
reasonably,
we
could
expect
that
it's
also
possible
to
start
it
after
it
is
shut
down,
but
that
that
is
only
possible.
If
you
assume
there
is
a
supervisor
so
that
that
semantics
need
to
be
somehow
defined.
B
B
It
could
be
like,
provided
that
server
wants
the
agent
to
be
disabled,
and
it's
like
up
for
the
for
the
agent
to
to
handle
that
and
then,
when,
like
sometime
passes,
maybe
it
wants
this
flag
change
to
to
false
which
which
enables
the
agent
back
rather
than
just
making
like
impressive
commands,
shutdown,
start
and
etc.
A
A
A
B
I
have
just
one
quick
note,
because
I
missed
the
the
last
meeting
and
there's
this
instance
id
draft
pr,
so
I
just
want
to
say
that
I
was
thinking
about
it
and
I
think
that
being
able
to
have
this
temporary
instance
uids
by
sent
by
the
agent
and
the
agent
explicitly
asking
for
new
agent
uid
and
to
be
generated
by
the
server,
would
solve
the
edge
case
with
the
multiplex
connections
yeah.
B
A
So
you're
saying
keep
the
instance
id
a
required
field.
We
do
not
make
it
optional.
You
cannot
omit
it
if
the
agent
needs
an
id,
even
if
it's
for
the
first
time,
then
it
can
just
pre-generate
one
temporarily
put
it
in
the
message
also
indicate
that
it
needs
an
id
a
new
id
somehow
in
the
flags
somewhere,
and
then
the
server
pushes
the
new
one.
Exactly
would
be
the
approach
and
you
would
use
the
the
exact
same
functionality
to
to
initiate
the
regeneration
from
the
server
side.
A
B
Yeah,
exactly
and
we've
been
actually
discussing
this
with
my
colleagues
here
at
sumo,
and
we
believe
that
this
might
be
a
pretty
common
case
when
someone
is,
for
example,
cloning,
the
virtual
machine
or
the
the
image
like
this
might
happen
that
the
the
the
the
several
agents
with
the
same
id
will
be
reported.
And,
of
course,
we
might
tell
the
users.
Don't
do
not
do
that,
but
eventually
someone
will
do
that
and
instead
of
failing,
we
can
handle
that
gracefully
and
being
able
to
regenerate
the
instance.
Id
will
open
the
path
to
the
zone.