►
From YouTube: CNCF Serverless WG Meeting - 2018-03-22
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
All
right,
let's
turn
to
roll
call
stuff
Clemons,
either
I.
C
A
On
it,
Varun
or
either
yep
all
right
cool
at
Rakowski
here.
E
A
B
A
A
E
A
A
A
A
William
unusual,
usually
either
okay
John
mature
I
got
you
right.
Is
there
anybody
the
call
who
I
did
not
mark
with
an
asterisk
I
got
everybody
except
William.
D
A
Yeah
I
got
Jo
Kathy.
Are
you
there
yeah.
A
A
G
G
Do
a
couple
quick
introductions
for
some
for
some
newcomers.
First
off
super
excited
to
have
Eric
Erickson
from
Nordstrom
joined
the
call
I
I've
been
going
out
and
trying
to
seek
some
new
perspectives
to
join
this
working
group.
People
who
aren't
focused
on
providing
infrastructure
as
a
service,
specifically
so
I've
invited
Eric,
who
is
very
popular
in
the
service
community
in
general
and
looking
forward
to
his
perspective
as
well
as
I,
think.
G
G
Yeah
I
see
him
on
the
list
here
there
we
go
sorry
yeah
now,
I'm
off
you,
yes,
yep,
yes,
so
spread,
there's
a
lot
of
service
things
and
open-source
things
over
Accenture
and
again.
I
think
that
they
have
a
useful
perspective
that
they
could
lend
excited
to.
Just
you
know,
have
AB
these
news
perspectives
join
the
effort,
that's
great!
Thank
you
and
welcome
guys
thank.
A
You
everyone
all
right
all
right,
so
let's
jump
right
into
the
agenda
so
couples
we
still
have
some
outstanding
action
items
would
be
able
to
do.
Is
please
when
you
get
a
chance,
take
a
look
at
yours.
I!
Don't
want
to
spend
too
much
time
there.
Just
another
reminder
for
kook
on
face
to
face
with
yours,
a
doodle
poll.
It's
not
that
important
anymore
just
want
to
make
sure
we're
just
gonna
have
quorum
and
I
think
we
have
15
people
right
now
signed
up,
so
we
definitely
will
have
quorum
there.
A
So
we
are
going
to
have
a
meeting
and
it
will
be
an
official
meeting
and,
as
I
said
last
time,
I
will
set
up
a
dock
for
us
to
be
able
to
add
topics
as
we
get
closer
to
the
event.
I
think
a
little
premature
to
do
that
right
now.
So
with
that,
let's
jump
into
some
PR
work,
so
I
added
four
to
the
list,
which
should
be
relatively
straightforward,
see
if
we
get
these
out
of
the
way,
I
believe
Rachel
this
one
first
one
might
be
yours.
You
want
to
talk
to
it.
A
Any
objections
to
moving
these
two
documents,
all
right,
excellent!
Thank
you,
Sarah,
easy
enough,
so
Rachel
Rachel,
I'm,
sorry,
Rachel,
sorry,
okay!
Next
one
is
mine.
This
one,
since
we
approved
that
Cara
wish
Spirit
was
last
week,
but
basically
we
revamped
the
scope
and
stuff.
There
was
a
suggestion
to
go
in
and
remove
this
section
since
it
seemed
to
be
duplicate
or
old,
so
I
did
that
PR.
So
basically,
all
I
did
is
remove
the
status
section,
since
we
know
how
the
scope
stuff
is
there
any
questions
on
that.
Well,.
D
A
Alright,
cool.
Thank
you.
Louise
I
think
this
one's
yours.
You
want
to
talk
to
it.
I
had
a
tracing,
ID
I've
been
tracing.
They
hide
the
comments
here
for
a
sec,
yeah.
K
So
that
this
essentially
is
adding
a
section
into
the
who's,
the
abuse
case
document
on
event
Tracey,
essentially
just
to
indicate
that
we
need
some
mechanism
being
able
to
have
a
cover.
The
case
where
we
have
a
sequence
of
events
that
are
result
from
an
initial
event
and
have
some
mechanism
of
being
able
to
trace
those
events
through
multiple
intermediate
devices.
A
That
alright,
now
the
words
by
not
seen
a
comment
asking
you
to
put
a
blank
line
in
there,
if
that's
not,
obviously
material
change,
so
we
can
obviously
do
that
before
I
actually
merge
it.
If
you
don't
get
a
chance
to
do
that,
I
can
do
that
for
you
later
today.
I
think
I
have
admin
access
to
make
that
change.
Okay,
any
objection,
then,
to
accepting
this.
A
G
Sure
this
is
a
pretty
minor
PR
Sarah
did
a
great
job
of
refining
our
roadmap
to
be
oriented
around
versions
instead
of
dates,
and
when
she
made
that
change
there
was
a
couple
agenda
items
that
weren't
under
specific
versions.
They
were
in
a
section
called
additional
items
and
I
felt
it
was
important
to
put
some
of
those
items
as
agenda
items
or
action
items
in
specific
versions,
because
some
of
them
are
pertaining
to
the
marketing
of
this
effort
and
I.
G
A
Any
questions
on
this
yeah
I
think
it's
been
out
there
for
a
while
I
think.
Last
night
you
made
some
very
minor
editorial
tweaks,
nothing
substantial!
So
it's
been
out
there
for
a
few
of
the
review.
Any
questions
or
comments
on
this
all
right.
Any
objections
to
accepting
it
excellent
cool
all
right,
in
that
case
we're
done
through
what
I
consider
to
be
the
easy
PRS.
A
Next,
so
Sarah,
you
made
a
suggestion
here
to
talk
about
the
scope
of
the
specification
for
the
roadmap
before
I
before
I.
Get
you
to
talk
to
your
suggestion
here.
I
do
want
to
just
point
out
that
I
think
was
actually
last
week's
call.
We
agreed
to
this
text
in
the
spec
already
which
to
me
pretty
well
defines
the
spec
that
the
scope
of
the
spec
itself
so
go
ahead
and
make
your
point,
though
I.
D
Think
when
we
agreed
upon
the
high
level
design
goals,
we
felt
that
there
wasn't
really
enough
specificity
to,
for
example,
answer
the.
What
is
Sora's
question
and
what
I've
seen
happen
in
the
discussion
of
attributes
is
that
there
are
multiple
attributes
that
combine
together
to
achieve
one
of
the
goals,
and
so,
if
we
don't
refine
those
goals
a
bit
more
than
and
and
deal
with
things
one
attribute
at
a
time
you
know
like
we
haven't
really
scoped
the
spec
and
so
I
feel
like
the
work
that
Clemens
did
on
the
usage
scenario.
D
Section
would
address
that
concern
and
I
think.
Actually,
the
the
description
of
the
producer
goes
a
long
way
towards
answering
a
bunch
of
the
confusions
about
what
is
source
and
I'd
like
to
just
propose
finish
that
before
deciding
on
any
of
the
attributes,
so
we
can
have
discussions
about
them
and
move
the
discussions
forward
where
people
feel
that
they
are
aligned.
However,
I
would
like
to
not
address
any
PR
for
any
attribute.
Until
that
usage
scenario
is
PR
is
committed.
C
So
I
personally,
don't
feel
like
that.
The
use
of
scenario
discussion
is
even
doing
anything
to
the
scope
of
the
specification.
Let's
cover
the
specification
is
about
us
having
common
metadata
and
data
attributes
that
help
us
to
facilitate
interoperability
and
that's
a
scope
of
it
and
I.
Don't
think
we
we
expand
the
scope
and
I'm
actually
not
willing
to
go
and
take
a
step
back
to
you
know
the
beginning
and
talk
about
the
scope
of
the
spec
again.
C
Okay,
but
I
would
rather
go
and
start
making
progress
because
ultimately,
there's
a
bunch
of
people
around
here
who
are
interested
in
writing
code
and
where
I
think
we're
we're
very
close
to
writing
code
and
I.
Think
there's
a
growing
consensus
in
the
group
that
we
are
fairly
close.
So
I
would
like
to
get
to
the
point
of
us.
You
know
going
through
the
user
scenarios,
which
we
talked
about
already
this
week
for
two
hours
and
and
look
at
them
again.
C
D
J
This
is
Rachel,
I
I
think
that
this
so
the
the
idea
that
we
would
be
taking
a
step
back
to
if
we
become
aligned
on
what
it
means
to
be
interoperable.
It
seems
like
a
mistake
to
me,
like
the
point
of
being
interoperable,
is
that
we
agree
on
like
this
is
the
point
that
we
agree,
and
so
we
have
to.
We
have
to
start
agreeing
on
things
before
we
start
writing
code.
So
then,
let
me
ask
the
questions
back.
What
what.
J
Like
so
in
talking,
so
the
one
of
the
reasons
that
we
started
talking
that
we
asked
people
to
start
making
presentations
about
what
they
saw
like
how
they
understood
events
to
work
is
because,
in
the
conversation,
people
were
using
the
same
words
in
subtly
different
ways
which
revealed
to
me
to
others
that
we
were
not
that
we
didn't
have
the
same
picture
in
mind.
Right
I.
Think
that
I
think
that
the
usage
scenarios
do
a
great
job
of
making
sure
that
we
are
aligned.
J
C
G
C
F
F
A
I'd
like
to
make
a
suggestion
here,
cuz
I
think
I've
heard
several
different
things.
One
is
someone
was
suggesting
that
we
we
we
don't
really
work
too
hard
or
work
too
fast
on
the
attributes
until
we
agree
on
things
like
the
use
of
scenarios
and
I
will
point
out
that
uses
scenarios
is
the
very
next
thing
we're
going
to
be
talking
about,
so
we
are
going
to
be
trying
to
get
agreement
on
that.
The
other
point
I
want
to
make,
though,
is
going
forward.
A
Basically,
everything
is
done
through
PRS,
whether
you
want
to
change
the
process
or
you
want
to
use
a
governance.
You
want
to
say
the
spec.
Everything
is
done
through
PRS
and
this
phone
call
every
week
in
the
limited
time
we
have.
We
can't
spend
time
on
this
call
necessarily
doing
a
whole
bunch
of
abstract
discussions
or
talking
about
alignment
and
stuff
most
of
those
discussions.
Just
the
nature
of
time
have
to
be
done
offline.
A
So
if
there
are
people
who
feel
that
we
are
not
aligned
on
a
particular
topic,
I
would
strongly
recommend
that
we
set
up
additional
phone
calls
outside
of
this
Thursday
one
to
have
those
discussions
and
have
the
result
of
those
discussions
be
pr's
back
to
the
working
group
for
changes
in
some
documents.
Someplace,
because,
as
I
run,
this
call
I'm
going
to
give
priority
to
pull
requests,
because
that
is
ultimately
what
drives
us.
Our
work
forward.
So.
D
We
just
accepted
a
small
modification
to
the
road
map.
The
road
map
was
agreed
upon
several
weeks
ago.
It
has
two
bullet
points.
One
is
the
design
goals
which
we
agreed
upon
last
week.
The
other
is
the
scope
of
the
specification
we're
talking
about
that
bullet
point
which
was
addressed
in
a
PR
some
time
ago,
and
so
it's
I
believe
that
we
don't
have
alignment
on
the
scope
of
the
specification.
A
D
C
On
the
use
of
scenarios,
discussion
on
this
particular
PR
I
wanted
time
boxes
to
ten
minutes,
because
I've
already
spends.
We
already
spend
at
least
two
hours
about
two
and
a
half
hours
on
this
this
week
in
a
group
and
on
this
section,
I
would
like
to
hear
the
folks
who
have
not
been
present
in
that
and
those
in
those
talks
to
speak
up
and
see
what
their
their
opinion
on
this
is.
C
First
is
I'm
talking
about
so
first
of
all,
I'm
I'm
finding
in
the
in
the
first
paragraph
saying
this
is
what
what
this
is
about,
and
it's
user
scenarios
developer
perspectives.
The
second
is
I'm
making
clear
that
I'm
keeping
the
roles
of
event
producer
and
consumer
distinct,
that
is
to
mean
we're
talking
about
of
one-way
flow,
but
one
application
can
always
take
on
multiple
roles,
concurrently,
which
including
beef,
being
both
a
pursuit
producer
and
consumer
of
events,
which
means
if
the
application
wants
to
go
and
take
this.
C
What
we'd
finally
hear
and
model
a
bi-directional
flow
on
top
of
it
and
that's
fine.
It's
just
not
the
focus
of
what
we're
doing
so.
First
applications
produce
events
for
consumption,
and
you
can
go
and
read
this
itself.
I'm
just
going
to
go
and
highlight
what
it's
highlighting
what's
important
is
that
events
are
typically
produced
related
to
a
context,
so
they
come
in
from
somewhere
or
they
are
produced
based
on
a
producer
chosen.
C
Classification
I'll
have
some
examples
in
the
following
PR
discussion,
so
I
can
with
pictures,
but
for
a
temperature
sensor
or
a
room
here
may
be
context
qualified
by
the
mountain
position,
which
means
where
is
it
in
a
room,
a
room
before
building
that's
something,
that's
fairly
concrete
and
that's
what
I
call
context
or
it's
purely
abstract,
like
a
sports
result
and
that's
classified
by
league
and
teams,
I'm,
also
making
clear
that
as
producer-
and
it
also
applies
to
the
consumer
later-
could
run
anywhere.
C
It's
a
server
or
device,
and
then
I'm
also
making
clear
here,
because
we
have
some
IOT
folks
that
the
produce
to
fit
the
the
origin
of
the
events
effectively.
The
original
producer
matters,
and
not
necessarily
the
one
who
then
ultimately
renders
the
message
as
a
cloud
events
message.
So
if
we
decide
that
our
and
of
transport
binding
has
a
particularly
panned,
the
events
need
to
be
rendered
in
a
particular
way.
C
C
Make
it
as
broad
as
possible
to
something
meant
to
be
an
exhaustive
list
and
again
the
consumer
might
be
anywhere
so
we're
not
being
specific
about
the
consumers
being
several
as
applications.
It
could
also
be
clients
and
I'm
gland
here,
I'm,
starting
to
enumerate
a
few
things
that
the
consuming
application
is
interested
in
and
that
drives
requirements
towards
the
producer.
So,
for
instance,
they
want
to
be
able
to
distinguish
it.
The
exact
same
event:
it's
not
processed
twice.
C
They
want
to
be
able
to
figure
out
looking
at
an
event
where
that
event,
what
context
that
event
is
related
to
or
how
that
event
has
been
classified
by
the
producer.
They
want
to
identify
the
temporal
order
of
the
events
relative
to
the
originating
context.
If
the
device
that
is
there's
a
device
that
originates
the
events
and
it
doesn't
have
a
real-time
clock,
then
at
least
we
need
to
give
it
a
way
to
go
and
say
and
give
some
sequences
to
them
to
the
messages.
All
temporal
order
is
based
on
you
to
see
wall
clock.
C
But
if
you
see
wall
clock
is
obviously
in
order
and
criterion
that
also
works,
and
then
we
want
to
understand
the
context
related
detail
information
carried
in
the
event,
which
means
there's
data
that
we
want
to
understand
and
to
understand
the
data.
We
need
to
know
what
shape
it
is
and
then
we
will
probably
want
to
be
able
to
correlate
multi-event
instances
from
multiple
event
abusers
and
sent
them
to
the
same
consumer
context.
So
there's
got
to
be
some
way
of
how
we
can
go
and
identify
stuff
that
belongs
together
and
then
there
is
further.
C
Furthermore,
we're
covering
with
that.
With
the
next
points.
We
cover
the
cases
where
the
event
doesn't
come
doesn't
carry
complete
information,
because
it's
not
possible
to
do
so
for
legal
reasons
or
for
security
reasons.
So
you
have
an
HR
application.
That
raises
raises
an
event
about
a
new
employee
record,
haven't
been
created
and
that's
something
that
an
application
may
be
able
to
go
and
catch,
but
to
actually
get
at
the
PII
of
that
employee.
It
will
have
to
go
back
to
the
PR
to
the
HR
application
and
then
pull
out
all
the
details.
C
So
an
event
may
not
be
completely
self
contained,
but
may
contain
inside
of
its
payload
pointers
back
to
the
original
source.
Where,
then,
all
the
details
that
are
really
necessary
for
processing
that
events
are
hosted,
and
then
they
may
also
contain
information-
is
the
second
bullet
here
interact
with
the
events
at
the
originating
context.
So
you
get
an
alarm,
for
instance,
or
you
get
alerted
about
a
new
blog
file
having
been
created,
and
then
you
want
to
be
able-
and
you
know
that
that's
a
JPEG
file
and
you
want
to
go
and
create
new
thumbnails.
C
Based
on
that
JPEG.
You
obviously
have
to
go
back
to
the
subject
of
that
event,
the
blog
that
has
been
created
and
then
loaded
and
create
your
thumbnails.
So
that's
something
that
also
consumers
might
be
interested
in
further
down
and
what
we
also
called
out
here
in
the
in
the
just,
so
that
the
consumer
interest
motivates
that's
a
thought
piece
effectively.
C
The
consumer
ultimately
motivates
what
the
producer
needs
to
put
into
the
event,
because
the
consumers
are
interested
in
information
producer,
withholds
information
based
on
some
some
considerations,
as
we
just
said,
with
the
HR
application,
but
otherwise
it's
effectively
always
the
consumers
that
drive
what
needs
to
be
in
an
event
or
not,
and
how
that
also
needs
to
be
structured.
Then
we
get
to
the
section
on
so
questions
so
far.
Yes,.
K
C
So
there's
a
requirement
here
that
the
consumer
makes
and
we're
capturing
that
that
you
can
correlate
event
instances
from
multiple
event,
producers
to
send
them
to
the
same
consumer
context.
That's
also
that
implies
that
the
same
event
producer
obviously
also
needs
to
be
able
to
go
and
provide
a
correlation
criterion.
Okay,.
C
C
Is
these
message,
brokers,
event,
event,
browsers
event,
jesters
effectively,
anything
even
for
the
the
proct
and
HTTP
proxy,
or
for
an
HTTP
load
balancer
or
even
the
HTTP
dispatch
logic,
assets
webserver
everything
all
of
those
pieces
are
middleware
everything
that
is
not
the
the
code
that
produces
the
event
and
the
code
that
that
processes.
The
event
is
effectively
middleware,
so
middle
of
our
routes,
events
for
producers
to
consumers
or
on
works
to
other
middleware,
so
middlewares
middleware
my
chain
might
cause
chains.
C
You'll
also
see
that
later
applications
producing
events
might
delegate
certain
tasks
arising
from
their
consumers
requirements
a
middle
layer,
so
it's
ultimately
the
producer
and
the
people
who
configure
the
producer.
So
it's
not
only
the
producers
code,
but
it's
the
commute
because
the
producer
deployment,
including
the
configuration
for
that
deployment,
that's
a
all
of
those
things
together.
Taking
there's
a
decision
being
made
as
you
as
you
take
that
code,
you
configure
it.
Where
are
those
events
flow
and
then
also
what
middleware
you
take
and
configure
with
it
too,
and
then
which
paths
you
delegate
out.
C
So
in
some
kit,
in
some
case
you
may
have
a
software
and
there's
a
producer
that
just
calls
a
wet
hook
and
in
some
case
you
may
have
a
consumer
that
just
is
takes
the
web
hook
and
then
you
put
them
together
into
the
middleware,
is
effectively
just
HTTP
stacks
on
both
ends.
But
you
may
take
the
exact
same
pair
of
producers
and
consumers
in
a
slot
and
events,
bus
in
the
middle
and
they
won't
know.
C
F
C
C
I
think
we
can
so
correlation
is
something
it's
correlation
is
something
that
we
can
very
very
easily
do
using
a
clever
interpretation
of
our
of
the
the
discriminators
that
we
need
to
go
to
find
anyway,
so
I'll
actually
go
and
present
a
solution
to
that.
So
this
is
something
that
is
a
problem
statement
and
that
belief
in
that
problem
statement.
Kathy
brought
up
a
good
point
about
it,
so
I
believe
in
that
in
a
problem
statement
and
but
I
think
there's
no
expansion
of
the
scope
that
we
have
already
to
address
it.
Yeah.
C
C
C
That's
a
distribution
tassets
to
believe
that
in
the
middle
you
don't
make
the
producer
do
a
for
loop
and
send
the
same
event
20,000
times
typically
also
there's
a
way
for
if
you
publish
your
lots
of
events
and
you're
interested
in
a
class
of
events,
you're
not
interested
in
all
of
the
events
from
that
class,
but
you're
interested
in
subsets
of
them.
So
there's
processing
of
filter
conditions,
something
that's
very
common
and
pops
up
software.
It's
also
being
done
there.
Sometimes
the
middleware
we'll
go
into
transcoding.
C
You
show
up
and
you
submit
an
event
in
a
message
pack
and
then
you
want
to
go
sorry
in
Jason
and
you
want
to
have
it
a
little
bit
more
compact.
So
you
put
in
your
message
back
or
simpler,
you
put
a
text
file
in
or
some
text
event
in
and
he
wants
to
have
it
zipped
for
a
for
transfer.
That's
also
transcoding
transcoding
message
doesn't
change
the
shape.
C
It
merely
changes
the
way
how
the
data
is
coded
on
the
way,
then
there's
transformation,
also
very
common
in
enterprise
integration
scenarios,
where
the
goal
is
to
keep
the
semantic
integrity
intact
of
the
events,
so
that
in
still
the
same
events,
but
there's
a
remapping
happening.
So,
for
instance,
if
I
take
a
native
a
native
event,
that's
being
emitted
through
after
event
occurred
today
and
if
I
want
to
map.
If
I
map
it
into
a
called
events,
event,
that's
a
transformation
and
that
will
not
change
semantics
of
the
event
per.
C
A
C
So
so,
ultimately,
so,
ultimately,
there's
there's
again
there's
scenarios
then
there's
the
middleware
then
drives
a
further
set
of
requirements
again
on,
ultimately
on
the
producer
who
needs
to
produce
an
event.
We
also
went
effectively
this.
These
things
are
all
following
out
of
the
store,
the
the
scenarios
up
here
and
we
talked
through
that
in
detail,
and
let
me
get
let
me
get
to
the
framework
session,
and
then
we
have
the
fourth
one,
which
is
really
about
frameworks
and
frameworks
are
not
in
the
so
frameworks
are
not
necessarily
in.
E
C
They're
neither
producing
the
events,
nor
do
they
consume
the
events,
nor
do
they
route
the
events
but
they're
actually
helping
the
application
developer,
do
to
make
things
easier
and
frameworks.
What
frameworks
do
is
they
often
do
dispatching
so
when
you
think
about
most
public
popular
application
frameworks
and
they
take
some
kind
of
requests
and
now
make
it
dispatch
it
some
user
code?
So
if
the
user
code
is
a
function,
then
there
needs
to
be
enough
information
in
that
event.
C
For
that
dispatching
to
happen,
and
typically
you
take
an
event
stream,
a
fairly
narrow
event
stream
and
that
event
stream
may
have
a
few
different
operations
that
you're,
observing
or
some
kinds
of
events,
I
would
say
that
you're
observing
and
what
you're
doing
with
that
framework,
especially
net
onto
a
method
and
then
another
thing
that
frameworks
obviously
do
and
that's
what
they're
interested
in
and
that's
why
we
have
a
lot
of
your
framework.
People
on
the
call
is
to
make
sure
that
platforms
are
semantically
aligned.
C
E
C
J
C
C
Each
instance
of
a
framework
will
be
a
consumer
right,
yeah,
so
yeah.
But
my
point
is
I'm
talking
about
user
stories
and
so
I'm
talking
about
people
here.
So
there's
someone
who
consumes
the
event
who
built
an
app
and
then
there's
Austin,
who
writes
frameworks
who
sits
between
the
thing
that
I
built
and
the
thing
that
the
user
builds
and
Austin
to
the
framework
builder.
Okay,.
D
D
C
A
user
story
so
therefore
there's
two
distinct
users:
there's
someone
who
build
something,
builds
the
consumer
and
there's
someone
who
builds
something
that
needs
to
handle
those
events.
Austin
needs
to
nonsence
tool,
tooling
or
answer
functions
needs
to
go
and
take
it
out.
Events.
It
needs
to
call
a
function
in
some
way.
The
normal
person
on
the
street
doesn't
do
that
work,
but
they
simply
write
the
functions.
So
there
am
personally
here
there's
a
person
here
right,
sett
framework
and
since
that's
nine,
our
middleware
more
the
consumer,
they
get
a
specific
section.
Okay,.
D
Just
to
the
point
we
there
are
multiple
potential
actors
in
source
and
there
are
multiple
potential
actors
in
consumer
and
I.
Don't
know
if
it
was
you
or
somebody
else
who
argued
earlier
in
that
aggregating.
All
of
the
producer
concerns
together
whether
they're
the
platform
provider
or
the
application
writer
was
appropriate.
Do
you
agree
that
Austin
has
a
job
I'm,
just
saying
that
if
we
aggregate
things.
F
C
A
So
this
PR,
as
it's
so-so
on
a
second
so
I,
think
maybe
a
little
misunderstanding
here
so
correctly
wrong
here,
Clemons,
but
your
your
PR
is
really
just
sort
of
laying
the
groundwork
and
explaining
the
various
actors
that
may
in
be
involved
in
the
bigger
picture.
Here.
It's
not
necessarily
defining
our
set
of
attributes
or
eating
like
that.
It's
just
sort
of
laying
the
groundwork
for
someone
understand
all
the
things
that
we
thought
about
as
we
develop.
The
specification
is
right:
okay,.
B
C
A
C
A
Right,
so
it's
okay,
so
moving
forward
in
terms
of
process
here
we
have
appear
in
front
of
us
now,
keep
in
mind
a
couple
things.
First
of
all,
nothing
in
this
pull
request
is
normative.
Okay,
it's
all
just
explanatory
text
to
help
you
lay
the
groundwork
for
someone
reading
the
spec
to
understand
what
was
going
into
our
thinking
as
we're
making
decisions.
Okay,
nothing
here
is
normative.
The
other
aspect
is
at
this
point
in
time,
especially
since
it
is
such
a
large
PR.
A
We
are
not
looking
for
everybody
to
look
at
this
and
say
yes,
it
is
perfect.
People
can
make
further
changes
later
on
with
additional
PRS.
What
we're
looking
for
right
now
is
whether
this
is
a
step
forward
in
the
right
direction
and
whether
it
would
make
the
spec
better
to
add
it,
as
opposed
to
make
it
worse,
because
if
we
wait
until
it's
perfect,
we're
never
gonna
merge
it.
So
remember
we're
not
looking
for
perfection
we're
just
looking
forward.
Is
it
a
step
forward
in
the
right
direction
and
is
there
anything
here?
A
F
That
guy
observed
mixed
feelings,
I
think
it's
good
to
have
a
nice
background
on
the
other
and
I'm
sort
of
a
little
afraid
that
we're
getting
into
too
many
details
about
the
event
itself,
as
if
that's
our
focus,
that's
the
group
focus
I.
Think
that
group
focus
is
about
transferring
events
between
systems,
not
about
the
actual
nature
of
the
event.
F
G
I
think
that
this
looks
pretty
good
and
provides
a
lot
of
necessary
clarity
not
for
the
perfect
end
result,
but
for
moving
forward
and
just
getting
to
the
first
version
of
the
specification,
definitely
hearing
a
lot
of
anxiousness
to
try
and
move
forward
and
focus
on
how
we
can
I'm
focused
on
getting
that
initial
version
out,
keeping
it
minimal
and
finding
alignment
on
these.
These
core
attributes
that
seem
to
be
seem
to
be
difficult
to
align
on
and
I.
D
Those
were
this
is.
This
is
kind
of
my
point.
I
met
a
note
in
the
docs.
The
Clement
responded
to
things
with
comments,
which
means
this
PR
is
accepted,
all
of
that
information
and
clarification
will
be
lost,
and
so
I
think
that
there
are
some
really
key
points
that
some
might
argue
our
wordsmithing.
But
since
they
generated
a
bunch
of
confusion
in
the
comments,
I
would
argue
or
not.
Wordsmithing
maybe
wordsmithing
can
resolve
them.
However,
there
is
exists.
D
Somebody
says:
why
aren't
we
calling
this
cloud
messages
rather
than
cloud
events
which
I
think
gets
to
the
core
problem
that
we
don't
yet
have
enough
to
explain
and
that
comes
up
almost
weekly
and
so
I'm
happy
to
hold
pen
for
a
day
or
two
if
Clemens
or
you
don't
want
to
do
that
wordsmithing,
but
I
believe
that
it
is
necessary.
So.
C
D
C
Don't
have
to
agree
with
you
or
I,
don't
have
to
agree
with
your
objections
and
cause
text
changes
because
of
it.
That's
not
how
that
works.
Okay,
so
I
read
your
I.
Can
I
can
disagree
with
you?
This
is
my
text.
All
right,
I
write
it
I
hold
the
pen.
I
propose
this
PR
is
done.
I
will
make
no
further
changes.
C
We
will
go
and
and
vote
on
it
and
then
you
and
then
you
can
go
and
and
make
amends,
but
there
I
don't
see
any
any
reason
for
there
to
be
for
it
to
block
this.
At
this
point,
do
you
not
have
to
have
addressed
the
objections,
and
so
there's
and
and
you
can-
you
can
open
a
PR
in
ten
minutes
to
go
and
address
it?
C
We
have
version
of
the
spec
were
in
the
process,
but
we
don't
need
to
if
we,
if
we
just
keep
PRS
open,
open,
open,
open,
unchanged
the
spec
we
don't
make
for
any
progress.
So
if
you
believe
that
this
that
this
PR
holds
the
spec
back
or
throws
it
back
as
is
then
we
should
not
take
it
and
abandon
it
and
not
have
use
of
section
so.
D
A
So
it's
like
we're
gonna
run
out
of
time
here
so
again,
Sarah,
let's
go
back.
Ok,
I'm,
not
I,
agree
with
you
that
there
are
questions
that
maybe
they
were
the
original
ask
or
the
question
would
have
liked
to
see
some
sex
changes
and
sometimes
Clemens
made
those
changes.
Sometimes
he
didn't
that's
fine.
However,
very
specific
question
is:
is
there
any
comment
in
here
that
you
see
that
you
feel
like
needs
to
be
made
before
the
PR
is
actually
merged
and
cannot
be
made
in
a
subsequent
PR
itself?.
D
C
That
is
not
the
truth.
I
wait,
I
waited
I,
want
I
waited
on
Monday
didn't
do
anything
so
that
I
don't
throw
things
off
then
the
call
closed
on
Tuesday
and
it
went
through
and
did
all
the
changes
you
can
go
and
look
at
the
lock
that
it's
just
not
it's.
Just
not
the
truth.
I
went
through
and
address
all
those
things
and
it
actually
addressed
all
those
all
those
things
in
the
call-
and
you
see
there
you
go
a
day
ago
at
they
I
mean
those
rows
through
it.
A
D
C
Have
two
hours
in
talking
calls
you
had
you
had
you
had
four
days
right
since
we
have
time
go
through
those
two
words,
one
of
those
things:
I,
don't
I,
don't
know
what
the
holdup
here's.
What
I
want
to
do
is
I
want
to
get
to
working
on
the
document
and
not
working
on
this
usage
section
and
and
we're
going
to
I'm
serious
right,
I.
Don't
think
this
is
no
normative
text
nobody's
going
to
go
to
software
base
of
this.
C
This
is
purely
existing
because
of
your
assistance
at
Sarah
that
we
need
to
have
these
user
scenarios
to
drive
some
consensus,
even
though
I
believe
that
there's
industry
consensus
actually
about
most
of
the
concepts
that
work
that
we're
trying
to
it's
friend
of
use.
Okay,
sorry!
So
that
is
what
so.
That
is
what
the
section
is
for.
I
wrote
it
right
to
create
to
provide
clarification,
I
think
for
most
people
on
this
call
this
the
content.
The
content
here
is
not
not
really
necessary
right
and
I'm
happy.
A
A
A
D
D
D
C
G
H
C
C
So
in
the
interest
of
progress
right,
the
way
forward
with
this
text
as
it
is,
is
to
take
it
and
then
modify
it,
and
then
they
case,
because
if
there
is
no
substantial
objections
to
the
entirety
of
the
text
which
that
doesn't
seem
to
be,
then
there
doesn't
seem
to
be
any
hold
up
to
go
and
take
the
entire
text
and
then
start
to
work
smithing
all
the
pieces
of
it.
In
my
absence
right
right,
so
I
don't
understand,
I,
don't
understand
what
the
holdup
is.
C
A
So
hold
on
it's
like
we're
on
time.
I'm
gonna
do
couple
things.
If
it's
what
I
hear
it
first
of
all
Clemens
since
you're,
not
here
next
week
it
sounds
like
you're,
okay,
with
someone
else
taking
the
pen
and
other
people
are
allowed
to
make
commits
to
this
PR.
You
may
have
to
be
Navin,
I'm,
not
sure
so
I
may
have
to
be
me
or
mark
or
somebody
right,
so
we
can
make
edits
going
forward
without
you
being
here.
Are
you
comfortable
with
people
taking
the
pen
in
your
absence?
Yes,.
A
The
meat,
the
meat,
then
we
switch
the
order
which
I
discussed
this
then
so,
based
upon
what
I'm
hearing
I,
don't
think
it'd
be
appropriate
to
merge
the
PR
today,
because
people
have
asked
for
more
time
to
review,
because
there
were
some
changes
made
too
soon
to
this
meeting.
So
I'm
not
comfortable
forcing
emerge
right
now,
because.
A
C
A
A
I
A
C
A
Okay,
I
think,
let
me
know,
okay,
so,
given
everything
I've
heard,
I
personally
am
not
comfortable
forcing
a
vote
at
this
exact
moment
in
time.
I
may
be
wrong,
but
forgive
me
but
I,
don't
think
I
don't
feel
comfortable
doing
that
rather
play
more
conservatively
than
rush
it
through.
So
with
that
in
mind,
it
sounds
like
we
can.
We
can
make
edits
to
this
to
this
text,
one
way
or
another,
either
directly
to
his
PR
or
forked
or
whatever.
That's
not
a
problem
Sarah.
A
J
D
A
Okay
would
do
me
there
sit
fine,
some
time
if
it's
not
if
it's
not
tomorrow,
please
don't
make
it
any
later
than
Monday,
but
send
out
a
time
pick
a
time
and
people
will
join
if
you
want
to
collaborate
on
wordsmithing
or
chain
making
changes
to
this
text.
Please
join
that
call,
because
next
Thursday,
we
will
vote
on
some
version
of
this
text.
A
A
Okay,
just
to
go
back
to
the
roll
call.
Then
William
are
you
there?
Yes,
Michael
Payne,
yes,
I'm
here,
Ryan!
Are
you
there
Ryan,
okay,
borrow
borrow
me
you
there
yeah
here,
you
know
faintly,
but
I
heard
you
Joe
Joe
Sherman,
yes,
I'm
here
about
Alex,
yep
I'm,
here,
David,
Baldwin,
yeah,
okay
and
Ryan.
Are
you
there?
A
A
To
bring
up
I
do
want
to
address
one
comment
in
here:
an
agenda
that
Sarah
brought
up,
which
is
volunteers.
To
present.
She
Sarah
suggested
that
we
have
volunteers
present
small
set
of
attributes
that
work
together.
I
would
strongly
recommend
that,
if
you
would
like
to
have
us
work
on
a
group
of
attributes
at
one
time
because
they
are
correlated
or
they're
related,
I
would
strongly
suggest
that
you
submit
a
pull
request
with
your
desired
changes.
This
goes
for
anybody
I'm
not
talking
to
Sarah
particular
just
in
general.
A
The
best
way
to
get
a
discussion
going
is
around
concrete
text
proposed
for
the
specification
I'm
going
to
give
PRS
preferential
treatment
over
discussion
talk.
Okay.
So
if
you
want
to
push
for
something
to
happen,
whether
it's
for
a
single
attribute
or
attributes
submit
a
pull
request
and
that's
the
best
way
to
get
the
discussion
going,
because
that
is
what
I'm
going
to
get
priority
to
concrete
changes,
get
priority
over
abstract
ones.
Okay,
so
with
that,
we
have
three
minutes
left.
Are
there
any
other
topics?
People
would
like
to
bring
up
I.
G
Know
our
cloud
events
website
is
not
up
hoping
that
he
could
provision
the
website
that
he
worked
on
to
github
pages
and
once
that's
done
we
could.
We
could
get
the
Linux
Foundation
to
point
the
domains
to
that.
To
that
new
website.
I
just
need
to
understand
the
status
of
that
first
yeah.
You
may
need
to
send
a
note
to
picking.
A
E
G
I
look
forward
to
working
with
people.
You
know
in
the
individual
calls
whatever
it
takes.
I
think
what
we're
doing
here
is
of
great
importance.
You
know
events
in
an
ambiguous
subject
for
so
long
getting
all
these
great
minds
together
to
align
on
something,
as
it
was
always
going
to
be
hard,
but
I
think
we're
making
a
lot
of
progress
and
I
again.
I
think
what
we're
doing
right
now
is
important
to
serverless
in
general,
but
it's
bigger
than
surplus
I
think
this.
This
is
gonna,
have
a
big,
rising
tide
effect.