►
From YouTube: CNCF Serverless WG Meeting - 2018-03-23
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
E
Let's,
while
we
wait
for
people
to
come,
I'm
just
I'll
just
add
to
the
attendees,
oh
I
see
you're
here.
E
A
A
E
Don't
know
why
this
is
not
I
can
fix
it
up
later,
but
what
I
attempted
to
do
this
morning?
But
it's
not
in
this
pull
request-
is
to
just
have
this
be
the
consumer
and
the
producer
and
then
separately
talk
about
the
framework
of
the
middleware
and
see
if
we
can
get
further
on
that
and
and
then
do
that
as
a
separate
PR.
So
at
worst
case
we'll
have
the
consumer
and
the
producer
established,
and
then
we
can
talk
about
the
other
things.
Does
that
make
sense
yeah.
B
C
Sarah
one
of
the
one
of
the
concerns
I
have
is
that
I've
heard
from
Clemens
that
Microsoft
is
not
in
favor
of
pulling
it
out,
mainly
because
they
believe
that
removing
the
middleware
stuff
basically
ignores
their
requirements,
and
so
I'm
wondering
whether
it
would
be
useful
to
rather
than
looking
to
split
this
time,
if
we
couldn't
focus
on
seeing
if
we
can
come
up
with
concrete
textual
changes
to
the
current
PR.
That
would
get
every
way
to
the
point
where
they
say.
Yes,
it's
good
enough
when
we
can
move
forward.
E
H
E
C
I
thought
I.
Don't
think
anybody
would
question
that
I
would
just
rather
it
just
seemed
like
we
were
I
got
the
feeling,
based
on
the
many
discussions
we've
had
this
week,
that
we
were
fairly
close
to
agreement
on
Clements
PR
and
that
if
we
could
just
get
some
minor
wording
changes,
we
may
be
able
to
get
over
that
threshold
of
saying.
Yes,
it's
good
enough
and
we
can
move
on
all.
E
Right
so
let's
talk
about
it,
so
I
think
they
I
thought
we
were
very
close
on
Clements
PR,
but
then
I
was
surprised
at
the
implication
that
this
would
require
topics
in
the
definition
of
the
event,
and
we
had
talked
about
in
the
past
that
there
were
several
architectures
which
had
a
higher
level
of
abstraction
on
top
of
topics.
For
you
know,
Google
has
trigger
specifications
where
you
can
specify
a
filter
and
I
think
that
nucleo
also
has
a
similar
are
textured.
C
So
my
interpretation
of
all
the
text
are
putting
in
there
is
not
to
force
us
to
define
what's
in
the
spec
at
this
time,
they
are
simply
there
to
explain
some
of
the
some
of
the
thoughts
that
I've
been
running
through
our
heads
in
terms
of
what
the
use
cases
we'd
like
to
try
to
support,
I,
don't
believe,
there's
anything
in
there
that
mandates.
We
will
have
a
topic
I.
Think
that's
a
discussion
for
later.
When
someone
extra
proposes,
we
add
a
fee
attribute
called
topic
so.
C
E
I
think
that
that
so
basically
there's
the
middleware
routes,
events
from
producers
to
consumers
or
onwards,
so
the
middleware
applications
might
delegate
certain
tasks
from
consumers
requirements
to
the
middleware,
and
then
it
says
that
to
satisfy
these
needs
I'm.
Sorry,
the
middleware
is
interested
in
these
metadata
discriminators.
E
C
E
What
I'm
trying
to
understand
is
how,
and
maybe
there
are
some
people
on
the
call
who
have
topic-based
systems
who
could
speak
to
how
I'm
trying
to
understand
how
this
description
got
us
to?
We
need
topics,
and
so
I
feel
like
they're
or
I,
and
what
I'm
trying
to
address
is
this
continued
method
of
confusion?
I
Sara
I,
don't
think
anything
in
here
actually
denotes.
So
this
was
based
off
pull
117.
Is
that
correct,
yeah
I
think
the
the
source
of
confusion?
Maybe
that
happened
yesterday
was
the
pull
request
that
you
Rachel
Klaus,
had
a
fair
amount
of
pushback
on
was
actually
95.
This
pull
request
hasn't
changed
from
the
standpoint
of
defining
like
a
producer,
a
consumer
middleware
framework.
If
you
search
for
the
word
topic,
I'm
relatively
certain,
it's
nowhere
and.
E
I
That's
why
I
just
wanted
to
say
there's
to
me
a
little
bit
of
a
decoupling
here
from
Desai
defining
kind
of
the
high
level
persona
roles
right
that
we
talked
about
versus.
Do
these
actually
force
us
into
having
you
know,
topic
be
one
of
the
required
metadata
fields
on
the
event
envelope
that
to
me
was
kind
of.
There
was
a
little
bit
of
ambiguity
as
to
whether
or
not
while
we
were
talking
about
95
or
117,
so.
E
I'm
talking
about
I
thought
that
on
Monday
and
Tuesday
we
were
getting
to
conversion,
and
then
there
were
a
whole
bunch
of
questions
that
I
didn't
anticipate.
So
so
I
think
that
you
know
folks
feel
that
I
mean
these
metadata.
Discriminators
are
really
purely
about
the
event
itself,
as
given
by
the
examples,
and
then
the
the
wording
was
changed
here
so
that
it
it's
clear
that
the
the.
I
Absolutely
right,
like
the
ultimately
to
me,
the
producer
doesn't
define
where
the
message
is
going
right.
This
is
not
a
point-to-point
system.
This
is
purely
a
like
a
and
in
a
mutable
point
in
time.
Observation
was
taken
all
of
a
thing
right
and
I'm
gonna
make
people
aware
of
it,
make
others
aware
of
it
right
and
that
that's
so
in
that
I
think
kind
of
segues
into
the
idea,
which
is
when
we
had
the
idea
of
so
again
like
I,
don't
want
to
confuse
95
with
117
or
now
what
is
122.
I
But
the
idea
then
was
there
was
some
confusion
around
the
word
source
and
I
think
we
should
scope
that
source
versus
topic
was
brought
up
on,
but
again,
I
think
that
is
a
totally
separate
piece
of
the
conversation
related
to
pull
95
I.
Think
117
really
just
defines
the
high
level
act,
not
even
act.
There
is
high
level
kind
of
personas
yeah.
I
I,
don't
personally
have
any
like
one
way
or
the
other.
It
doesn't
matter
to
me:
okay,
if
it's
122
or
117
I,
think
at
the
end
of
the
day
like
if
we
settle
on
a
you,
know
the
correct
set
of
words
that
we
believe
convey
the
the
personas.
It
means
very
little
to
me
which,
which
pull
request
got
merged
no.
C
B
E
A
C
A
J
C
B
B
A
E
C
I
think
so,
look
at
me.
This
is
my
point
of
view,
but
it
seems
to
me
when
we
start
getting
into
saying
what
can
and
can't
happen
in
middleware
and
stuff,
like
that,
it's
sort
of
out
of
scope
for
us
right
we're,
defining
an
event
format.
What
happens
before
and
after
the
events
is
sort
of
manifested
it
to
be
comply
with
our
spec.
It's
sort
of
out
of
scope
for
us,
so
I'm
not
really
sure
it's
appropriate
for
us
to
say
what
middleware
does
or
does
not
do.
E
The
definition,
so
this
is
the
I
think
it's
really
important
to
get
this
right,
because
this
has
been
the
confusion
of
discussions.
I
believe
the
intent
of
this
pull
request
is
that
if
middleware
were
to
change
the
semantics
of
the
event,
it
then
becomes
a
producer.
It
is
no
longer
middleware
as
we're
agreeing
on
the
terms
here.
What.
B
My
point
was
just
that
I
like
I'm,
okay,
with
like
I,
want
us
to
get
alignment
like
the
goal
of
this
document,
for
me,
is
that
we
should
understand
each
other's
use
cases
and
we
should
agree
on
what
the
terms
mean
and
so
I'm
just
trying
to
get
to
like
I
just
want
to
know
what
we
mean
when
we
submitted
like
not
trying
to
I'm,
not
trying
to
be
prescriptive.
I
want
to
understand
what
people
mean
and
it
feels
like.
That's
not
like.
We
haven't
aligned
there.
Yes,.
E
C
Let
me
finish:
I,
don't
think
it
matters,
because
ultimately,
someone
is
going
to
produce
to
be
producing
an
event,
I,
don't
care
who
that
is
as
long
as
the
person
producing
the
events
puts
the
right
information
in
the
right
spot.
I,
don't
think
it
makes
difference
whether
they
think
of
themselves
as
a
producer,
a
middleware,
a
framework
or
anything
else.
As
long
as
they
put
the
great
data
in
the
right
spots,
you
think
of
themselves
any
way
they
want.
I
think.
B
So
I
think
there
their
implications
of
this.
That,
like
it's,
not
it's
not
just
wordsmithing
like
like
Clemens
last
comment
is,
and
this
is
why
source
is
the
wrong
attribute,
so
I
think
a
lot
of
people
are
reading
more
into
this.
Like
people
like
it's
like
aligning
worldviews,
and
then
from
that
we
can
write
a
spec
I.
Would.
I
Actually
echo
that
sentiment
as
well
right
like
when
you
open
the
door
to
say
I,
as
you
know,
quote
unquote,
middleware
can
say
I'm
gonna
change,
parameters
on
the
event
it
is
now
the
job
of
the
consumer
to
detangle
like
well.
Was
this
just
the
routing
of
the
event
versus
the
actual
initial
emission
of
the
event
right
I
think
you
opened
the
door
for
a
lot
of
ambiguity.
I
Middleware
is
purely
observational
as
I
think
what
we're
going
for
in
this
case
and
I
think
that's
what
you're
advocating
for
Sarah
and
as
well,
which
is
the
idea
that,
if
you're
going
to
change
something
about
an
event
in
any
capacity
right
like
you,
have
ultimately
not
you're,
not
mill
where
anymore
right
and
that's
what
we're
trying
to
define.
Middleware
is
specifically
the
like
a
Kafka
broker
or
a
mesh
network
that
is
literally
just
forwarding
packets
right.
I
Those
are
the
sorts
of
things
that
were
saying
like
if
I
don't
some
even
chain
go
so
far
as
to
change
source
right.
The
source
of
the
event
was
a
sensor
but
I'm
an
API
gateway.
So
there's
there's
some
ambiguity
there
as
to
okay.
Now
do
I
change
the
source
on
the
event
to
say
that
it's
coming
from
me
versus
it's
coming
from
you
know
the
original
sensor
that
was
I,
think
Clemens
intent
with
that
I
think.
I
B
Yeah,
that's
what
I
would
have
expected
and
then
that's
not
what
seems
to
be
happening
in
the
conversation,
so
like
I
think
we
should
just
like
we
need
to.
We
need
to
like
decide
on
that
one
and
then
I
think
this,
like
that,
like
that's,
why
I'm
being
concerned
with
this
with
the
usage
scenarios
and
after
after
we
like
have
agreement
there,
I
would
like
I
think
it's
probably
good
to
go
for
me.
I
think.
B
B
E
F
You
know
at
at
this
time
you
know
I
do
think
we
have
a
handful
of
features
that
we'd
like
to
implement
that
we've
heard
from
users
that
that
do
transformations
on
the
events
structure,
but
again
don't
change
the
semantic
integrity
of
the
event
and
I.
Think
that
that's
that's
a
pretty
good
rule
that
that
we
personally
like
to
be
able
to
be
able
to
do
that.
I
am
pretty
hesitant
to
get
super
prescriptive
about
this
actually
at
this
time,
because
it's
it
is
so
early.
C
C
I
think
the
way
that
decision
would
manifest
itself
would
be
to
propose
a
change
to
the
specification
itself
relative
to
the
attributes
that
we
have
right,
because
if
someone
says
well,
I
need
to
have
additional
information
beyond
the
original
source
ID
or
whatever
they
they're
talking
about
right,
then
they're
going
to
advocate
for
potentially,
and
you
active
you
to
be
added
and
they're
going
to
have
to
make
a
case
for
why
that
used
to
get
at
it
and
I.
Think
that's
the
best
way
to
resolve
these
kind
of
discussions
is
by
saying,
okay.
C
How
would
we
resolve
your
particularly
use
case?
Can
you
do
it
with
the
existing
stuff
to
be?
They
had
something
or
change
something
I'm,
not
sure,
as
called
to
saying
I'm
sorry,
Dawson
I'm
saying
is
being
that
prescriptive
just
in
defining
the
scenario
is
that
you
know
guided
our
thought
process.
I,
don't
think,
is
necessarily
that's
productive.
Is
it
yes,
people
some
people
think
it
is
that.
B
C
E
Let's
just
pause
on
that
for
a
sec
I
want
to
address
the
question
that
Doug
raised,
which
was
why
you
know.
Why
is
this
important
and
what
I
want
to
call
back
to
is
the
many
discussions
of
what
is
source
right
like
where,
if
we
can
agree
that
the
middleware
that,
like
whatever
the
source,
except
for
like
format
and
encoding,
the
sources
meted
whatever
context
it
provides,
is
immutable,
then
I
think
that
that
does
move
the
conversation
forward.
I
Like
I
completely
agree
with
this
line
of
thought
right
like
you've,
you've
added
puppet
master
or
something
right,
like
I'm
I'm,
now
going
to
look
at
events
and
decide
whether
or
not
they
need
to
be
mangled.
If
anything,
you
can
relegate
the
scope
of
what
middleware
is
allowed
to
change
to
our
extensions
right.
The
actual
envelope
as
it
was
initially
created
is
immutable,
and
but
we
allow
for
extension,
right
and
and
to
go
so
far
as
say.
The
data
payload
is
also
immutable.
I
I
In
his
comments,
I
mean
that's.
This
is
sort
of
the
the
compromise
I'm
tempting
to
propose
between
the
two
right,
which
is
you
know
there.
There
has
to
be
some
notion
of
you
know.
Event
was
produced
middle
we're
really
keen
on
reaching
and
Mangala,
except
to
add
context
that
potentially
indicates
to
someone
that
you
know
it
an
event
hopped
along
a
route
to
get
to
where
it's
going.
A
A
I
Actually
argue
that
that
sentence
is
incorrect
in
in
part,
one
I
think
if
you
are
constructing
the
event,
you
are
the
effective
producer
on
behalf
of
right,
the
context
in
which
an
event
took
place.
This
was
a
similar
question.
I
was
thinking
of
it
from
an
IOT
perspective,
right
like
where
I
have
access
to
like
12
bits.
I
can
you
know,
raise
or
lower
and
ultimately
like
I
and
a
gateway
is
going
to
say.
I
Oh,
like
this
bit
was
lowered,
means
low
battery
right
you're
producing
the
event
in
the
on
the
context
there
on
behalf
of
right,
like
the
actual
sensor
or
the
actual
weather
station,
or
something
along
those
lines
to
me,
I
think
this
paragraph
should
be
rewritten
based
on
the
discussions
we
had
this
week.
Well,.
A
Again,
you
know
we're
trying
to
put
words
into
Clemens
in
terms
of
what
he
meant
here
but
I,
if,
if
he
was
deriving
a
lot
of
meaning
within
that
middleware
role
based
on
this
transformation
between
that
original
producer,
that
may
not
produce
cloud
events
and
then
the
Gateway
producing
the
cloud
event.
That
might
be
part
of
the
confusion.
A
I
A
F
You
know
one
thing
I'm
worried
about
with
us
being
so
prescriptive
here
in
this
language
is
we're
gonna
preclude
our
ability
to
be
able
to
listen
to
the
market
and
now
the
way
our
middleware
implementation
is
going
to
work
is
that
users
are
configuring
everything
so
so
nothing
is
gonna
happen
by
surprise.
They're
gonna
be
able
to
configure
exactly
how
events
are
treated
and
converted
or
if
they're
transformed
within
our
gateway.
F
We
want
to
make
sure
that
we
we
do
give
them
some
level
of
flexibility
there,
because
we
also
because
we
want
to
enable
our
system
to
kind
of
listen
to
users
and
be
able
to
accommodate
a
lot
of
functionality.
So
all
this
stuff,
anything
that
happens
within
the
middleware.
You
know
we
we'd
like
to
do
a
lot
of
experimentation
in
that
area
and
again
it's
going
to
be
configurable
completely
by
the
user,
so
nothing
will
be
will
be
happening
by
surprise.
B
I
A
fair
point
to
Austin
can
I
ask
a
kind
of
dumb
question
just
given
come
my
context.
Is
your
intent
to
supply
sort
of
like
ETL
ish
type
workloads
like
saying
like
we
will
consume
events,
transform
them
or
perform
aggregations
or
projections
and
then
potentially
persist
them
somewhere
else.
F
That
is
something
that
we're
considering
we're
to
be
honest,
we're
considering
a
lot
of
things
within
the
middleware
sure
it
is
beautiful
her.
It
is
gonna
blur
the
lines
between
a
lot
of
the
things
we're
talking
about
here.
I
would.
I
Actually
argue
you
take
on
all
three
personas
in
that
respect
like
if
I
wanted
to
use
you
to
simply
route
from
A
to
B.
Without
touching
the
event,
you
would
support
that
I
assume
immediately
and
in
that
case,
you're
purely
male,
where
in
the
case
where
you're
consuming
events,
you
know
altering
them
significantly
or
in
significantly
and
then
producing
new
events
you're
effectively.
You
know
consumer
transport
and
producer
right.
We're
transport
in
this
particular
instance.
I
A
Mean
I
think
it
goes
without
saying
that
we're
all
wanting
integrity
within
data
integrity
within
all
of
these
messages,
as
we
transform
them
or
move
them
along
the
pipeline.
But
at
the
end
of
the
day
you
know
there
there
will
be
changes
made
depending
on
what
the
source
is
and
what
the
destination
is.
E
I
think
wow.
You
say
that
so
what
I'm
suggesting
is
that
what
we're
doing
is
we're
helping
our
conversations,
we're
saying
if
you're
in
Rolex,
you
cannot
do
that.
Therefore,
you
have
to
describe
yourself
as
role
why,
in
order
to
have
the
conversation,
be
more
effective.
So
if
we
say
that
so
one
approach
is
to
say
that
the
in
this
weather
station
example,
it's
decides
whether
it
is
the
producer
or
an
int
or
middleware,
and
if
it
wants
to
construct
required
mated
metadata,
then
we
refer
to
it
as
the
producer.
E
C
E
Suggesting
that
we
have
a
common
language
for
describing
the
roles
based
on
what
they
do,
and
anybody
can
do
anything
and
if
they
do
a
certain
set
of
things,
we
describe
them
as
a
producer.
If
they
do
a
certain
set
of
other
things,
we
describe
them
as
middleware
and
it
will
help
us
in
our
conversations.
I
I
J
I
H
C
To
hear
the
mean,
let
me
finish
the
reason
I
say
no
is
because
everybody
is
going
to
have
their
own
point
of
view
in
terms
of
what's
important
and
what's
not
and
everybody
will
come
to
the
table
with
their
own
perspective
and
when
you
argue
for
or
against
a
particular
team,
the
specification
you
will
present
your
point
of
view
relative
to
that
particular
change.
And
that's
all
it
really
matters
right.
E
We
can
also
adjust
this
language
if
needed,
and
we've
already
already
said
that
this
language
isn't
normative.
What
what
I'm
trying
to
do
is
to
move
us
forward
in
when
we
say
middleware.
What
do
we
mean
when
we
say
producer?
What
do
we
mean
so
that,
because
we've
had
this
many
times,
we've
had
the
API
gateway
conversation
and
many
times,
and
we've
had
new
people
come
on
board
and
have
the
same
conversation
again.
We're
generally
I
think
there
is
agreement
that
there
is
a
common.
E
The
meaning
of
the
event
is
a
useful
concept
in
our
conversations,
and
so
that's
kind
of
what
I'm
trying
to
get
at
is
that
when
somebody
says
I'm
middleware
that
we
know
what
concerns
were
bucketing
in
there
or
we
can
say,
we
call
that
you're
in
the
producer
role.
Great
now
tell
us
all
your
concerns
and
so
that
we
have
that
shared
language
for
light,
because
we
have
different
architectures
I.
F
Think
this
is
a
helpful
exercise
getting
out
getting
aligned
on
a
shared
language
is,
it
sounds
like
a
small
thing,
but
it
is.
It
is
so
important
to
enhance
collaboration
and
I
think
that
what
we
have
here
is
it's
pretty
good.
It's
also
going
to
help
newcomers
come
and
understand
this
better
and
navigate
the
ambiguous
world
of
events,
so
I
think
there's
definitely
value
created
here.
At
the
same
time,
certainly
hearing
a
lot
of
folks
get
more
and
more
antsy
to
just
go
back
to
the
attributes,
discussion
and
focus
on
that.
F
B
I
think
one
thing
that
would
be
really
great
like
one
thing
that's
been
really
clarifying
for
me
in
this
conversation,
is
that
we
see
middleware
is
being
able
to
assume
any
of
the
three
roles.
It
could
be
flat,
middleware
producer
or
consumer,
and
we
could
include
that
I
think
that
would
be
very
clarifying
like
it
could
be
one
sentence
in
Section
three
at
the
top
of
section
three
or
more:
maybe
it
just
goes
at
the
top
or
the
bottom
I.
Don't
know
it
could
go
in
several
places,
but
that's
a
important.
B
C
C
I
E
C
All
right
with
only
but
eighty
minutes,
that's
on
the
call
I
prefer
that
we
get
to
the
point
where
by
what
would
be
the
deadline
you
know
Tuesday
morning
or
whatever
it
is
Monday
night
that
people
have
made
the
exact
textual
changes,
they'd
like
to
see
in
the
spec
and
then
I
can
quickly
run
it
by
Microsoft
to
see
if
they
have
any
objection
to
it
going
to
their
PR
because
technically
is
their
PR
and
if
not,
we
can
get
it
added
in
and
vote
on.
This
thing
really
quickly.
I.
E
E
E
Thank
you,
I
wanna.
There
was
a
question
that
was
raised
in
yesterday's
conversation
that
wasn't
answered,
which
is
why
do
we
have
a
separate
framework
section
when
we've
already
said
that
there
are,
there
was
like
I
think
it
was
Kathy
who
was
saying
that
in
the
producer
there
were
multiple
roles
right,
there's
a
service
platform
or
you
know,
there's
a
platform,
the
application
developer
and
those
were
collapsed
into
one
role,
and
so
there
was
the
open
question
of.
E
F
Little
depends
on
your
definition
of
framework.
Of
course,
you
know
we
have
a
framework,
that's
a
developer
tool
for
provisioning,
all
the
configuration
all
the
infrastructure
or
wiring
these
things
up,
so
that
they
work
together
and
that's
that's
what
our
definition
of
framework
is
and
that
certainly
that's,
certainly
a
different.
A
different
role
in
the
middle
layer
and
it's
a
bit
of
an
ambiguous
role
to
it
could
be,
could
be
a
lot
of
things.
E
E
They're,
either
consumer
or
producer
like
they,
they
fit
into
the
other
roles.
I
think
our
in
our
case,
their
consumer
needs
right
because
we
have
a
consumer
framework
and
I.
Don't
know
whether
your
frameworks
are
producer,
consumer
framework
but
I,
it
feels
like
they
might
fall
into
one
of
the
other
three
roles:
okay,.
B
E
And
just
to
tell
you
my
perspective
on
this,
it
seems
that
this,
the
sort
of
this
metadata
commonality
is
really
detailed.
In
you
know,
there
was
a
some
in
this
metadata
discriminator
up
here
for
like
aggregation,
so
Kathy
was
pretty
vocal
about
this
need
for
classification
right,
which
and
I
think
that
many
of
our
systems
need
which
led
to
that
pretty
precise
description,
which
I
think
I
just
like
to
aggregate
the
same
concerns
in
one
piece
of
area
of
text,
if
appropriate,.
F
H
Can
hear
me
so
one
aspect
that
might
be
important
for
the
spec
or
I
think
it
is
important,
is
the
interoperability
so
especially
for
the
frameworks
Austin
I
think
developed,
so
they
they
need
to
be
able
to
run
in
in
different
infrastructures
and
therefore
may
also
rely
a
bit
more
on
D
and
this
aspect
as
the
other
roles.
H
So
I
could
also
imagine
to
have
another
PR
later
on.
Maybe
elaborating
a
bit
more
on
this
interoperability
I
think
that's!
That's
the
core
goal
of
this.
The
whole
specification
so
far,
the
description
of
the
roles
mainly
describes
eventing
cases,
but
doesn't
mention
this
interoperability.
It
is
not
explicitly
I.
E
E
H
It
just
stepped
over
this
aspect
when
thinking
more
and
more
about
this.
This
topic
question,
because
in
that
case
you
would
need
to
maintain
a
topic
hierarchy
and
structure
and
that's
typically
done
inside
one
organization.
But
if
events
leave
one
organization
are
consumed
by
some
other
one
that
gets
more
difficult
and
then
that
way,
I
stepped
over
this
interoperability.
F
I
E
So
great,
thank
you,
and
that
is.
E
Is
this
sufficient
to
clarify
the
scope
of
what
we're
doing
I
added
another
issue,
because
what
I,
what
I'm
trying
to
do
is
when
we
get
into
discussion
of
the
attributes
which
I'm
dying
to
do
really
that
we're?
We
can
have
really
fruitful
conversations
about
what
we're
doing
and
not
get
into.
Oh,
you
know
like
confusion
about
what
what
we're
doing
we
can
we
can.
I
Think
we're
there
and
I
think
beginning.
The
conversation
related
to
attributes
will
most
certainly
help
us
find
efficiencies
right,
like
I
think
we
just
have
to
be
open
to
the
idea
that
we
will
revisit
the
personas
and
clarify
as
necessary,
but
from
a
baseline
perspective.
I
think
this
is
a
reasonable
place
to
begin
the
conversation
I.
F
Think
so
too
I
think
we've
got
our
roadmap,
which
provided
a
lot
of
clarity.
We
have
our
design
goals,
you
have
you
should
scenarios
all.
This
should
help
increase
our
focus,
and
this
also,
this
just
helps
any
any
newcomers
come
and
contribute
to.
The
effort
really
understand,
what's
going
on
which
I
also
appreciate,
because
that
whole
the
whole
journey
is
important.
C
H
The
clock
messages
question
came
from
me
and
it
was
in
this
discussion
about
topics.
So
I
was
just
imagining
this
PR
o95
goes
through.
Then
you
would
have
attributes
for
topic,
subjects,
I,
think
event
ID
times
them,
and
if
you
replace
the
term
event
and
these
attribute
names,
then
you
would
just
have
a
message:
header,
not
not
nothing
specific
for
event.
So
that
was
my
concern.
When
I
asked
that
question
right.
C
H
F
E
B
E
C
G
E
C
I
So
we
are,
we
getting
close,
so
I
think
that's
the
the
last
point
I
wanted
to
make
to
Austin.
Is
there
a
time
box
for
the
final
set
of
you
know
comments
to
be
included
that
Doug
should
bring
into
this
specific
or
the
pull
request
right,
whether
it's
117
or
122?
Let's
decide
right
now
and
then.