►
From YouTube: CNCF Serverless Working Group - 2018-01-25
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
A
B
A
C
A
F
A
A
A
G
A
Right
cool,
thank
you
all
right,
give
you
30
seconds
or
so.
Oh
we
miss
you.
Oh
hey,
hey
so
used
to
seeing
there
you
just
sort
of
I
just.
A
A
A
Just
acting
up.
Okay.
Are
there
any
changes
to
the
agenda?
People
would
like
to
make
I
tried
to
cover
up
out
some
of
the
hot
topics.
B
H
I
did
a
PR
for
changes
to
the
governance
model
and
a
little
offline.
I
think
there's
been
a
lot
of
discussion
on
it.
I've
updated
it
and
I
had
an
offline
discussion
with
Doug
that
I'm
gonna
try
to
separate
it
into
individual
specific
PRS.
But
I
would
like
people
to
sort
of
comment
on
the
ideas
in
it,
because
it's
definitely
like
a
work
in
progress.
It
was
like
exploring
a
bunch
of
ideas
for
a
governance
model
that
would
encourage
offline
participation,
so
I
think
it.
A
A
Last
I
heard
they
may
have
some
minor
edits
they
want
to
make
to
it.
I
haven't
actually
seen
the
proposals
yet,
but
obviously
people
should
get
a
chance
to
review
those
before
they
finalize
everything,
but
it
is
still
hidden
the
work
so
nothing
to
do
there
for
our
group
yet,
but
I
just
wanted
to.
Let
you
guys
be
aware.
What's
going
on
there,
let's
see
piers
well,
okay,
there
I
think
there
are
three
PRS
that
are
technically
ready
to
go.
A
Let's
look
at
the
first
one
here
my
machine
behaves
properly,
so
this
one
there
are
more
edits
that
need
to
be
made.
However,
the
reason
I
decided
to
add
it
to
the
list
for
discussion
right
now
is
because
all
the
edits
that
I
think
need
to
be
made
are
strictly
typographical,
in
the
sense
that
the
pr
still
references
open
events
instead
of
cloud
events
like
you
can
still
see
her
on
line
one
so
like
that,
but
I
think
those
are
really
the
only
edits
that
people
have
suggested
to
be
made
in
there.
A
H
H
K
A
H
Yeah
I,
like
the
use
cases
on
a
second
doc,
I,
think
the
same
thing
like
you
know
like
when
we
have
separate
things
and
separate
Docs
and
it's
easier
to
manage
all
the
PRS
yeah.
J
Yeah
those
that
maybe
those
their
cloud
events
specific
there's
a
whole
is
another
set
of
Doc's
about
the
working
with
itself.
It
may
also
want
to
include
just
and
I
think
Doug
may
have
said
its
before-
maybe
the
briefest
of
blurbs-
about
what
it's
not
right,
to
the
extent
that
that
helps,
clarify
and.
H
I
think
you
know
like
ideally-
and
we
may
not
be
like
quite
there
yet,
but
maybe
somebody
feels
like
they
could
draft
them
like.
What
are
we
looking
for?
What
kind
of
engagement
are
we
looking
for
right
now,
because
I
think
we
got
like
I'm
hoping
we'll
get
to
a
place
relatively
soon,
where
we're
looking
for
people
to
implement
the
spec,
but
we're
not
quite
there
yet,
and
that
should
be
clear.
A
F
A
A
Okay,
so
Austin
on
the
next
PR,
which
I
believe
is
number
eight
I
know
there
was
at
least
one
comment:
that's
relatively
new
by
Marc
and
their
couple
has
any
comments,
mainly
typographical
type.
Things.
Are
there
other
things
in
here
that
we
need
to
discuss
or
they're
just
a
matter
of
addressing
the
comments
so.
G
That
one
one
comment:
it's
your
on
I'll,
try
and
add
it
to
the
readme
just
before
we
we
move
to
the
next
one
on
the
overview
again,
I
made
this
comment
before
just
a
logistic
of
editing.
I
think
we
also
want
to
address
the
API,
not
just
the
messaging
I.
Don't
think
it's
clear
in
this
description
that
eventually,
as
a
service
working,
we
want
to
make
sure
that
the
service
consumption
model
of
the
event
is
sort
of
standardized
uniform,
whatever
we
want
to
call
it
so.
A
G
Why
do
we
need
separate?
You
know,
because
the
format
eventually
need
to
be
consumed
if
you're,
creating
informant
and
everyone
consumes
it
in
a
different
way.
That
sort
of
misses
the
point
I,
don't
think
we
really
need
more
event
structures.
You
know
more
pubsub
engines
are
enough
of
them
like
what
we
really
want
is
a
definition
of
how
the
message
looks
within
a
flop,
submit
son
or
whatever
and
how
you
consume.
It.
F
I
mean
I
mean
that
the
spirit
of
github
is,
you
know,
to
keep
PR
small
I
mean
we
should
have
PR
comments,
be
reflecting
that
if
we
closing
the
current
content
issues,
if
their
future
of
things
or
things
that
are
additive
or
new,
we
should
get
this
PR
approved
through
and
improved,
and
then
future
topics
future
suggestions
augmentations
to
be
addresses
issues.
That's
the
spirit
of
pull
requests,
get
them.
You
can't
you
shouldn't,
keep
them
open
at
Ignasi
'm
and
have
scope
creep.
That's
that's
my
concern.
H
I
added
a
note
about
like
I,
mean
I
agree
with
this,
like
in
terms
of
the
roadmap
like
I,
think
that
my
understanding
is
that
is
the
same
as
whoever
was
just
speaking,
that,
like
the
format,
is
not
sufficient
and
I,
don't
know,
I
I
think
it
would
be
nice
to
keep
the
format
as
its
own
spec
and
have
a
different
spec
or
guidance
or
whatever
we
decide
about
how
one
transport
set
format
in
such
a
way
that
there
can
be
interrupts
between
two
systems.
You.
G
Know
that's
a,
but
is
heresy
Iran
from
the
Gaza
I
think.
The
point
is
that,
let's
assume
we
want
to
implement
some
of
that?
Okay,
just
like
you
know,
we've
seen
open
messaging,
another,
so
you're
going
to
implement
the
spec
and
what
would
be
the
implementation?
You
know
Jackie
Jason
structure,
a
you
know,
go.
You
know,
message
format,
it's
probably
when
you're
saying
we're
going
to
implement
it,
you're
going
to
implement
a
library
that
consumes
a
message
and
generates
a
message
in
that
essentially
gets
you
to
an
API
I.
D
A
A
H
I
mean
I,
don't
think
it's
word,
smithing
its
actual
scope,
like
it's
actually
that
people
disagree
with
the
roadmap
or
feel
that
there
needs
to
be
more
scope
in
the
roadmap
and
then
committing
to
a
road
map
that
doesn't
seem
to
accomplish.
Our
goals
is
like
not.
Everybody
isn't
aligned
with,
however,
having
a
starting
document
that
we
edit,
you
know,
is
also
a
good
process
right.
So
I
think
that
that's
where
we're
at
and
and
I
like
the
idea.
There
are
open
issues
right
that
indicate
that
there
are
open
issues
right,
yeah,.
D
A
D
A
Basically,
the
in
a
speck
it
suffer
looks
like
you
merge
the
spaces
there.
It's
fine.
You
basically
ripped
out
the
use
case
section
and
put
it
into
a
separate
dock,
and
then,
let's
see
where's
marks
come
at
the
oh
wait,
did
I
turn
off
the
little
checkbox
hold
on
there.
It
is
yes
open,
eventing
changed,
but
so
there's
this
comment.
D
A
It
doesn't
know
a
couple
comments
down
here.
It's
not
like
there
may
be
some
edits
you
want
to
make,
so
this
one
may
not
be
quite
ready
to
merge
right
now.
Is
that
fair,
correct?
Yes,
so
let's
take
this
one
off
line,
then
I've
been
and
hopefully
iplex
weeks
call
we
could
try
to
yell
this
one
down.
Yep.
D
D
I
A
Yep
yeah
right
any
other
comments
on
peer
and
rate
all
right,
moving
forward,
I'm
a
screen
removed.
Okay,
there's
this
one
that
I
opened
up
number
15,
which
tries
to
make
a
first
pass
at
adding
some
normative
language
around
the
properties
themselves.
You
know
which
ones
are
optional,
which
ones
are
required,
I,
don't
think
I
change.
The
semantics
of
anything
I
did
try
to
remove
some
extra
text.
A
H
K
K
A
That's
why
I'm
gonna
sing
it
okay.
Well,
anyway,
it
doesn't
sound
like
we're
ready
to
actually
merge
this
today.
I'll
take
a
look
at
some
at
your
comment
but
I'll
with
only
Chad,
giving
it
one
LG
10
just
26
minutes
ago.
I
feel
a
little
uncomfortable
merging
this
right
now.
So
just
as
a
reminder,
please
everybody
go.
Look
at
this
I
like
I
said:
I
tried
my
best
not
to
change
any
semantics,
but
if
I
got
it
wrong,
obviously
jump.
You
know
pointed
out
to
me:
I'll
try
to
fix.
H
A
A
A
So
one
thing
I
want
to
talk
about
next
were
areas
the
spec
that
we
thought
I'd
needed
work,
or
that
we
need
to
take
action
on
and
the
list
that
I
put
here
or
just
things
that
popped
in
my
head,
just
to
sort
of
get
the
conversation
going
in
particular,
the
things
that
stood
out
to
me
are
inside
the
spec
right
now
we
have
several
places
where
there
are
things
that
are
listed
as
to
dues
or
notes
and
they're.
Basically
things
that
need
discussions,
so
I
thought
okay.
A
What
we
should
do
is
remove
those
from
the
spec
itself
and
turn
each
one
of
those
into
an
issue.
It
seems
like
a
fairly
easy
thing
to
do.
The
other
thing
is:
there's
a
section
called
content
after
you
pass
your
backlog,
I'm
assuming
that's
just
a
list
of
potential
attributes
that
haven't
been
agreed
upon
by
the
people
that
original
work
on
the
spec.
A
So
we
should
do
is
open
up
an
issue
for
each
one
of
those
just
to
decide
whether
we
want
to
include
them
as
a
as
an
approved
property
or
not
so
just
open
up
issues
for
those.
Then
we
can
remove
those
or
I'm
sorry
I'll
leave
them
in
the
spec
in
that
section
for
right
now,
but
then
open
up
issues
for
each
one.
A
That
says
either
remove
it
or
make
it
a
full
fledge
properly
we
agreed
to
and
then
once
all
those
issues
are
resolved,
that
entire
section
will
go
away
because
there
won't
be
a
backlog
anymore.
So
those
are
the
two
sort
of
action
item
e-type
things
that
I
wanted
to
mention.
First
any
comments
about
those
disagreements.
They
seem
reasonable.
The
starting
point
we.
D
Put
the
backlog
in
the
Google
Doc
because
we
were
working
out
of
Google
Docs
now
that
we've
moved
to
github
I
think
it
makes
sense
to
maybe
remove
that
backlog
section
from
the
specification
itself
and
possibly
put
that
all
in
issues:
okay,
shorten
the
document,
make
it
an
easier
read
and
then
just
put
those
in
the
format.
That
is
where
an
easy
debate
can
take
place.
I'm.
Okay,
with
that
too,.
A
A
Excellent,
alright:
what
about
converting
all
the
notes
and
to
do's
and
to
issues
anybody
want
to
jump
up
and
take
that
one.
A
Ok,
cool!
Thank
you.
Ok,
the
other
thing
that
I
thought
might
be
worthy
of
doing
in
terms
of
work.
That
Stan
aspect
is
to
pull
the
current
set
of
or
poke
on
the
current
set
of
providers
out
there
to
make
sure
that
the
the
current
set
of
suggested
properties
aligned
with
their
view
of
a
good
starting
point
in
terms
of
a
core
set
of
properties.
So
this
is
basically
nothing
more
than
just
make
sure
the
big
guys
out
there
are
looking
at
this
stuff
and
paying
attention
to
it
and
and
they're.
H
Well,
I
think
going.
A
H
What
exactly
all
these
decisions
which
I
have
been
made,
and
so
I,
don't
I,
don't
I
I,
can't
think
I'm
sure
there
is
something
like
out
there
in
the
world
that
is
like
this
is
a
picture
of
how
all
these
things
work
together
or
what
is
the
context
for
these
particular
types
of
events
and
so
I
I.
Think
that's
that's
the
thing.
That's
missing
because,
like
I'd
like
to
see
people
who,
in
addition
to
the
major
cloud
providers,
you
know
Google
being
one
of
them.
C
H
But
maybe
there
are
other
players
like
that
are
not
yet
involved
that
have
an
analogous
thing
or
consume
them
like
I'd
like
to
see
other
like
like
tool
makers
or
like
some
outreach
to
you
know,
and
Rachel
and
I
were
brainstorming
people
who
are
writing
applications
based
on
events,
so
that
this
is
also
vetted
by
people
who
are
consuming
them
in
a
different
way.
Well,.
F
This
goes
back
to
the
use
cases.
I
mean
first,
you
know,
first
of
all
down
it's
about
the
it's
always
about
the
data,
it's
about
the
event
producers.
What
I'm
hearing
you
have
to
identify
as
event
producers
to
go
after
in
different
domains
or
spaces
like
the
IOT
or
whatever
who's
our
producing
events.
Today,
you
have
to
ask
them
why
they've
made
decisions
purdue
students
where
they
have
and
what
are
they
in
its
youth?
And
you
also
see
if
the
receptive
to
alignment
with
the
standard.
E
F
I
think
it
greatly
places
like
the
how
we,
how
we
do
routing
in
place,
it's
gonna,
come
down
to
event
types,
different
event,
types
will
carry
different
types
of
data
and
some
will
have
protocol
requirements.
So
I
think
those
are.
Those
are
the
things
that
we
need
to
get
at
a
higher
level
of
what
type
of
events
we're
dealing
for
which
domains
so.
A
H
Say
inside
the
spec,
but
like
what
I'd
like
to
do
is
like
I
know,
people
who
are
who
are
sort
of
part
of
this
ecosystem
in
some
way
right.
They
are
consuming
events,
they're,
writing
tools
around
events
they're
they
have
application
architectures
that
completely
depend
on
events
and
like,
and
so
I'd
like
to
be
able
to
point
them
to
this.
However,
for
most
for
many
people,
the
spec
stand
alone
is
not
sufficient
for
them
to
understand
what
we're
trying
you
know
like.
How
does
this
fit
into
the
whole
puzzle
and
part
of
it?
H
H
A
K
A
G
So
that
the
previous
document,
I
wrote
against
Iran
or
the
cnam,
and
there
was
another
one,
I
did
cover-
serve
the
ecosystem,
the
difference
or
pub/sub
mechanism
protocols
and
the
differentiate
just
like
Sarah
between
message
and
events.
Again
because
for
some
cloud
provider
events
there
may
not
be
a
message
or
the
message
will
be
provider
internal
things
that
you
don't
even
care
about.
The
message
structure,
yeah.
G
H
G
A
D
D
Down
and
drafted
look,
can
you
hear
me?
Okay
at
the
moment
heading
out
a
bit,
you
may
want
to
start
over
yeah
sure,
I
think
there's
still
a
naming
conversation
or
a
naming
pass.
We
should
do
on
some
of
the
properties
that
are
within
a
specification
when
we
drafted
those
those
properties.
We
agreed
to
not
focus
on
the
name,
just
focus
on
their
meaning,
so
I
think
if
someone
wants
to
take
a
shot
at
seeing
if
there's
opportunities
to
name
those
properties
in
a
better
way,
that
would
be
helpful.
I've
been
thinking
about
that.
D
H
And
also
I,
don't
know
if
people
have
I
haven't
given
a
lot
of
thought
to
rationale
for
naming
but
like
Austin,
if
you
or
the
other
people
have
been
involved
in
like
sort
of
standard
stuff
like
if
there's
any
rationale
for
why
we're
naming
things
a
certain
way
would
love
to
settle
on
that.
First,
like
oh,
we're
gonna
take
capitalization
from
this.
You
know
way
of
doing
things,
or
we
want
to
be
consistent
with
this
kind
of
a
thing
like
you
know,
like
sort
of
agreeing
on
some
kind
of
philosophy,
and
then
we
can
wordsmith.
F
A
Okay,
I
heard
Austin
volunteer
to
take
initial
pass
at
this
I
assume.
If
someone
else
is
also
interested
you'll
reach
out
to
Austin
to
work
on
that,
if
Austin
doesn't
do
it,
I
will
open
up
an
issue,
so
we
can
assign
this
in
terms
of
priorities
and
workload
and
stuff
and
science
I
write
my
own
stuff
like
that,
so
we
could
track
it
any
other
things.
People
inspect
people
think
we
need
to
it
to
deal
with.
A
Once,
okay,
that's
really
good
list
so
far,
all
right,
not
hearing
any
I've
had
a
whole
bunch
of
a
eyes
to
do
things.
That's
all
good.
Okay,
the
next
thing
I
thought
might
be
good
to
talk
about,
is
Howard
sort
of
a
more
of
a
process,
type
question
in
terms
of
how
we're
going
to
decide
what
we're
going
to
do
for
each
release,
because
I've
been
kind
of
assuming-
and
this
is
actually
up
for
debate-
is
that
we
have
at
least
three
different
releases
sort
of
an
alpha-beta
and
then
a
version
one.
A
A
No,
we're
just
going
to
keep
sort
of
working
in
and
every
now
and
then
we'll
say:
oh
we're,
gonna
cut
a
version
1.2
and
then
it
wind
up
2.5
or
something
you
know
and
just
sort
of
play
it
by
ear
or
do
we
want
to
say
no,
let's,
let's
have
some
concrete
releases
alpha-beta
of
type
thing,
and
that
way
can
we
get
a
sign?
Is
those
milestones
you
know
how
do
people,
how
people
like
to
move
forward
on
this
in
terms
of
laying
out
our
target
dates
for
things
I.
H
Oh
now,
we
think
it
is
complete
enough
that
we
would
like
people
to
make
implementations
of
it
and
then,
when
we
have
at
least
two
interoperable
implementations,
provided
we
don't
have
somebody
who's
like
wait,
I'm
almost
done
with
mine
that
then
we
would
declare
it.
We
would
welcome
additional
implementers
and
then
it
would
be
one.
Oh
when
something
you
know
some
milestone
of
interoperability
or
something
something.
A
F
F
Apart
from
the
first
release,
where
I
get
the
base
content
down,
this
group
should
basically
on
a
weekly
basis,
be
able
to
anybody,
can
nominate-
or
even
apart
from
the
group
via
via
off
on
communication,
saying
I
think
we've
added
enough
content
through
here
or
whatever
that
this
PR
wants
a
new
point
release,
and
then
then
we
do
that.
You
know
based
upon
a
a
page
fault
system
right.
F
I,
don't
I'm
saying
that
I
think
that
I
won't
I'm
here
affirming
the
fact
that
we
want
people
to
write
code
against
date,
so
so
I
think
that
the
the
code
files
him
in
this
spec
and
the
way
in
the
github
world
it
works
is
of
course
you
know.
People
will
follow
point
releases,
so
it's
important
for
us
to
realize
that
we
can't
hold
back
people's
codes
and
in
debates
we
have
a
because
they
didn't
get
pull
requests.
We
all
agree
upon
that
could
warrant
a
point
release
no.
A
I
understood-
and
let
me
just
finish
what
I
was
saying
there
than
that
I
was
assuming
that
once
we
get
to
a
version,
one
that
the
normal
semantic
versioning
look
exactly
as
you
were
describing
Sara
right,
you
know
maybe
change.
The
semantics
has
to
do
a
major
version
bump
or
something
like
that.
Non
non.
Breaking
changes
can
be
point
releases.
You
know
adding
things
without
breaking
things:
great
boy,
visas
that
kind
of
stuff,
but
I,
was
trying
to
figure
out
the
best
way
to
get
us
to
the
version.
A
One
thing
that
means
we
want
to
do
assume
that
periodically
we're
gonna
just
do
a
V,
zero
dot,
one
and
a
V
0.2,
and
just
keep
increasing
the
number
and
eventually
we'll
say
yep.
Now
we're
at
one
point:
no,
because
I'd
spit
its
a
math
point,
though
I
think
at
some
point
we
do
need
to
decide
when
we
reach
this
level,
whether
you
want
to
call
it
beta
or
you
want
to
call
it
nine.
A
That's
when
we're
that's
when
I
feel
like
we
need
to
be
able
to
tell
the
broader
community
we
feel
like
the
spec
is
stable
enough,
that,
while
we
were
hoping,
people
were
implanting
up
until
now.
Now
it's
really
stable
enough
that
you
should
feel
confident
that
we're
not
going
to
completely
revamp
everything
on
you
and
implementation
should
feel
free
to
implement
this
about
too
much
fear.
That
was
my
original
thinking
behind
this
process
and
that's
what
I
thought
beta
was
going
to
be,
and
alpha
is
more
like
hey.
A
We
think
this
thing
is
in
embarrass
is
not
embarrassing.
We
want
to
share
it
to
the
world
right
and
that's
sort
of
like
once
you
get
past
this
initial
stage
of
had
an
RFC
keywords,
make
sure
the
naming
looks
a
kind
of
right
kind
of
stuff,
and
you
know
get
us
past
the
initial
hump.
That
was
my
original
thing
behind
those
three.
That's
four
layers.
First,
steps.
F
Most
important
have
milestones,
but
I
still
say,
apart
from
the
very
first
release
when
it's
when
you
can
start
annotation
when
there's
enough
to
implement
people
just
follow
the
commit
hash.
So
people,
if
I
read
code
I,
would
just
say
I
would
reference
the
commit
hash
for
the
document
level.
That
I
followed
right.
A
H
H
I'm
trying
not
understand
the
I
think
I
understand
the
intent
of
saying,
like
I'm,
declaring
something
alpha
or
beta
I.
Just
think
that
that's
confusing
when,
like
you
know,
if
a
if
somebody
has
a
G
a
product
and
choose,
we
want
to
incent
them
like
a
general
availability
like
released,
you
know
mature
product
and
we
want
to
incent
them
to
implement
the
specification.
F
Well,
I'm
saying
because
I'm
saying
the
same
thing
well,
first
of
all,
we
don't
we
have
this
thing
called
market
freeze,
you
say
we're
gonna,
wait
till
this
date
to
freeze
people
won't
look
at
it.
So
as
soon
as
that
people
have
a
chance
to
beta.
It
has
enough
content.
We
want
people
on
commenting
because
they
kept
in
their
commit
patch
and
they
can.
They
can
choose
to
freeze
the
implementation
based
upon
that
level
and
upgrade
as
they
see
fit.
Yeah.
A
I'm,
a
little
nervous
was
saying
you
know
when
you
have
two
independent
implementations,
then
then
we
go
to
one
oh
I'm,
not
sure.
That's
the
criteria
I
would
have
put
out
there.
I
definitely
want
influent
ation,
so
they
were
wrong,
but
I
think
it's
more.
We
have
implementations,
we
don't
have
any
unresolved
issues.
There
are
tagged
for
version.
A
One
there's
I
think
there's
several
different
things
that
go
into
play
there
and
that's
I
think
why
I
was
hesitating
a
little
and
why
well,
my
suggestion
was
going
to
be
was
rather
than
tried
to
necessarily
narrow
it
down
on
this
call
to
suggest
that
we
grew
of
us
go
offline
and
come
back
with
basically
a
pull
request
to
document
the
proposed
process.
We
go
through
four
defining
releases.
J
H
H
J
I,
don't
know
how
productive
this
is
right
in
some
respects.
I,
don't
know
how
much
how
much
we
aren't
necessarily
having
discussions
somewhat
ahead
of
where
we
are
but
I
guess,
I
suppose
it
is.
It
is
healthier,
it's
maybe
it's
neither
here
nor
there,
whether
it's
alpha
beta
or
dot
or
we're
following
a
different
semantic
versioning
scheme,
yeah
generally
people
consider
it
I
think
alpha
beta
is
certainly
I'm
convey
a
certain
sentiment.
J
People
associate
1.0
with
I'm
a
similar
sentiment
about
production
readiness,
I
think
that
it
is
like
to
the
extent
that
anything's
a
specific
as
standard
I.
Think
more
and
more,
at
least
from
my
perspective,
our
industry
is
generally
trended
towards
that
being
reinforced
by
implementation.
So
I
think
it's
all
right.
You
know
I
feel
like
that's
a
good
direction
like
Haga
those
that
are
actually
using
it.
J
You
know:
that's
the
fact
that
it's
an
actual
standard
or
a
meaningful
standard
and
getting
getting
providers
to,
or
framework
providers
to
have
this
implemented
prior
to
a
100m
meeting
with
the
amount
of
momentum
behind
it.
We
won't
have
that
much
of
a
challenge,
but
I
could
see
that
being
a
challenge,
so
I
get
them
getting
them
to
invest
to
the
points.
They
would
do
it
prior
to
understanding
that
it's
it's
unstable
in
terms
of
its
spec
yeah.
A
And
so
people
understand
sort
of
my
reason
behind
bringing
this
up
now
was
a
couple
of
reasons.
One
is,
as
we
start
asking
people
to
open
up
issues.
I
feel
like
we're.
Gonna
need
to
have
some
sort
of
scheduling
of
issues
or
listening
a
priority
of
issues
right
when
which
ones
we
think
are
critical,
which
ones
are,
can
be
deferred
and
a
lot
of
way.
A
People
do
that
as
I
say:
okay,
they
assign
issues
to
particular
milestones,
and
so
I
thought
it'd
be
useful
to
have
sort
of
a
roadmap
of
what
the
milestones
are,
and
we
could
say
this
issues
should
be
assigned
for
0.9
versus
this.
One
needs
to
be
done
immediately
for
point
one
right,
and
so
we
can
sort
of
weigh
the
priorities
there.
I
thought
that
might
be
useful
to
help
order
things.
A
I
was
one
reason
behind
it,
but
the
other
one
is
I
think
it
suddenly
touches
on
what
you
were
saying
there,
which
is
when
looking
are
people
to
implement
this
stuff.
But
in
my
experience
there's
a
lot
of
companies
that
will
not
touch
a
specification
until
it
reaches
a
certain
level
of
maturity
and
we
need
to
decide
how
we're
going
to
indicate
that
that
that
bar
right,
whether
it's
called
beta
or
some
other
name
or
some
version
number,
we
need
to
decide
what
that
level
is.
A
F
I
thought
vanishing
point,
I
think
that
it-
and
this
goes
back
to
ice
thing
about,
depending
on
our
we're
dependent
on
a
commitment,
dependent
library,
those
libraries
change
onerous.
All
the
time.
I
think
the
scope
of
this
group
was
to
include
tooling
around
it,
even
even
as
as
soon
as
possible,
from
what
Austin
was
saying
at
some
previous
meeting.
So
maybe
the
signal
is
is
when
that
code
is
actually
when
our
group
feels
that
we
have
enough
content
in
the
spec
to
start
creating
tooling
around.
F
We
can
bite
people
to
use
that
tool
and
I
think
that's
the
TV
and
cable
when
you
start
working
towards
for
more
formalization
and
so,
but
until
we
reached
that
point,
you
know
the
question:
is
you
know
what
what
it
goes
back
to
scope?
What
should
be
the
scope
for
routing
one
that
we've
matched
milestone?
One
and
I
think
we
only
have
a
milestone
one
and
everything
is
just
future
milestone.
Yeah.
G
Another
thing:
if
we're
looking
at
open
messaging,
just
as
an
example,
he
opened
the
gate
up,
you'll
see
reference
API
for
go,
PHP
Python,
you
know
Java,
CPP,
etc.
Okay,
I
think
we
should
have
the
same.
We
should
a
part
of
the
repo
API
examples
and
some
frameworks
we're
willing
on
our
platform
to
just
have
a
branch
of,
for
example,
that
implements
that,
even
if
it's
not
really
the
production
stuff
is
just
something
that
or
someone
can
experiments
with
with
those
API
it
I,
don't
think
we
want
to
keep
it
as
a
document.
G
I
think
we
want
to
move
just
like
open
messaging
did
and
start
at
least
consider
defining
limitations.
You
know
just
the
Linux
way:
you're
not
waiting
until
you
have
Fuji
a
standard
for
people
to
you're,
starting
with
something
you
have
a
strawman
proposal
and
you're.
You
know
when
bridging
up
over
time,
so.
F
A
A
D
I
tuned
in
halfway
through
this
through
this
topic,
it
sounds
like
there's
a
few
things
being
discussed
at
once.
That
is
like
how
we
do
versioning
and
what
the
scope
is
of
this.
This
initial
version
that
we're
putting
out
I
keep
in
mind
that
the
specification
right
now
actually
has
a
property
in
there.
That
indicates
what
version
of
a
spec
that
you're,
using,
which
should
hopefully
mitigate
a
lot
of
issues
and
I.
Think
that,
should
that
should
be
one
of
the
first
priorities
for
us.
D
As
far
as
versioning
goes
I'm
a
fan
of
just
using
simple
versioning
and
not
using
words
like
alpha
or
beta,
just
because
I
think
that
it
will,
it
will
probably
steer
people
away
when
we
actually
need
to
build
momentum
right
now
and
I
think
that's
that's
still
one
of
the
most
important
things
and,
furthermore,
I
think
that
anything,
that's
version
zero,
whatever
it's
kind
of
implicit,
that
it
is
a
beta
or
kind
of
a
new,
a
new
effort.
So
anyway,
those
are
my
thoughts
on
versioning
I
agree
with
a
lot
that
matt
said.
D
I
think
we
need
to.
You
know,
continue
to
talk
about
the
scope
of
this
effort.
Again
there
is
a
scope.
That's
drafted
up
in
the
specification,
I
think
just
settling
on
what
that
scope
is,
should
be
one
of
the
top
priorities
for
this
group.
If
people
think
that
this
that
there
should
be
more
or
something
else
in
the
scope,
we
should
we
just
shy
about
it
right
away.
All.
A
G
E
A
Make
sense
so
what
I
like
to
do
is
suggest
that
we
don't
spend
more
time
talking
about
this.
One
I
think
of
a
lot
of
great
ideas
mentioned
and
we'll
take.
Some
of
us
will
take
this
one
off
line
and
if
there's
a
PR
that
can
come
out
of
here
that
maybe
defines
our
release
process
or
something
like
that.
We'll
submit
a
PR
with
give
me
people
something
concrete
to
to
look
at
and
review,
but
this
has
been
good
just
for
gathering
ideas
of
what
people
think
in
the
space.
A
A
G
A
So
that's
wait.
A
minute
seems
like
more
than
one
person's
typing.
I
can't
tell
okay.
So
yes,
there's
a
push
for
and
implement
the
reference
rotation.
Okay,
so
we
talked
about
reference
implantation.
Are
we
talking
about
how
many
understand
Solis-
and
you
said
yes
or
I-
think
it
was
you
to
suggest
you
said
conformance
tool.
Sorry.
J
L
A
L
D
My
company,
as
a
few
things
that
we
like
to
contribute
for
reference,
implementations,
I,
think
that
there's
a
few
things
we
could
we
could
make
be
that
would
help
people
use
this
right
away.
A
few
tools,
for
example,
some
type
of
middleware
that
you
could
put
in
your
AWS
land
of
functions
to
convert
AWS
events
to
this
specification
before
it
actually
enters
your
function.
I
think
we
could
build
a
simple
libraries
and
stuff
to
support
that
I.
Think
that
would
be
a
huge
use
case.
D
We'd
love
to
contribute
that
to
the
cloud
events
repository
also
we're
looking
at
it.
Some
type
of
story
with
Kafka
as
well
I
think
that
would
be
very
useful
and
add
a
lot
of
legitimacy
to
this
effort
and
then,
of
course,
we
have
our
own
event
Gateway
project,
which
we've
been
working
on
for
a
long
time,
which
is
going
to
fully
embrace
the
specification.
Okay.
A
A
Oh,
what's
that
time,
Thank
You,
romantic,
okay,
so
okay,
I,
don't
want
to
get.
This
is
a
little
bit
talking
about
process
a
little
again,
but
I
just
want
to
start
the
discussion
around
at
some
point.
It
seems
like
it'd,
be
useful
to
make
sure
that,
as
we
start,
adding
new
features
to
the
specification
there
may
be
some
bar
other
than
we
think
it's
a
good
idea
before
something
gets
in,
for
example,
others
backs
a
lot
of
times.
What
they'll
do
is
say.
A
Nothing
no
new
feature
goes
into
the
spec
until
they're
at
least
say
two
implementations
that
implement
that.
So
we
can
see
how
it
looks.
People
can
play
with
it.
They
can
see
it
in
action
and
actually
see
that
it's
real
and
it's
not
just
some
pilots
guy
thing
that
people
are
thinking
of
I'm,
not
sure
I
have
to
decide
anything
right
now,
because
the
spec
is
so
immature.
A
But
I
would
like
you
all
the
sort
of
thinking
about
whether
we
want
to
introduce
that
bar
into
our
process
at
some
point,
because
I
do
think
as
a
lot
of
people.
That
said
in
this
call
code
talks
and
these
days,
not
just
paper,
specs
and
so
I
think
we
should
try
to
get
to
the
point
we
have
behind
this
at
some
point
to
justify
what
we're
doing
for
each
step
of
the
way.
So
let
me
just
stop
about.
F
F
We
should
be
creating
libraries
to
help
people
create
conformant
events
so
for
all
the
different
languages,
so
whatever
tooling,
whatever
language
I,
have
on
a
client
or
on
the
server
side.
For
that
matter
that
we
we
give
them
a
language
that
implement
suspect
that
this
group
contributes
and
that
we
host
on
our
get
up
and
then
then
the
issue
of
creating
the
conformance
tools
diminishes
because
they
can
ascribe
the
libraries
that
we
endorse
and
we
know,
are
conforming
to
a
certain
words
in
this
book.
You.
A
So
my
first
like
I,
think
as
Austin,
you
said
this:
the
scope
should
sort
of
dictate
what
we
put
into
the
spec.
Oh
I'm,
not
sure.
That's
fine
grained
enough
personally
right,
because
that
won't
necessarily
help
us
to
say.
Oh,
someone
wants
to
add
a
full
property
and
it's
because
it's
something
that
they
need
in
their
specific
implementation,
but
no
one
else
that
sees
any
value
whatsoever.
F
B
F
A
Obviously,
yes
successful,
it
needs
to
be
there.
I
mean
just
under
six
from
an
experience
I've
seen
in
other
specs
I've
seen
them
have
this
bar
in
there
and
that's
why
I
want
to
raise
the
question
about
whether
we
want
to
have
that
bar
there
and
since
I'm
getting
is
as
at
least
as
of
right.
Now
we
probably
don't
want
to
think
about
having
that
bar
and
that's
fine
well.
H
Actually,
I
completely
agree,
which
was
why
I
was
working
on
the
governance
modifications
and
you
know,
Doug
has
opened
an
open
issue
to
specifically
talk
about
moving
towards
a
process
which
would
allow
for
more
async
normal
kind
of
LG
TM.
So
I
think
this
is
really
under
that
governance
thing.
Some
people
think
it's
premature
to
get
into
that
type
of
Governments
discussion,
so
I
think
we
should
just
you
know,
keep
talking
about
it
offline
and
in
issues,
because
I
think
it's
actually
super
important
right
now
we
are
favoring.
H
This
discussion
over
async
participation
and
I
think
we're
seeing
the
effects
of
that,
because
everything
is
a
vote
of
this
group
that
meets
an
in
live
instead
of
being
a
result
of
discussion
on
PRS
and
so
but
I
think
everybody
wants
to
move
to
more
async
stuff,
so
I
think
we're
getting
there.
Yeah.
A
Okay,
anyway,
just
why
they
started
having
a
discussion,
I
think
get
input
there.
No
resolution
or
no
action
taken
from
this
at
this
point
in
time
we
are
are
almost
at
a
time
and
I,
don't
think
we
have
time
to
jump
into
a
new
topic.
However,
I
do
want
to
make
sure
I
keep
you
all
the
roll
calls
brihat.
So
let
me
just
go
through
the
list
of
attendees
that
do
not
have
a
star.
Next
I
mean
that
I
confirm
they're
on
gym
courtesy.
There.