►
From YouTube: CNCF Serverless WG Meeting - 2018-11-29
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
B
C
C
C
B
F
G
G
C
C
D
C
C
E
C
G
E
C
Morning,
someone
else
go
flying
by
good.
G
C
K
A
C
Problems
Neela,
you
look
off
mute
for
a
sec,
okay,
say
what
well
catch
up
later,
these
guys,
let's
go
and
get
started.
Dude
you've
got
a
very
full
agenda.
That's
see
how
much
we
can
get
through
so
community
time.
So
this
is
a
quick
time
for
people
who
may
not
normally
join
the
call
to
bring
up
any
topics.
They'd
like
to
mention
or
have
a
short
discussion
on
I
know.
We
have
a
couple
new
people,
any
other,
any
new
topics
you
want
to
bring
up.
C
C
I
think
the
only
thing
kind
of
worth
mentioning
is
that,
from
a
burgeoning
perspectives
and
I
sent
that
ended
about
this
last
night,
we
will
not
be
versioning
the
SDKs
at
the
same
level
as
a
spec
themselves,
meaning
the
SDKs
be
able
to
change
their
version
over
as
they
see
fit
or
as
necessary.
The
way
people
will
then
know
what
version
of
the
SDK
goes
with,
which
version
of
the
cloud
event
spec
is
by
checking
the
documentation.
So
we
just
make
sure
that
a
Doc's
are
up
to
date
on
all
that
stuff.
C
If
you
have
any
concerns
about
that,
please
go
ahead
and
respond
back
to
my
note
or
join
the
weekly
call,
but
that
was
the
decision
that
they
made
yesterday.
So
I
just
want
to
bring
that
up
for
you
guys,
because
I
think
everything
else
is
pretty
standard,
but
that
was
only
thing.
It's
kind
of
exciting
all
right.
C
Any
questions
on
that
all
right,
I,
don't
see
Kathy
on
the
call
and
I
don't
live
anything's
happening
with
the
workflow
stuff,
so
I,
don't
think,
has
anything
to
say
there
relative
to
coop
calm
as
our
right
now
I.
Don't
think
we
have
any
new
slides.
We
just
have
the
Shanghai
ones.
I
was
gonna.
Take
the
action
item
to
convert
the
slides
over
to
the
to
the
Seattle
template
that
they
have
I
assume
they
have
a
different
template.
I
haven't
checked
yet,
but
I
assume
it's
out
there.
C
So
please
just
speak
up
and
after
the
call
just
drop
me
a
note
and
figure
out
some
way
to
get
you
in
there.
If
you
do,
if
you
really
do
want
to
present
and
of
course,
as
soon
as
I,
do
the
conversion
of
the
slides
over
to
the
new
template
I
will
make
you
make
that
available
to
you
guys
to
look
at
the
review
and
if
you
feel
like
there
are
any
changes
you'd
like
to
make
about
anything,
please
speak
up
or
go
to
make
comments
and
the
presentation
itself.
C
Okay,
are
there
any
questions
or
comments
about
that
all
right
cool?
Thank
you!
So
the
interrupt
demo.
We
are
planning
on
doing
showing
this
in
Shanghai.
We
showed
it
very
briefly
during
the
intro,
whether
it
stays
with
the
intro
or
we
do
it
in
the
deep
dive
or
a
little
bit
of
both
and
don't
know
yet
so
I
need
to
talk
to
Clemens
Kathy
about
that,
but
the
demo
is
still
is
there.
We
I
think
we
have
five
or
six
different
end
points
right
now,
if
you'd,
like
your
endpoint
I'm.
C
There's
you
have
obviously,
until
the
day
of
to
get
your
endpoint
up
there.
It's
not
a
very
large
endpoint
relatively
easy
to
do,
but
there
are
you
know
the
sooner
you
get
up
there,
the
better.
So
we
do
some
debugging
if
things
do
go
wrong,
but
you
do
have
time
to
get
it
up
there.
The
only
thing
worth
mentioning
from
my
point
of
view
is
as
of
right
now
the
end
point
uses
version
0.1.
Next
I
should
fix.
C
That's
not
Novi
in
there
we're
using
0.1
as
the
version
string
for
the
spec
version
field
and
obviously
that's
not
right.
We're
not
doing
0.1
everybody's
doing
the
latest
version
of
the
spec,
which
is
some
undefined
thing.
Well,
we
do.
What
I'd
like
to
propose
is
that
we
switch
to
0.2
anticipation
of
us
doing
0.2
in
the
relatively
near
future,
hopefully
the
for
coob
con.
But
even
if
we
slip
it's,
it's
I
think
0.2
is
more
accurate
than
0.1
0.1.
It's
basically
flat-out
lie.
C
So
what
I'm?
That's
why
I'm
proposing
to
the
demo
guys
that
are
working
on
it
and
I'm,
not
hearing
any
pushback?
Yet
I
wanted
to
mention
it
to
you
guys
so
that
you're,
aware
of
it
and
give
you
guys
a
chance
to
raise
any
concern
about
the
fact
that
0.2
will
appear
in
the
message
flows
that
we
demo
that
coupe
con
itself.
C
Yeah
for
those
who
are
not
in
the
demo,
slash
at
all
I
was
gonna,
make
the
change
to
the
controller
tonight.
So
hopefully
at
some
point
during
the
evening.
If
you
change
your
function
over
to
support
the
0.2,
then
everything
should
work
by
tomorrow
morning,
but
I
was
going
to
change
today
on
my
side.
B
C
B
They
were,
there
were
some
confirms
race
in
issue
185,
but
there
was
some
lack
clarity.
You
know
how
some
of
the
data
types
work
and
how
would
you
deal
with
I'm
trying
to
get
some
clarity
and
there
so
first
of
all
make
it
clear
that
either
your
eye
reference
at
the
Times
them
are
not
just
strings,
but
they
are
following
a
particular
scheme
and
then
I've
also
added
some
explanatory
text
that
says
that
you
can
effectively
infer
either
from
the
mapping
table,
if
you
know
so,
for
instance,
for
a
date
for
sorry
for
time.
B
You
know
that
it's
a
date
and
even
though
it
shows
up
as
on
the
wire
as
a
string,
you
know
that
you
have
to
do
a
conversion
into
a
native
type
right.
Whatever
your
SDK
is.
The
same
is
true
for
the
yeren
reference
and
president
in
the
C.
Sharp
SDK
actually
surfaced
that
as
a
UI
type
and
a
time
type
of
cetera.
So
that's
basically
explaining
that
you
should
use
inference
and
then
at
the
bottom,
I
further
clarify
this.
B
If
you
find
in
the
data
in
the
data
attribute,
you
find
a
string,
but
the
string
is
a
is
basically
four
encoded
and
you
are
not
expecting
something.
That's
that's
a
text
or
it's
it's
a
it's
a
content
type.
If
you
don't
understand,
then
your
effective
decoding
that
as
it's
a
binary
from
basic
before
it's
basic
and.
C
C
C
All
right
any
objection
to
approving
that
one
excellent!
Thank
you
now.
Next
one
is
from
Jim,
unfortunately,
I,
don't
believe
Gemma's
on
the
call
I
mentioned
to
me.
He
wasn't
gonna
be
able
to
make
it
today,
but
I
believe
this
is
just
fixing
the
protobuf
to
align
with
the
property
change
that
went
in
last
week.
It
was
before
Kim
Irwin,
I
guess
two
weeks
ago.
Hopefully
this
is
more
of
a
type
of
type
change.
I,
don't
want
to
give
people
a
chance
to
look
at
it.
C
C
So,
for
example,
in
this
bizarre
case,
I
decided
it
might
be
useful
to
add
some
explanation
about
why
we
chose
to
do
the
extensions
way
we
did
into
the
primer
itself,
and
so
basically,
this
PR
just
add
some
additional
text,
mainly
to
the
primer,
just
explaining
some
of
the
reasons
why
we
did
what
we
did
I
all
I
tried
to
do
was
just
to
summarize
the
discussions
we
had
in
the
past
and
explain
it.
I
then
also
added
a
pointer
to
it.
C
Actually
I
had
a
little
bit
of
clarity.
Saying
extensions
need
three
places
top-level
things,
but
they
can
be
the
extension
themselves
can
be
misted,
meaning
they
could
be
structures,
not
just
single
property
kind
of
things,
just
for
clarity's
sake
and
then
I
had
appointed
to
the
new
primer
text.
This
in
no
way
changes
any
semantics
whatsoever.
It's
just
my
first
pass
at
trying
to
allow
people
who
are
new
to
the
group
to
understand
why
we
did
what
we
did
and
that's
that's
basically
yeah.
C
Obviously,
if
there
are
additional
changes
later
on,
people
want
to
make
this
text,
so
we
can
make
those,
but
just
want
to
get
an
initial
pass
out
there
for
people
to
understand
the
initial
thinking.
I
think
that's
been
out
there
for
a
little
bit
of
time.
Are
there
any
questions
or
comments
on
that.
C
Okay,
any
objection
to
approving
cool.
Thank
you
guys.
Oh
this
one,
this
one's
for
me
as
well
I'll
try
to
run
what
I
was
oh
yeah.
This
one
actually
was
been
open
for
a
while.
Originally
I.
Think
Austin
made
a
comment
about
how
it'd
be
nice
if
people
use
versions
in
some
of
our
properties
in
particular,
which
one
was
this
in
like
for
example,
to
type
people,
may
want
to
put
a
version
string
in
there
the
same
way.
We
expect
them
to
do
it
on
the
schema
URL
and
it
was
a
relatively
minor
change.
C
But
then
I
think
Clemons
made
a
comment
about
how
people
need
to
be
careful
when
they
start
changing
that
version
string
in
there,
because
it's
going
to
be
viewed
as
a
as
a
breaking
change
by
consumers.
So
I
added
some
text
to
the
primer.
To
give
some
background
on
that
thought
and
Clemons
I
think
you
said
you
review
this
text
and
you're
okay
with
it
yeah.
N
C
C
Don't
think
this
makes
any
normative
change
whatsoever.
It's
just
explanation
text
all
right.
Any
objection,
then,
to
adopting
this
one,
all
right,
cool
Thanks,
all
right.
So
next
one
now
this
one
I
opened
up
today
and
I-
know
I
said
in
the
comments
typically
for
non
typos
changes.
We
want
them
to
be
out
there
for
a
little
while
I
do
actually
kind
of
consider
this
to
be
a
bit
of
a
typo.
C
It's
not
quite
a
typo,
but
it's
awfully
awfully
close
I
noticed
this
morning,
while
talking
to
Clemens
that
we
never
actually
say
in
the
spec
what
the
exact
string
is
to
use
for
the
spec
version
property.
In
other
words,
is
it
zero
point
one?
Is
it
v
zero
point
one?
Is
it
something
different?
We
never
actually
say,
and
it's
actually
obviously
very
important
C
get
in
our
ability
and
the
the
demos
and
SDKs
have
all
been
assuming
zero
point.
One
of
these
for
the
current
version
of
the
spec.
C
C
C
Right
cool
now,
I
sent
out
a
note,
I
think
a
day
or
two
ago
saying
that
we
have
three
different
issues
that
are
right
now,
officially
tagged
to
zero
point
two,
but
they're
kind
of
in
a
holding
pattern,
because
the
original
authors
have
not
gone
back
to
us
on
the
feedback
that
we've
given
them
so,
rather
than
just
closing
it
for
lack
of
activity.
I'd
rather
give
them
a
little
more
time
to
think
about
it
or
to
respond
back
to
us.
C
However,
I
don't
want
to
I,
don't
want
that
to
definitely
block
us
from
going
to
0.2.
So
I'd
like
to
do
is
propose
that
we
move
these
out
of
the
0.2
milestone.
I,
don't
believe
any
of
these
are
breaking,
and
obviously,
since
we're
not
talking
about
a
1.0,
we
could
always
make
changes
as
we
go
along
anyway,
but
I
didn't
want
to
make
the
decision
unilaterally.
I
want
you
to
give
you
guys
a
chance
to
say
no,
you
think
some
either
of
these
three
need
to
stay
in
0.2.
C
B
B
However,
the
way
I've
solved
that
in
in
so
the
c-sharp
SDK,
now
kind
of
works
with
with
either
and
if
it's
expect
version
is
based
in
sense,
since
it's
going
to
even
if
it
could
take
your
basic
overrides
it
since
we're
since
were
moving
off
a
very
experimental
version
and
we
want
the
land
at
spec
version.
I
have
not
really
had
any
problems
with
doing
the
implementation
in
the
way
that
it's
tolerant
of
their
1:1,
but
then
otherwise
is
basically
life
with
0.2.
So
it
doesn't.
C
This
is
a
breaking
change
for
people
that
adopted
0.1
and
obviously
it
is
because
it's
a
proper
name
change,
but
I
believe
also
he's
claiming
that
spec
version
itself
is
not
descriptive
enough
and
he'd
like
it
to
switch
back
to
cloud
events
version,
because
it's
more
descriptive
and
I
wanted
to
basically
open
the
floor.
That
people
say
whether
they
think
we
should
change
it
back.
Changing
something
else.
Cuz
I
know
version
itself
as
a
word,
as
also
proposed
I'd
like
to
hear.
J
I
C
And-
and
so
let
me
jump
in
here
from
a
procedural
perspective,
I
know
we're
never
formally
I,
don't
like
the
government
stock
probably
says
this,
so
maybe
it
should
at
some
point
is
the
idea
of
reopening
issues
is
obviously
something
it's
always
a
possibility
and
in
other
groups
that
I've
been
in.
Usually
we
only
allow
people
to
reopen
issues
when
there's
sort
of
new
information
to
be
presented
that
maybe
wasn't
considered
before,
but
simply
reopening
it,
because
someone
felt
like
we
made
the
wrong
choice
without
new
information.
Usually
it's
frowned
upon.
C
I
O
N
O
Better
with
the
club,
this
is
Kevin
yeah,
oh
you're,
hi,
Kevin,
I'm,
cool
yeah,
sorry
I
mean
office,
so
yeah
so
I
would
prefer
either
way.
Take
one
step
further
to
use
a
version.
All
we
take
one
step
back
with
a
more
descriptive
of
cloud
events,
mercy
yeah,
so
take
one
step
back.
Definitely,
I
have
benefit
on
my
side.
I
I
don't
have
to
change
my
code,
but
if
we
wanna
make
it
okay,
simpler
nasty
verbose,
then
we
should
take
version
instead
of
spec
version.
F
Previously
I
don't
remember
exactly,
but
I
thought
we
left
it
open
to
possibly
changing
versions
and
someone
was
going
to
make
a
Laurie
process
that
separately,
but
I
thought
we
decided
definitely
not
to
do
cloud.
Events.
I
think
this
brings
up
some
possible
new
information,
but
we
did
discuss
that
this
will
be
a
breaking
change
and
we
need
be
a
breaking
change
and
we
accepted
that
because
we
were
only
0.1.
I
was
I,
don't
know
that
introduces
much
new
information,
but
I
do
I
thought
we
left
it
open
to
making
it
version
instead
of
surgeon.
F
C
F
N
K
Is
not
Iver
hi?
This
is
like
a
mirror.
I
prefer
to
leave
it,
as
is,
if
you'll
consider
from
the
point
of
view
of
the
user,
so
they
are
looking
into
some
event.
They
see
a
property.
This
is
a
spec
version,
so
they
know
that
this
relates
to
the
version
of
the
specification.
I
understand
that
there
might
be
some
reward
done
on
the
side
of
who
implemented
0.1
in
code,
but
I
feel
we
are
so
early
in
our
understanding
and
learning
about
the
event
that
changed
in
this
level
at
0.1.
K
We
should
not
go
with
the
legacy
code
as
being
the
foundation
for
the
specification
at
such
an
early
stage
and
I
think
over
time.
Changes
like
this
will
become
smaller
and
smaller
and
will
have
the
Malaysian
list
so
I
prefer
to
leave
it,
as
is
that
I
feel
it
is
descriptive
enough.
The
vendor
returns
to
the
version
of
specification,
so
I
feel
there
is
no
confusion
there.
Okay,.
L
Version
I
think
I
mean
cloud.
Events
is
already
evident
as
it's
either
part
of
a
Maps
or
prefixed
depending
on
the
car
on
the
transport.
But
spec
is
somehow
bit
more
descriptive
because
there
could
be
other
things
that
would
be
version
like
the
event
type
or
whatever,
and
this
could
create
misunderstandings.
Pen,
spec
version
is
short
and
descriptive
enough.
C
Okay,
so,
based
upon
what
I'm
hearing
so
far,
it
seems
to
me
that
the
argument
for
going
to
or
going
back
the
cloud
events
version,
because
it's
a
breaking
change,
is
something
that
I
think
not
everybody.
But
Moe
people
seem
to
not
necessarily
accept
as
a
valid
argument.
Basically
saying:
hey
we're
not
at
1.0.
Yet
the
backwards-compatibility
thing
is
just
a
fact
of
life.
C
It's
a
it's
a
0.1
so
that
that's
not
part
of
the
argument
is
what
I
think
I'm
kind
of
hearing
so
I
think
he
the
question
before
us
really
comes
down
to
do
we
want
the
current
spec
version
or
do
we
want
it
to
be
just
version
and
I?
Think
that's
really
the
question
in
front
of
us.
So
I
guess.
My
question
for
the
group
is:
if
you,
if
you
accept
that
as
the
the
real
question
is,
do
we
want
to
basically
open
this
door
up
to
have
another
vote?
C
I
think
that's
what
it's
probably
gonna
come
down
to,
because
I'm
not
hearing
anybody,
give
a
a
an
argument
that
seems
to
be
swaying
one
side
or
the
other
and
I
do
kind
of
get
the
sense
that
maybe
we
are
kind
of
50/50
about
whether
it
should
be
version.
Your
that
simpler
or
suspect
version,
cuz
yeah,
it's
simple,
but
it
still
a
little
descriptive.
Both
seem
to
be
about
50/50
from
what
I'm
hearing
so
far
and
I'm
not
quite
sure
how
to
resolve
that
other
than
to
take
some
sort
of
vote
at
some
point.
C
But
to
me
we
first
need
to
ask
the
question
of
do.
We
want
to
reopen
this
at
all,
because
we
did
make
a
decision
and
I
don't
want
to
gain
that,
have
it
or
reopening
previous
decisions,
but
this
is
kind
of
a
big
one.
So
I'd
like
to
hear
whether
people
think
nope
it's
sort
of
an
out
of
order
thing
and
we
should
accept
the
decision
until
there's
new
information.
D
J
C
J
C
C
Okay,
I
guess
does
that
imply
that
our
decision
is
we're
going
to
leave
it,
as
is
I,
don't
want
to
force
this
on
people
I
know,
for
example,
Kevin.
You
feel
strongly
enough
to
open
up
the
issue
in
the
PR
and
that
who
was
that
was
it
Dan,
John,
Michell
I
think
you've
made
mentioned
that
we
actually
did
leave
the
door
open
for
this
change
in
the
future
and
I.
Don't
want
us
to
feel
like
we're.
We're
reneging
on
that
on
that
promise.
C
But
at
some
point
we
have
to
be
able
to,
as
a
group
say.
Yes
we're
going
to
reopen
this
or
not.
Does
anybody
feel
like
we're
being
hasty
about
this,
or
they
want
to
raise
another
point?
I
just
I'm
not
quite
sure
how
to
go
here,
other
than
not
sure
where
to
go
next
with
this
other
than
to
say
there
any
objection
to
not
making
this
change
and
I
don't
want
to
force
that
on
people.
C
B
B
C
O
Not
that
is
a
group
decision.
That's
fine.
I
just
wanted
to
warn
the
group
that
in
the
future,
we
should
reduce
such
a
freakin
change.
We
at
least
should
have
at
least
the
one
cent
stick
with
us,
so
we
can
smooth
them.
You
know
maintain
the
forward
and
the
backward
compatibility
and
the
good
thing
about
subversion.
The,
or
is
that?
Ok,
you
guys
and
all
the
extensions
are
say
envelope,
so
that
means
I
can
still
keep
using
the
cloud
events
version
as
a
extension
in
my
spec.
B
B
N
And
the
problem
is
not
like
4s
to
change,
something
is
like.
If
we
change
it,
then
all
of
our
clients,
like
we
have
multiple
internal
teams
which
are
going
to
use
it.
So
if
we
change
something
all
of
them
also
have
to
change.
Other
I
agree
that
I
it's
early
phase.
This
would
be
like
ready
to
accept
changes.
But
if
we
can
kind
of
like
minimize
the
breaking
change,
it
will
be
like
good
for
everybody.
N
B
I
think
I
think
what
we're
doing
now
with
the
SDK
work
and
then
we're
actually
writing
code.
That's
part
of
the
project
that
will
cause
inertia
in
in
elementary
things
like
like
attribute
names,
etc.
So
I
think
that's
fairly
automatic,
because
otherwise,
literally
whoever
makes
that
change
needs
to
go
through
all
the
code,
make
sure
that
it
all
works.
C
C
C
C
This
issue
wanted
some
clarification
around
the
Jason
section
or
the
I'm.
Sorry,
the
there,
the
json
data
or
the
the
jason
civilizations
data
attribute
and
Clemons,
and
the
author
went
back
and
forth
a
little.
But
since
then
the
actual
doc
has
been
changed
and
there's
some
new
text
in
there
and
according
to
Clemons
I
heard
this.
C
It
sounds
like
this
next
when
new
text
removes
the
problem,
because
the
objection
or
the
concern
was
around
the
use
of
the
word
object
in
the
old
text
and
that's
no
longer
there,
as
you
can
see
by
the
text
here
so
I
think
we
can
actually
close
this
issue
now.
However,
before
we
actually
close,
it
I'd
like
to
wait
for
Reed
to
confirm
that
it
actually
is
okay,
but
either
way.
I,
don't
think
this
is
necessary
because
it
is
just
a
very
minor
change
to
the
spec.
C
Any
questions
or
comments
on
that
I
guess
the
big
it
more
clear,
I'm
proposing
that
we
close
this
with
no
action.
Once
you
get
confirmation
from
the
original
author,
okay,
not
hear
any
objection.
The
last
issue
I
think
we
had
was.
This
person
was
suggesting
that
we
have
a
another
transport
for
web
push
protocol.
C
Since
that
time,
I've
asked
the
person
if
they'd
be
interested.
In
writing.
A
prf
also
asked
if
someone
else
played
the
volunteer
to
write
it.
I
haven't
heard
anybody
jump
up
and
down
saying
yes
now,
I'm,
don't
I'm,
not
unless
the
proposing
that
we
closes
with
no
action,
because
it
could
be
that
people
haven't
had
time
to
look
at
it.
C
Yet,
however,
like
the
other
issues
that
have
been
sort
of
stale
for
a
while,
I
want
to
move
it
out
of
the
0.2
bucket,
and
that
way
it's
not
blocking
us
from
looking
at
a
0.2
milestone.
So
is
there
any
objection
to
moving
this
out
of
the
0.2
milestone,
with
the
assumption
that
we
could
weigh
that
it
add
in
the
transport
layer?
Obviously
it's
just
not
just
moving
from
being
a
blocker
I'm.
B
It
should
be
to
push
the
question.
There
is
whether
we
need
to
have
only
aspect
that
is
equivalent
to
a
web
host
thing,
and
there
I
only
think
it's
more
necessary
than
being
specific
about
how
to
do
the
base.
You
request
with
our
whether
I
should
be
mapping
so
I'm,
not
sure
that
spec
is
actually
necessary.
Okay,.
C
B
C
Okay,
so
is
there
anyone
on
the
call
who
thinks
that
this
should
be
a
blocker
for
zero
point
two,
and
we
could
save
the
discussion
about
whether
it's
a
valid
request
at
all.
First
for
another
time,
okay,
now
during
objection
that
I'd
like
to
move
out
of
zero
point
two,
and
we
can
have
the
discussion
later
and
so
clemens,
could
you
possibly
put
a
comment
in
here,
basically
restating
what
you
just
said
and
see
what
there
yeah?
Okay
cool?
Thank
you,
okay.
C
So
with
that
I
believe,
we've
actually
addressed
all
of
the
requirements
for
zero
point
two
in
terms
of
open
issues.
I
think
we
have
the
main
known
requests
for
for
mandated
properties.
I
know
there
are
still
some
Pretty's,
some
optional
properties
that
aren't
discussion,
but
I
think
0.2
milestone.
Just
basically
says
you
know,
try
to
nail
down
the
required
ones.
We
have
this
list
of
core
protocols,
I'm,
not
hearing
anybody
jump
up
and
down
saying
we
have
to
have
a
brand-new
ones.
C
I
mean
we
have
some
things
like
rocket
MQ
and
by
zero-point-two
we
don't
have
to
decide
to
have
it
in
or
out.
We
just
have
to
have
sort
of
an
initial
list
of
ones
who
want
to
consider
and
I
think
we
have
that
list
already.
So
at
this
time,
what
I'd
like
to
do
is
to
propose
that
we
get
every
one
week
a
review
time
and
I
guess:
I
could
call
a
voting
period
as
well
so
one
week
to
review
all
the
current
documentation.
C
So
that's
the
main
spec
itself,
all
the
transports
specs
and
the
primer
with
the
goal
of
within
this
one
week,
people
saying
yes
or
no
to
approving
it
as
a
0.2,
with
the
final
deadline
for
the
or
that
sorry,
the
final
tallying
of
the
vote
happening
on
next
week's
call.
So
one
week
review
slash
voting
period.
C
Cool
I
mean
you
should
be
able
to
get
to
assuming
everybody
proves
it
to
zero
point
to
no
time
for
coop
con,
which
would
be
very
exciting
cool.
Thank
you
very
much
and
I
will
send
a
note
to
the
no
and
list
to
have
two
for
those
people
who
cannot
make
the
call
to
do
the
review
and
hi
Jim
is
here
on
the
call.
Thank
you
all
right.
M
B
C
C
Okay,
I'll
close
it
after
the
call,
but
I'll
add
a
reference
to
the
PR.
So
we
like
to
understand
why
we
closed
it.
Okay,
so
just
to
remind
myself
cool.
Thank
you,
sir
all
right
rocket
and
Q,
so
this
person
would
like
to
add
a
rock
at
him.
Q
transports
it
doesn't.
There
apparently
goes
with
this.
Oh
I'm,
sorry
look
at
the
wrong.
One
is
doing.
C
B
Think
about
that
the
exact
same
way,
I,
think
about
it,
that
people
are,
and
that
is
rocket
and
Q
is
choosing
to
have
its
own
fire
protocol
for
one
project,
while
the
rest
of
the
world
tries
really
hard
to
either
in
the
messaging
world
at
least
tries
really
hard
to
either
go
in
a
line
of
MVP
or
in
PTT
or
Kafka.
So
that's
the
three
big
ones
and
rocketed
Q
wants
to
do
its
own
thing
and
my
my
argument
keeps
being
that
we're
trying.
We
should
try
not
to
bless
project
proprietary
protocols.
P
B
C
Yes,
oh
I'm,
just
double-checking,
you
made
some
comments,
I,
like
sure,
remembering
correctly,
okay
yeah,
he
said
he's
had
been
adopted
by
hundreds
of
companies.
I
don't
think
he
says
there
are
multiple
implementations
and
if
I
hear
you
correctly,
Clements
I
think
that's
your
biggest
concern
is
the
multiplication
aspect.
Is
that
right,
yeah.
B
B
But
that's
you
know,
that's
my
that's.
That
might
be
my
my
my
stance,
who
are
trying
to
you
know
bring
peace
and
harmony.
It's
a
messaging
space
that
might
magnitude
there
and
might
not
be
the
right
one
for
this
project,
but
I
just
don't
believe
we
should
go
in
and
help
proprietary
protocols
get
blessing
of
interoperability
projects
all.
G
C
B
Close
so
that
said,
I
want
to
have
it.
I
really
want
to
have
a
debate
with
the
open
messaging
project
on
how
we
could
probably
go
in
the
line
things
there,
and
so
it's
not
that
I'm
that
I'm
just
categorically
saying
hey.
We
should
shut
the
door
that
entire
effort,
because
the
open
messaging
proposal
also
came
from
I.
Think
from
that
same
people.
B
B
C
B
It
was
also
my
impression
it's
just
that
this
so
by
the
rules
that
we've
set
it
doesn't
meet.
The
bar
and
I
think
that
needs
to
have
its
a
broader
discussion
needs
to
be
had
in
terms
of
how
we
can
go
and
align.
Those
I
would
been
going
to
line
those
efforts.
I
would,
rather,
frankly,
I,
would
rather
have
for
rocket
and
cubes,
though
it's
not
a
protocol
that
everybody
speaks
and
also
messaging
to
be
something
that
came
up
as
a
higher
level.
B
Api
project
that
helps
the
Trop
ability
run
that
kind
of
builds
another
JMS
effect
right.
Gms
was
built
for
a
world
where
everybody
kept
their
product
protocol
proprietary,
and
you
should
not
going
to
promote
that
again.
What
we're
doing
here
is
real
wiring
up
and
that's
484,
and
we
should
stay
true
to
that.
C
C
C
C
Okay,
if
there's
somebody
on
the
call
who
would
like
to
join
the
conversation,
just
ping
me
off
flying
all
I'll
loop,
you
into
the
chest,
but
I'll,
take
you
actually
to
sort
of
reach
out
to
those
guys
and
see
if
there'll
be
a
coupe
cause.
You
have
a
conversation
there,
okay,
so
relative
to
the
PR
itself.
It
sounds
like
the
action
is
to
write
back
to
them,
saying
that
the
group
does
not
believe
it
meets.
The
minimum
bar
of
one
of
those
two
requirements
listed
in
the
primer.
I
mean
these
two
points,
I,
don't
mind.
C
Taking
that
actually
I'd
have
to
put
that
in
there
I'll
leave
that
open,
I'm.
Sorry
I'll
leave
the
PR
open
just
so
they
can
reply
back
if
they
think
they
were
wrong
and
they
can
explain
why
he
actually
does
meet
one
of
those
two
bars
but
other
than
that
unless
they
come
back
and
convince
us
otherwise,
we'll
eventually
close
it,
but
I
wanted
to
give
them
a
chance
to
reply
back,
but
I'll
take
the
action
to
let
them
know
what
our
just
current
decision
is.
Is
that
okay,
everybody.
C
C
C
See
y'all,
you
know,
find
somebody
or
trying
to
find
some
time
myself
to
work
on
it.
Okay,
I
think
the
other
ones,
I
think
this
one's
still
bring
up
our
being
discussed.
I
think
the
this
one
is
being
discussed
as
well,
because
it's
related
to
that
one.
We
had
these
two
pairs
from
Sarah
I.
Believe
there's
open
comments
on
there
or
questions
and
I
know.
Sarah
has
been
busy
with
other
things
like
the
safe
stuff,
but
she
hasn't
tied
back
to
us
on
those
and
I.
My
general
sense
is
I.
C
Don't
yes,
I
think
these
are
necessary
needed
and
I
commented
on
those
both
of
those
PRS
that
we
don't
hear
back.
I
was
gonna
propose
that
they
be
closed
with
no
action
and
I
haven't
heard
back
from
you
from
her
any
of
the
one
of
those.
So
my
proposal
for
the
group
here
is
to
close
these
two
PRS
here
with
no
action.
I.