►
From YouTube: CNCF Serverless WG Meeting - 2018-02-01
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.
C
B
D
B
E
E
C
E
E
E
Think
so,
or
at
least
until
I
get
a
feeling,
I
may
have
some
others
jumping
in
my
place,
but
yeah
I
mean
we're
we're
starting
to
get
pretty
involved
in
a
few
different
aspects
of
service
from
like
the
application
developers
side.
So
we're
just
chatting
with
tryst,
and
then
you
suggested
I
jump
in
the
meeting,
so
I'll
mostly
be
listening
for
now,
but
we'll
see
like
I'm
happy.
Okay,.
C
C
G
The
end
everything
else
is
right,
thank
you,
I
know,
EE,
oh
no,
II
know.
Sorry.
There
we
go.
Thank
you.
I
know
we're
at
honeycomb
dot,
IO,
okay,
just
out
of
curiosity
you're
gonna
attend
on
a
regular
basis.
I
have
gotten
an
invitation
and
it
was
like
hey.
You
know
you
should
check
it
out
and
I
think
you
can
contribute,
but
I
don't
know
if
I
actually
can
so.
If,
if
this
is,
if
it
turns
out
that
yes
I
can
I
would
love
to
excellent.
G
C
G
K
K
C
C
L
C
C
C
C
N
C
Okay
hung
Zhang.
C
Okay,
we'll
circle
back
around
later?
So
let's
move
this
where
you
guys
can
see
my
screen
right,
yep,
all
right
cool,
so
don't
wanna,
so
I
spent
a
whole
lot
of
time.
Accident
me
back
up.
Are
there
any
changes
to
the
agenda?
If
you
would
like
to
make
okay,
just
a
quick
reminder
of
the
AI
is
I.
Think
Austin
you
have
to
Oh
someone's,
adding
a
new
one
for
you,
one
for
yourself.
That's
nice,
so
just
remind
Ross!
Then
you
get
you
got
two
in
there.
I
I
C
C
Okay,
so
let's
see
you
next
step,
white
paper
I
have
no
update
since
last
week,
so
I
assume
the
the
Linux
Foundation
Geysers
doing
doing
their
reviews
and
edits
and
stuff
I'll.
Try
remember
to
ping
them
later.
Today,
I
haven't
officially
heard
anything
from
them.
Just
a
couple
of
miscellaneous
things,
I
wanted
to
cover
some
of
the
more
process-oriented
than
anything
else.
I
just
want
to
remind
people
that
we
do
strongly
encourage
everybody
with
your
formerly
part
of
the
working
group
or
just
lingering,
to
comment
on
issues
and
pull
requests
and
stuff
like
that.
C
That's
how
we're
going
to
gauge
whether
a
pull
request
is
ready
to
be
merged
or
not
or
come
up
for
essence.
A
review
on
the
one
of
these
calls,
the
more
LG
teams
it
gets,
the
better
chance
of
it
gets
merged.
So
please
comment
as
best
you
can.
Obviously,
if
you
have
a
change
you'd
like
to
see
in
there
try
to
get
in
there
sooner
rather
than
later,
just
get
in
there
that's
going
to
get
fixed
and
then
get
merged.
C
If
there
is
an
issue
that
you'd
like
to
actually
work
on
at
own,
go
ahead
and
put
some
comments
in
there
indicating
that
I'm
partial
to
this
hashtag
dibs
Kalinda
spec,
there's
a
lot
of
background
noise.
I
start
muting,
some
people,
I
can't
be
people.
So
if
you
can
go
on
mutes,
I'd
appreciate
it.
C
G
C
C
So
did
I
start
off,
or
did
you
lose
me
during
the
middle
of
my
get
stuff
or
what
is
it?
Okay?
We
lost
you
at
dibs
dibs
Wow
long
time
ago,
okay.
So
if
you
want
to
work
on
an
issue-
and
it
doesn't
look
like
it's
been
assigned
to
anybody
else-
just
please
go
ahead
and
mark
it
as
dibs
or
propounding
there
with
dibs
or
some
other
type
of
comment.
C
C
If
you
want
your
github
ID
in
the
attendance
tracker,
so
people
know
who
you
are
and
they
could
poke
you
through
github,
this
user,
PRS
and
stuff.
Let
me
know
if
you
don't
want
it
listed
here
and
I
listed
it
by
mistake.
Let
me
know
and
I'll
remove
it.
I
have
to
either
one
and
finally,
it
seemed
like
people
are
having
issues
with
git
and
I'm,
not
a
github
expert
or
get
expert,
but
I
believe
this
covers
some
of
us
today.
C
We're
running
into
in
particular
make
sure
that
in
your
get
clients
that
you
have
your
user
name
and
user,
that
email
set
appropriately
I,
don't
think
this
a
has
to
be
your
full
name,
but
we
really
would
appreciate
it.
Who
was
your
full
name?
Actually,
this
the
DCO
might
actually
require
full
names
on
a
harp
sensor,
but
either
way
we
would
really
appreciate
it
put
your
full
name
there.
So
we
know
who's
actually
signing
the
the
commits
and
then
so,
if
you
do
a
git,
config
global
L,
you
know
make
sure
it
shows
up
correctly.
C
Then,
when
you
do
your
git
commit,
if
you
include
the
s
on
there,
it'll
automatically
sign
it
and
then,
when
you
look
in
the
git
log
for
your
commit,
you
should
see
the
author
and
the
sign-off
tag
match
if
they
do
not
match
I,
think
the
DCO
check
will
fly
an
error
and
it
won't
let
your
PR
get
merged.
So
I
think
that
I
think
those
are
the
problems
that
people
were
running
into
recently
with
PRS
and
stuff.
It's
basically
not
setting
these
things
properly
and
then
not
using
the
yes
on
the
commit.
C
All
right
not
hearing
any-
hopefully
that
was
mildly,
useful
okay.
So
let's
do
peer
review
here
now,
keep
in
mind
as
we
go
forward
here,
we're
not
looking
for
an
essay
perfection
or
just
wanna,
make
sure
we're
keep
moving
forward,
and
so
hopefully
we
can
go
through
these
relatively
quickly
Austin.
You
want
to
quickly
bring
us
up
to
speed
on
this
initial
use
case,
PR
sure.
H
To
better
explain
what
we're
doing
and
why
we're
doing
it,
we
decided
to
take
a
lead
on
drafting
out
some
use
cases
for
the
cloud
event
specification
right
from
the
beginning
to
help
guide
our
efforts,
and
this
is
a
first
pass
at
those
use
cases.
No,
it's
not
final
by
any
means,
but
it's
a
it's
a
start.
Could
it
be
reworded?
Better,
probably.
H
Are
there
a
whole
bunch
of
use
cases
that
aren't
in
here
absolutely,
but
this
is
just
to
get
the
ball
rolling,
there's,
probably
five
of
them
in
there
right
now,
and
everyone
is
welcome
to
contribute
to
add
use
cases
I
think
we
should
optimize
this
whole
repo.
So
that's
all
types
of
people
from
all
walks
of
life
can
contribute
use
cases
because
it
gives
us
a
really
good
signal
as
to
kind
of
what
we
need
to
accommodate
with
the
specification
but
check
it
out.
It's
only
a
paragraph
or
two
for
each
use
case.
H
C
D
C
H
C
C
Okay,
this
one
was
mine.
I,
just
noticed
that
this
paragraph
was
going
over
the
80
columns
thing,
so
I
fixed
the
couples
places
just
this
paragraph
and
the
spot
down
here
and
then
actually
I
think
this
actually
may
be
a
duplicate
from
another
PR.
This
wasn't
missing
a
new
line
here,
so
this
is
strictly
syntactical
fix
any
comments,
questions.
F
D
C
It
yeah
excellent.
Thank
you,
okay,
next
thirty,
nine!
This
is
this.
This
is
mine.
Oh,
this
is
just
removing
the
notes
or
two
dues
that
were
left
in
the
spec
from
the
previous
draft.
The
reason
it's
okay
to
remove
these
now,
oh
and
the
backlog
stuff
is
because,
for
the
a
is
that
we
have
a
last
week's
call,
we
now
have
issues
for
every
one
of
the
two
do's
and
every
one
of
these
backlog
attributes.
So
we
can
discuss
those,
and
so
since
they're
all
for
discussion,
it
makes
sense
to
remove
them
from
the
spec.
C
H
C
All
right
next
one
is
number
15
this
one.
It
takes
the
first
pass
at
hiding
the
RFC
keywords
and
for
those
you
don't
live
and
die
by
specifications.
The
RFC
keywords
are,
the
you
know,
must
shoulds
maze
and
those
kind
of
things
it
just.
It
did
not
attempt
to
change
the
semantics
of
anything.
It
was
just
in
a
first
attempt
to
start
using
the
keywords
and-
and
there
were
some
cases
where,
like
here,
where
we
had
to
remove
uses
so
I
changed
that
must
with
our
because
must
whether
it's
uppercase
or
lowercase
does
matter
I'm.
C
Sorry,
it
doesn't
that
matter.
It
still
is
gonna
be
normative,
so
we
have
to
make
sure
we
remove
them.
Worried
then
actually
mean
to
use
it.
This
one
has
been
out
there
for
quite
some
time.
I,
don't
think
I've
made
any
changes.
I
Yeah
I
had
addressed
some
comments,
but
I
think
that
you've
addressed
everything
that
I
brought
up.
Yes,.
C
Excellent,
thank
you
very
much,
and
just
so
then
you
know
justjust
in
the
interest
of
full
transparency,
if
the
if
the
one
of
these
that
were
merging
today,
causes
a
rebase
of
one
of
the
other
ones
that
we
did
approve.
If,
as
long
as
the
rebase
is
strictly
synced
tactical
in
nature,
I'm
gonna
go
ahead
and
do
the
rebase
and
merge
it
it's
only
if
it
changes
something
that
I'm
gonna
pause
on
the
merge
and
and
bring
it
back
up
for
people
to
review.
C
C
H
Sure
thing
this
actually
has
two
things
happening
in
this
pour
Christ,
which
I,
don't
think,
was
the
best
approach
at
retrospective.
But
its
first
goal
was
to
add
a
basic
description
to
the
readme,
because
right
now,
when
you
go
to
the
readme
of
the
spec
repo
there's
not
much
there,
so
this
adds
a
basic
description
of
what
we're
doing
and
why
we're
doing
it
and
kind
of
how
to
get
involved.
So
there.
H
H
You
know
it's
chatting
with
Sarah
about
this
the
other
day
and
I
think
we
have
some
optimizations
or
some
improvements
we
can
make
to
this
roadmap,
but
I
think
we
could
possibly
merge
this
in
right
now
and
then
follow
up
with
another
pr2
to
better
and
improve
this
roadmap.
What
do
you
think
about
that?
Sarah
yeah.
I
H
H
With
it,
okay,
yeah,
yeah,
Sarah
and
I
were
chatting
about
possibly
not
doing
this
by
month,
but
instead
just
kind
of
doing
these
by
versions
like
version
0.1
should
have
you
know
basic
specification
and
use
cases
included.
You
know,
0.2
might
have
some
like
a
library
or
supporting
tool.
Something
like
that.
So
I
think
that'll
be
best
presented
to
everybody
here
as
a
separate
number
yeah.
I
H
I
C
O
H
P
Was
pushing
for
using
the
type
of
resource
that
is
common
sto,
which
has
a
name
a
server
and
a
type
as
well
as
the
labels
which
we
did
not
include
I'm
much
more
concerned
about
like
where
possible.
If
you
reuse
data
types,
and
that
you
should
call
it
just
in
big,
if
they,
by
its
type
there,
it's
going
to
be
to
resources
to
source,
to
destination.
Anyways.
F
P
Yeah
in
our
private
conversations
within
Google,
we
had
worried
about
that
a
lot
we
even
you
know
temporarily
considered
having
like
a
stack
of
some
sort.
We
decide
to
for
now
scope
it
just
to
the
original
sender
of
the
event
thing
that
actually
observed
the
occurrence
and
we
would
possibly
add
some
type
of
place
from
it
aware
later,
just
because
the
ergonomics
of
actually
using
a
stack
all
the
time
would
just
be
completely
unusable.
O
P
K
M
H
K
Also
sera,
we
had
the
check
on
that
I
think
there
is
a
distinction
between
the
protocol
aspect
and
the
message
aspect.
So
a
message
has
on
a
region
or
a
source.
The
protocol
may
have
a
source
IP
or
something
else
you
know,
and
the
protocol
may
have
multiple
legs.
So
maybe
the
message
goes
to
http
transverse
Kafka
and
moves
to
Kinesis
in
each
one
of
those
segments
will
be
a
different
source
destination,
IP
address
and
other
protocol
specific
semantics
topic,
names,
etcetera,
but
there's
only
one
source
to
the
message.
P
K
But
maybe
we
do
need
the
distinction
around
the
protocol
metadata
versus
the
message
metadata,
because
the
Pirkle
is
only
the
carrier
of
the
message,
so
the
Kafka,
you
know,
serve
source
topic
or
you
know
port
number
or
whatever.
You
know
it's
not
necessarily
for
the
message.
It's
part
of
the
transports
that
delivered
the
events
message.
N
C
So
I
think
what
I'm
hearing
is.
We
don't
necessarily
have
agreement
on
this.
Yet
all
right
that
actually
may
ask
more
pointed
question
so
tell
us,
would
you
object
to
changing
it
to
source
right
now
in
patch
it
with
a
potential
change
later
or
would
you
rather
have
some
more
offline
discussions?
First,
I
am.
P
I
Actually,
I
think
that
I
think
the
discussion
is
that
we
know
what
this
means.
It
means
the
thing
that
generated
the
event
and
we're
not
sure
what
to
call
it,
because
something
might
be
generating
an
event,
because
it
observed
something
that
happened
elsewhere,
but
we
still
want
to
know
who
generated
the
adventures
and
what
piece
of
software
was
like.
I
created.
This
bit
of
data
is.
K
Yeah
I'll
give
you
an
example
here:
let's
assume
we
have
an
API
gateway
that
have
a
survey
URL
and
grabs
a
function
is
the
source,
the
source
IP
of
the
guide
that
generated
HTTP
requests.
Where
is
the
source
so
the
path
resource?
You
know
what
you're
thinking
about
Amazon
API
gateway,
which
one
of
those
is
this
source
next
resource,
but.
I
Well,
I
think
it
depends
on
whether
that
the
angular
things
actually
created
a
cloud
event
or
whether
it
did
something
else
that
the
API
gateway
is
then
generating
an
event.
I
mean
it's
sort
of
semantics,
but
I
mean
do
you
think
at
some
point,
you're,
like
okay,
now
I'm
starting
to
use
cloud
events
versus.
K
I
I
O
N
Q
I
It's
like
a
different
thing,
which
of
course
can
manufacture
like
I
mean
we're.
Having
talked
about
like
security
like,
if
you
don't
know,
if
you're
not
have
a
secure
transport,
all
bets
are
off,
anybody
can
make
up
anything
right.
So
it's
like
what
how
much
you
trust
the
other
end
of
the
pipe.
Yes.
K
I
can
suggest
that
by
default
the
source
will
be
the
the
guy
deserves,
like
they
died
gateway
in
that
case
and
able
to
have
another
third
option
to
convey
metadata.
It's
original
source
like
the
host
name
in
the
case
of
HTTP
or
a
host
cookie
or
whatever,
but
essentially,
and
then
it
but
then
should
be
open
for
interpretation
that
may
you
may
be
creating
server
like
a
domain
name.
You
know
like
the
preference
will
be
they
be
I
gave
with
graphics
dot
something
else,
but
that
will
be
certain
open
to
its
limitation.
K
I
P
P
P
C
K
I
P
I
Yeah
I
think
they
would
be
interesting
to
see
a
proposal
around
that
you're
on
I
think
we
got
stuck
with
you
like
you
know
in
these,
in
these
cloud
environments,
where
everything
is
connected
to
everything
else
and
it
gets
hard
to
sort
of
figure
out
what
the
actual
source
is,
but
I'd
be
really
interested
in.
If
you
have
a
concept
that
you
think
would
really
work,
yeah.
K
You
know
you
think
about
it
in
many
cases
like
if
there
is
an
API
gateway,
it's
already
doing,
authentication
using
tokens
or
whatever,
and
then
it
served
can
inject
the
header
with
what's
the
identity
that
I've
authenticated,
so
the
backend
function
can
do
authorization
based
on
identity
that
insert
trust
different
guy
to
at
least
authenticate,
and
it
could
be
very
useful,
that's
something
we
do
but
and
we
really
need
it
for
a
bunch
of
applications
to
understand
who's
their
identity.
That's
issuing
this
event.
I
Yeah
we
do
something
similar,
so
we
just
couldn't
come
to
a
like
when
we
had
prior
conversations
before
this
came
to
github.
We
like
we
couldn't
come
to
like
a
crisp
definition
that
everybody
could
agree
to
so
like.
If
you
want
to
do
a
draft
of
something
and
then
people
can
chime
in
async
I
think
that'd
be
yeah.
K
C
That's
fine,
okay,
so
I
think
what
I'm
hearing
so
far
is
we
have
action
items
for
follow
on
either
changes
or
additional
properties
related
to
this,
but
I
think
I'm.
Hearing
more
people
are
ok
with
the
idea
of
at
least
changing
resource
to
source
for
now,
even
though
it
may
change
later.
Is
there
any
objection,
then,
with
moving
in
that
direction?
In
other
words,
is
there
any
objection
to
accepting
this
PR
as
it
stands
right,
I.
F
M
C
F
I
So
I
think
the
key
thing
is
I
saw
a
lot
of
questions
about
resource
that
were
like
completely
misinterpreting
what
we
were
trying
to
achieve,
and
so
that
was
the
you
know.
That
was
the
thing
right
where,
if
even
if
source
isn't
precise,
it's
more
in
the
direction
so
that
people
new
to
reading
the
spec
would
get
the
gist
of
it.
I
mean
that
said,
you
know,
like
I'm,
not
gonna
die
on
my
sword
on
this,
because
I
think
we
still
have
only.
F
K
R
F
K
And
it
may
be
that
you
know
the
path
within
s3
is
part
of
the
message.
Object
which
is
refer
refer
to
in
the
schema,
and
the
thing
that
is
the
source
is
actually
as
we
generated
and
event
telling
you
something
about
about
its
buckets.
That
would
make
more
sense
to
me
because
then
there's
a
lot
of
metadata,
which
is
the
event
or
region
specific,
and
that
will
probably
be
designed
into
the
schema
of
the
of
the
message
like
if
it's
a
DynamoDB
right
now,
then
you
have
a
previous
value
current.
C
Just
in
order
to
make
forward
progress
or
ease
I
don't
want
to
rattle
on
this
one
more
than
we
already
have
dan.
Is
your
concern
strong
enough
to
actually
to
rethink
like
a
formal
objection
to
where
the
point
where
you'd
you'd
ask
for
like
a
vote
on
this,
or
is
it
something
you
can
just
sort
of
hold
your
nose
on
I
mean.
I
C
That's
my
next
point
was
if
they,
if
he
does-
and
it's
perfectly
fine
dan,
if
you
do
I'm
not
trying
to
be
stronger
than
you
but
I
just
want
to
make
sure
cuz
I
don't
have
to
play
now.
I'm
gonna,
say:
okay.
If
someone
must
make
a
motion
to
formally
make
a
vote
on
this,
that's
fine!
Otherwise
I'm
gonna
defer
it
till
we
have.
You
know
either
next
week's
call
or
we
get
some
other
resolution
perfect
presented
to
us
as.
F
Long
as
as
long
as
we're
committed
to
making
a
vote
on
it
later
because
I
mean
the
whole
world
is
built
about
around
URLs
in
your
eyes,
and
no
one's
ever
been
confused
by
that.
So
the
thought
of
walking
away
from
something
that's
been
that
well
as
this
concerns
me.
So
if
we're
committed
to
voting
on
this
later
on
fine,
but
just
doing
whatever
we
want
today,
which
is
accepting
that
it's
just,
we
have
to
commit
to
actually
fall.
B
Or
not,
I
mean
I,
mean
I
agree
with
the
RI
approach
and
I
think
that
I
like
the
nomenclature
source
and
then,
as
you
saw
the
model
I
presented
back
at
her
face-to-face
in
November.
That's
basically
I've
distinguish
we're
always
dealing
with
multiple
resources.
In
terms
of
events
and
to
me,
if
you
adopt
the
source
terminology,
we
should
adopt
a
target
terminology,
so
the
event
always
has
a
source
and
a
target,
but
nothing
else.
C
P
C
C
Where
I
think
before
we
consider
really
something.
Thank
you
all
right.
Excellent!
Okay,
thank
you
guys
very
much
and
thank
you
guys
for
help
for
getting
through
those
six
issues
that
that's
that's
really
great
Austin.
This
has
been
lingering
I
think
maybe
for
two
weeks
now,
I
want
to
make
sure
we
talked
about
today,
since
you
put
on
the
agenda
two
weeks
ago
and
didn't
get
to
it.
H
Sure,
yes,
you
know
and
since
then
I'm
still
feeling
like
we're,
not
we're
not
quite
ready
to
start
talking
about
this,
but
the
the
topic
was
you
know
what
point
do
we
start
approaching
some
building
some
kind
of
tooling
to
help
support
the
specification,
so
people
can
start
using
it
today
and
integrating
it
with
other
projects
within
the
ecosystem.
I,
don't
think
we're
quite
quite
there
yet
so
I'm
fine
with
kind
of
deferring
this
conversation
topic
for
a
little
bit
further.
Okay,.
K
C
K
By
the
way
regarding
the
implementation,
we
can
take
a
stab
with
waiting
like
we
already
have
like
an
emulator
for
our
server
list.
I
can
take
the
emulator
and
I'm
create
a
tasting,
go
like
a
stub
to
generate
just
like
those
classes,
and
you
can
emulate
function,
calls
or
no
one.
Okay,
that
sounds
good.
All
right,
I.
H
S
C
Okay,
before
I
move
to
the
next
item,
just
wondered
my
people.
If
you
have
not
done
so
already
check
and
make
sure
your
name
is
in
the
attendee
list,
the
beginning
of
the
gender
doc,
because
we
we
will
try
to
do
the
roll
call
again
for
late
comers.
But
if
your
name
isn't
there
I'm
gonna
forget
to
call
on
you
now.
C
H
C
One
well
I
was
looking
through
this
or
considering
this
earlier
today.
I
realized
that
it
seems
like
most
of
the
proposals
that
people
are
going
to
suggest
for
future
work.
Items
are
probably
going
to
either
expand
the
scope
of
our
working
group
of
the
specification
or
potentially
kick
off
a
brand
new
working
group,
and
if
that's
the
case,
I'm
thinking,
maybe
we
should
do
is
aside
from
maybe
people
adding
things
of
that
work
out
unless
they
want.
C
But
what
it
really
should
do
is
open
up
a
proposal
in
the
WG
serverless
working
group
directory,
because
we
haven't
direct
with
our
cup
proposals.
You
made
people
should
put
their
roles
in
there
and
hash
out.
You
know
or
work
for
through
discussions,
other
people
to
formalize
proposal
and
then
when
they
feel
like
it's
ready
enough
and
solid
enough,
then
they
could
bring
it
to
this
group
on
a
weekly
call
for
us
to
consider
it
because
I
don't
think
we
want
to
necessarily
get
into
the
brainstorming
session
on
this
call
itself.
C
But
at
least
then,
if
you
have
a
doc
in
the
repo
someplace,
then
people
can
hash
on
that
repo
there
or
you
know
inside
there,
put
a
pointer
to
a
Google
Doc,
whoever
you
guys
want
to
work,
but
overall
I
was
wondering
whether
we
should
just
use
the
proposals
during
the
original
repo
as
the
way
to
sort
of
get
those
conversations
going.
What
do
you
guys
think
sounds
good
to
me
great.
I
C
I
C
I
C
M
I'm
thinking
about
you
know,
I'm
working
on
proposing,
oh,
like
somebody's
application
model,
I'm
sure
I
start
like
on
a
Google
Doc
should
I
start
start
on
this
github.
C
Anyway,
why
don't
you
wait
until
I
get
that
process
to
find
a
little
more
recent?
That
way,
everybody
follows
the
same
pattern
and
chances
are
it's
gonna
be
kind
of
similar
where
I
described
here,
which
is
either
open
up
an
issue
or
open
up
or
request
at
a
document
proposal
der
in
our
in
our
original
git
repo,
the
service
repo.
But
let
me
work
on
the
details,
and
hopefully
before
next
week,
we'll
have
that
in
place,
and
then
you
can
just
follow
those
debts.
You
can
follow
that
process.
Does
that
sound?
Okay,
okay,.
C
K
C
I
So
I
made
a
very
simple
presentation
that
just
defines
a
few
simple
terms
that
if
we
could
just
agree
on
what
terms
we
want
to
use,
then
that
would
help
draw
a
bigger
diagram
which
I
think
then
we
could,
then
that
would
help
us
all
be
like.
Are
we
talking
about
the
same
thing
and
and
get
somewhere?
So
the
first
part
of
this
comes
from
the
spec
itself.
Right
like
that,
we
that
the
event
is
commonly
used
colloquially
to
mean
the
data.
That
represents
the
thing
that
happened.
I
So
this
was,
you,
know,
sort
of
prior
to
getting
us
into
github,
who
said
well,
there's
an
occurrence,
which
is
the
thing
that
happened
and
then
there's
the
event,
which
is
this
specification
and
and
so
and
then
sort
of
like
I
decide.
I
talk
about
like
some
of
the
use
cases
which
are
there's
a
lot
of
stuff
around.
I
Like
you
know,
somebody
makes
an
HP
or
RPC
call
and
that
changes
some
state
on
the
server
which
generates
one
of
these
events,
or
you
know,
there's
also
been
a
lot
of
conversations
about
like
the
IOT
sensor,
so
situation,
and
we
also
wanted
to
call
out
that,
like
it
could
be
a
non-event
right,
it
could
be
time
passing
with
something
not
happening.
All
of
these
things
are
in
scope
and
that
and
that
some
of
the
stuff
that
the
spec
discusses
is
there's
like
sort
of
context
and
data.
I
But
the
idea
is
that,
like
every
occurrence
is
uniquely
identified
that
it
should
be,
it
describes
the
event.
So
that's
really
just
a
preamble
that
covers
what
the
spec
isn't.
But
what
looked
in
the
spec
for
the
new
terms,
which
I
pulled
the
source
term
from
the
change
that
I
liked
right
that,
but
this
is
like,
but
then
I
think
you
couldn't
talk
about
it
with
like
what
it
what
happens
after
they
like
there's
another
side
of
it
right
which
is
outside
of
the
scope
of
the
current
spec.
I
So
the
way
that
the
current
spec
is
written
is
that
there's
this
event
that
then
using
things
that
we
have
not
diagrammed
yet
can
be
bound
to
use
the
word
action
from
open
Wisc.
You
know
Amazon
calls
his
handler.
Everybody
calls
these
things
different
things,
but
I
thought
action
was
like
sort
of
a
nice
generic
term
for
like
what
you
like.
There's
the
the
events
that
are
emitted
or
generated,
and
then
there's
another
thing
that
the
developer,
who
is
not
the
developer
of
the
source
and
may
not
even
be
the
developer
of
the
action?
I
So
I
just
wanted
to
propose,
like
are
these
words
that
are
good.
Is
this
a
reasonable
sort
of
description
of
how
we're
doing
things
and
then
on
also
acknowledging
that,
like
a
we're,
all
agreeing
that
this
specification
currently
doesn't
cover
a
protocol
where
the
event
is
transmitted
and
there's
like
a
whole
bunch
of
requirements
that
are
currently
like
sort
of
outside
of
the
spec,
so
I
wanted
to
sort
of
first
ask:
like?
Does
everybody
agree?
This
is
the
model.
I
K
P
And
then
to
expand
on
that
point,
the
other
one
that
I
think
Sarah
was
trying
to
make
is
that
the
source
also
doesn't
care
about
the
action
that
one
of
the
power
of
plot
events
is
that
you
can
have
these
lead
loosely
coupled
systems.
You
can
expose
the
ability
to
observe
the
currents
without
knowing
every
consumer
of
your
action.
C
So
Sarah
in
terms
of
next
steps
on
this
I
want
to
make
sure
that,
as
we
go
forward
on
something
like
this,
what
to
think
is
great
that
we
don't
necessarily
have
to
worry
about
keeping
two
documents
in
sync
or
them.
Getting
out
of
sync
is
more
than
worried.
How
do
you?
What
do
you
want
us
to
do
in
the
short
term
on
this?
Is
it
just
to
make
sure
the
spec
is
the
right
terminology,
so
you
can
echo
them
properly
in
this
stock
that
you're
producing
or
what
do
you?
I
I
actually
went
ahead
and
based
on
the
conversation
in
the
issue
and
made
a
markdown
version
of
this,
so
that
if
we
so
if
you
could
look
at
the
markdown
thing
so
that
it's
easy,
that
if
we
change
the
terms
of
the
spec,
we
just
like
it's
in
text
rather
than
in
I
mean
it's
also
in
I.
Don't
I'll
have
to
think
about,
like
somebody
would
like
this
picture.
I
don't
know
how
to
do
pictures
and
work
down
very
effectively,
so
it
has
a
ping
in
it
right.
I
I
I
The
goal
is
just
so
that,
if
somebody
is
coming
to
this
fresh
write,
they're
like
oh
god,
events
I
really
want
to
do
something
that
has
nothing
to
do
with
what
we're
doing,
because
they
do
something
that
they
call
with
the
word
event
that
they
could
like
read
it
in
for
talking
be
like.
Oh,
that's,
not
what
we're
doing.
Okay,
I'm
gonna
go
away
or
like
okay
I
understand.
The
context
is
now
I'm
gonna
dive
into
this
back
so.
C
C
You
pointed
to
the
spec
and
then
the
rest
of
it
is
just
prose
that
talked
about
those
concepts
without
actually
trying
to
define
it,
because
I
get
a
little
nervous
when
I
see
things
like
event,
:
and
then
a
definition
of
it,
because
that's
asking
for
things
to
get
out
of
sync
and
then
PRS
to
get
them
back
in
sync,
and
it's
just
gonna
be
a
maintenance
nightmare.
But
it's
talking
about
things
in
abstract
sense.
The
way
you
described
it
I
think
that
makes
perfect
sense.
So
we
look
at
the
sense
of
the
bigger
picture.
C
C
I
We
were
thinking
that
the
other
action
item
I
have
but
I
didn't
get
to
is
to
take
the
references
out
of
the
spec
that
are
like
the
like.
The
things
that
are
the
current
events,
like
the
the
cloud
event
like
things
that
Amazon
and
Google
and
others
like
started
like
we're
feeders
into
this,
and
so
the
idea
is
I.
Just
came
up
with
this
directory
name
about
to
be
like
this
is
where
we
can
like
put
stuff.
I
That
is
the
context
for
this
I
mean
this
could
go
in
the
readme,
but
I
think
it
would
be
better
to
link
it
from
the
readme
so
that
we
can
also
link
things
like
I.
Think
Rachel
last
week
suggested
that
we
have
like
a
table
of
contents
and
the
readme,
so
it
would
be
like
a
link
to
the
concepts
and
a
link
to
the
how
to
start.
You
know
how
to
contribute
and
the
working
group
meetings.
Sure.
H
C
G
I
I
think
that's
a
good
point.
I
think
the
to
clarify
what
I
think
I
mean
and
hysteric.
C
Yes,
thank
you.
I
don't
mean
to
cut
us
off,
but
I
do
want
to
get
the
roll
call
back.
My
circular
attendant
or
marked
down
appropriately.
We
are
out
of
time.
I
want
to
be
respectful
people,
but
Ben,
please
if
we
don't
get
it
covered,
bring
it
up
next
week.
So
let
me
just
quickly
go
through
the
roll
call
again
Joe
Scherman
from
Microsoft
to
you
here.