►
From YouTube: CNCF Serverless Working Group 2020-10-22
Description
CNCF Serverless Working Group 2020-10-22
C
B
D
B
B
Yes,
well,
I
call
it
la
la
land.
So
yes,
yeah.
B
If
you
think
about
the
the
the
most
extreme
people
and
like
on
the
left
versus
the
extreme
on
the
right,
they're
they're,
the
mental
patterns,
the
logic
illogic,
however,
you
want
to
call
it:
they're,
they're,
they're,
subjective
justifications,
they're
the
same.
It's
just
the
path
they
take
in
their
logic
to
justify
it
and
what
they
react
to
emotionally
are
are
where
it
differs,
but
the
the
actual
subjectivity
and
the
brain
processing
is
the
same.
So
that's
a
creepy
thing.
Yep.
A
Because
I've
often
heard
people
talk
about
how
the
the
political
spectrum
actually
is
a
circle
yeah
yeah.
So
it's
interesting.
D
A
A
I
will
be
happy,
though,
when
the
whole
election's
over,
just
because
I'm
just
tired
of
the
the
text
messages
telling
me
to
vote
and
the
emails
from
from
both
sides
it,
which
is
really
fascinating,
that
I
actually
get
from
both
ends.
I
have
no
idea
why
you
think
I
only
get
it
from
one
side
but
nope.
I
get
it
from
both
weird.
I
I
A
However,
we
do
need
to
start
talking
about
the
interop
doc.
I
did
make
a
couple
of
changes
earlier
today.
Just
some
suggestions.
We
do
at
least
have
something
to
talk
about,
but
I
didn't
realize
it,
but
november
2nd
is
coming
up
really
fast.
So
simon
are
you
there.
J
J
F
D
A
F
Oh
I'm
from
google,
okay.
A
L
I
A
Oh
hey
mark
how's
it
going
awesome
good,
oh
hey,
mark
before
I
forget
the
cncf
sent
us
a
note
asking
for
a
paragraph,
or
so,
if
you
want
to
give
them
a
status
update
for
some
for
something
they're
doing
for
kubecon,
I
was
gonna
write
something
up,
but
I
was
gonna.
I
wanted
to
send
it
off
to
you
just
to
do
wordsmithing
and
stuff
like
that,
so
keep
an
eye
out
for
a
slack
message
or
email
or
something
for
me
later
today.
I
K
Yeah,
it
comes
out
on
the
if
you're
on
the
cncf,
maintainers
email,
distribution.
B
I
A
Yeah
I
got
lucky
because
I
completely
missed
it
the
first
time
so,
as
you
said,
almost
all
the
time
slots
were
basically
gone,
except
there
was
like
a
late
late
friday
afternoon
was
still
available.
I
thought
okay,
fine
I'll
I'll
grab
that
one
and
then
almost
immediately
after
I
signed
up
for
that,
I
get
some
emails
saying
that
they
reopened
it
and
I
went
back
and
checked
and
I
got
really
good
times
so
I
ended
up
canceling.
C
A
All
right,
three:
after
why
don't
we
go
and
get
started?
Let's
see
we
have
17
people
all
right.
So
just
a
reminder,
I
don't
see
lance
or
scott,
so
I
can't
nag
them
about
the
ais
I'll,
keep
moving
forward.
Anything
from
the
community.
People
want
to
bring
up.
That's
not
on
the
agenda.
A
Okay,
not
hearing
it,
so,
as
I
mentioned
just
now,
we
do
have
office
hours.
I
was
able
to
snag
some.
I
think
some
pretty
good
times
as
we
get
closer
to
the
date
I'll
be
looking
for
people
to
volunteer
to
hang
out
there
last
time
it
was
fairly
easy.
A
I
don't
even
think
we
had
anybody
show
up
so
we're,
maybe
looking
for
one
or
two
people
just
to
hang
out
there
answer
questions
in
case
people
do
show
up
you're
looking
for
names
later
so
be
thinking
about
whether
you
can
take
either
or
both
of
those
times
be
appreciated,
but
it
should
be
light
duty.
A
I
kind
of
think
there's
anything
else
for
kubecon
that
we
need
to
mention.
I
can't
think
of
anything.
So
I
did
submit
the
video
and
powerpoint
slides
for
the
cloud
event
session
that
clemens
and
I
did
and
later
today,
timor
and
I
will
be
recording
the
one
for
the
serverless
working
group
session
and
then
we'll
submit
that
today
and
I
think
that's
it
in
terms
of
our
sessions
for
for
our
organization.
A
A
Sdk
call
none
this
week,
but
we
will
have
a
interop
call
immediately
following
this
one,
with
with
november
2nd
coming
up,
we
really
need
to
get
on
the
ball
in
terms
of
filling
out
the
the
scenario
dock.
Some
people
know
what
they
want
to
code
to.
A
I
did
make
some
suggested
changes
right
before
this
call,
so
we
do
at
least
something
to
talk
about
and
as
a
reminder,
we'll
start
that
call
immediately
following
this
one,
no
later
than
1
pm
eastern,
but
probably
earlier
since
we
have
a
short
agenda
today,
all
right
and
timor.
Anything
you
want
to
mention
relative
to
the
workflow
subgroup.
M
Oh
hi
yeah
for
the
specification
and
we're
currently
discussing
the
the
function
or
service
invocation
definitions,
we're
going
through
them
and
revising,
and
also
we're
moving
forward
to
to
hopefully
have
the
a
new
release
by
kubecon.
So
yeah.
Those
are
the
two
things
thanks:
okay,
any
questions
for
them.
A
I
A
N
Quickly,
yeah,
it's
very
easy.
The
json
schema
doesn't
follow
the
specification.
As
you
can
see,
the
data
schema
definition
has
a
mid-length
of
one
which
makes
it
required
parameters,
but
the
specification
says
data
schema
should
be
an
optional
parameter,
so
yeah.
A
G
G
A
G
A
G
Section
I
think,
above
this,
which
doesn't
have
data
schema
in
there.
G
This
just
means:
if
that
field
exists,
it
must
have
a
length
if
it
doesn't
exist.
It
doesn't
matter.
Okay,.
G
The
data
schema
can
be
it
shouldn't;
it
should
not
exist
in
the
payload
with
an
empty
string
and
that's
what
this
line
is
saying.
So
this
is
correct.
J
J
P
G
I
have
a
follow
up
to
add,
except
null
values
too,
so
that
will
that
will
solve
that.
Q
I
think
it
would
be
better
to
keep
the
mean
length
one
because
in
the
latest,
json
schema
draft
format
is
an
optional
validation
keyword.
So.
N
Okay,
I
just
noticed
that
all
the
required
fields
do
have
the
min
links
one
and
the
ones
optional
do
not
have
it.
So
I
thought
this
was
an
obvious
one,
but
okay,
we
we'd
also
want
to
add
novel
value,
acceptance
for
all
the
optional
ones
right
and
maybe
then
the
main
links
would
apply
to
all
or
none
of
them
having
this
field.
G
G
N
Yeah
so
now,
actually
I
thought
that
we
had
the
discussion
on
null
values
and
which
means
we
can
have
them.
Okay,
so
not
having
anything.
I
I
think
I'll
understand.
Okay,
so
but
then
yeah
I
I
can
have
a
data
schematic
a
data
schema
that
has,
I
know
this.
The
data
content
type
with
a
length
of
zero.
N
P
A
G
A
Q
Yeah
we
should.
We
should
do
that
again
because
in
the
next
spec
of
jesus
schema,
this
is
the
format
is
optional.
So,
even
if
there
is
the
time
the
validator
can
can
tell
you
look,
I
don't
know
anything
about
formats.
So.
A
Okay,
hold
on:
let's
take
some
notes
here:
okay,
so
let's:
let's
do
this
one
at
a
time
so
going
back
to
this
one?
Is
there
any
objection
to
closing
this
pr
with
no
action.
Q
A
G
Yeah,
so
the
general
idea
is
that
this
only
changes
how
we
interpret
the
wire
format.
Not
it
doesn't
change
anything
else.
So
it's
really
about
pushing
the
the
cloud
event
shape
onto
the
wire
as
a
json
object
and
pulling
it
off,
but
not
the
object
at
rest.
G
And
then
I
added
some
examples
of
valid
on
the
wire
cloud
event:
objects.
A
Yeah
yeah,
so
this
makes
it
clear
right
here
and
then
yeah
it's.
This
is
just
that's.
That's
the
prettier
right
stuff,
yep
and
then
here
are
the
examples
that
you
talked
about.
R
O
Sorry
much
better!
Thank
you.
I
think
there's
just
one
small
typo,
it's
my
type
of
week
in
equivalent
it's
written
equivalent
in
this
pier
for
what
I
read
like
if
you
go
up
like
yeah
here.
If
I,
if
I'm
correct
it's
the
second,
I
should
be.
A
O
A
S
A
Okay,
that's
what
I
thought.
Okay!
So,
let's
see,
if
there's
anything
else
here
worth
talking
about
those
are
just
prettier
things
and
then
we
have
down
here.
So
does
everybody
agree
with
these
changes
and,
of
course,
the
addition
of
mid
length
equals
one
on
this
one
and
time
def,
I'm
assuming
scott
you'll
check
the
other
ones
too,
like
bass,
f64.
A
Okay,
if
I'm
assuming
that,
if
all
that
that
if
scott
goes
ahead
and
adds
the
mid-length
equals
one
to
these
things,
that
everybody's
okay-
with
that,
we
can
approve
that
here.
However,
scott,
if
you
find
that
there's
another
gotcha
that
we're
not
thinking
of
we'll
hold
off
until
next
week
to
to
approve
it.
If
that's
okay
sounds
good,
okay,
all
right,
so
anybody
else
have
any
questions
or
comments
on
this
one
with
those
changes,
meaning
the
min
length
equals
one
and
then
the
the
I
to
a
letter
change
up
top
any
objections.
A
F
H
All
right
anish,
would
you
like
to
talk
to
this
one
yeah.
It
basically
sums
up
our
discussions
in
the
previous
weeks,
where
we
were
talking
about
having
certain
additional
fields
in
the
spec
in
the
webhook
spec.
I
guess,
and
then
we
decided
that
we
really
don't
want
to
get
into
the
security
business,
at
least
in
terms
of
our
specifications.
H
A
N
Yeah,
what
was
it
entirely?
I
think
the
idea
was
to
give
a
little
bit
of
guidance,
so
this
is
stating
that
every
vendor
has
a
different
authorization
model.
Hence
governments
will
not
now
or
in
the
future,
is
the
impression
I
get
from
the
text
specify
any.
A
A
A
H
I
would
really
expect
clemens
to
pitch
in
over
that,
because
it
was
like
a
very
clear
thing
from
his
side
that
we
do.
We
really
want
to
get
into
security
business
as
part
of
the
spec,
but
yeah
I
mean
I'm
all
right
with
it.
A
L
That
case,
should
we,
this
is
daniel
yeah.
It
only
talks
about
authorization
model.
I
think
we
were
talking
also
about
the
integrity
of
the
event.
H
L
L
Yeah,
if
we
are
not
going
to
do
yeah,
but
anything
I
would
say
you
know,
extend
it
for
the
integrity
part
also.
L
And
and
doug
you
know
if,
if
we
have
to,
let's
is
there
an
a
way
where
you
know
the
course
pack
would
not
say
anything
about
the
integrity
of
the
event?
But
if
you
want
to
give
a
example
where
you
know
there
are
use
cases
where
in
web
hooks,
you
want
to
send
event
out,
and
you
want
to
offer
a
you
know
and
up
show
an
approach
where
how
we
can
one
can
validate
the
integrity
of
the
club
event,
payload
and
event
envelope.
L
That
would
be
some.
Is
it
possible
to
link
some
documentation
from
cloud
events
site
for
that
those
kinds
of
use
cases,
or
we
would
not
even
do.
A
A
Okay,
yeah,
I
was
going
to
say
so.
My
personal
point
of
view
is,
I
think
it
makes
sense
for
us
to
talk
about
things
like
authorization,
encryption
or
or
integrity,
and
talk
about
how
we're
not
going
to
touch
that
stuff
when
it
comes
to
pointing
to
other
things
that
people
can
leverage
as
an
add-on.
To
our
specification,
I
think
it's
okay
to
talk
about
it
in
general
terms
to
say
hey
just
because
we
don't
do
it.
That
doesn't
mean
you
can't
add
it.
A
I
just
get
a
little
bit
nervous
about
pointing
to
particular
things,
because
I
don't
want
to
look
like
we're
endorsing
one
particular
thing
over
another
now,
if
we,
if
we
include
a
list
of
things
and
say
hey
by
the
way,
there's
x,
y
and
z
out
there
and
and
it's
very
clear
that
we
just
happened
to
pick
a
random
set
of
three
things,
then
that
that
would
I'd
be
okay
with.
But
if
you
only
point
to
one
that
would
make
me
more
nervous,
if
that
makes
any
sense.
H
T
I
E
Yeah,
I
just
wanted
you
to
be
able
to
speak
your
piece.
There's
two
comments
that
I
have
and
one
is
that
mentioning
vendors
seems
like
maybe
a
red
herring
is
not
the
right
word,
but
not
quite
as
direct
as
it
could
be
because
it
doesn't
say
anything
about,
say
the
the
open
source
or
you
know
other
kind
of
standardized
implementations
that
there
might
be
to
solve
for
this
problem.
But
the
other
piece
is
that
I
kind
of
assumed
and
I've
been
a
bit
lazy.
E
So
I
apologize,
but
I
kind
of
assumed
that
when
this
work
was
getting
done,
that
they'd
look
into
the
primer,
because
I'm
quite
certain
that
there's
a
piece
that
addresses
some
of
this
in
there
and
I
would
have
expected
that
to
either
been
modified
or
removed
in
preference
for
this.
But
anyway,
that's
monkeys.
A
N
Yeah,
if
I
recall
correctly,
we
were
talking
about
the
signatures
and
signatures
can
be
used
for
authentication
or
authorization,
but
I
think
the
integrity
check
was
the
use
case
being
discussed.
So
apart
from
the
authorization
that
is
done
with
the
book
and
using
this
signature
for
the
integrity
of
the
message,
we
were,
we
discussed
like
three
options:
either
we
wanted
to
also
save
the
integrity
of
the
cloud
events
envelope,
in
which
case
we
said
that
this
is
not
a
model
for
cloud
events.
N
I
think
so
it's
out
of
scope
there,
but
then
there
was
also
the
idea
that
maybe
the
data
part,
so
it
could
be
entirely
left
to
the
application
that
is
within
the
structure
sent
in
the
data
field
or,
if
wanted,
to
write
an
extension
that
carries
the
signature
and
the
envelope
for
the
data
transmitted
in
the
data
field.
N
So
I
wasn't
sure
if
clemens
had
said
something
on
the
consistency
of
this
approach,
but
I
think
there
was
something
that's
got
that
suggested
and
when,
when
we
said,
we
wanted
to
give
some
guidance
in
the
primer
of
how
to
do
that.
I
thought
this
would
sort
of
be
be
put
in
the
text
like
a
user
could
choose
to
you
solve
this
entirely
at
their
application
level,
and
maybe
if
we
say
it
shouldn't
be
integrity
of
the
envelopes,
then
this
may
be
a
decision
so
to
to
say
this
should
be
excluded
from
future
attempts.
L
Yeah,
I
I
agree
with
manuel,
I
think,
the
out
of
those
three
approaches
right.
I
I
did
write
a
comment
that
often
you
know
you
have
to
sign,
because
the
cloud
event
envelope
has
contacts
which
is
important
when
you
sign
the
payroll.
So,
in
my
opinion,
manuals
you
know.
The
third
approach
only
makes
sense
when
you
are
doing
the
integrity
check,
but
I
agree
that
we
should
list
those
three
things
in
a
you
know
separately,
and
we
shouldn't
say
that
you
know
you
should
just.
L
However,
you
want
to
sign
the
payload
and
you
you
know,
go
ahead
and
use
whatever
approach
you
want
to
use.
I
think
parts
of
the
envelope
are
important
whenever
you
sign
the
payload,
so
our
guidance
should
be
kind
of
you
know
include
that
part
that
you
know.
L
We
understand
that
part
of
the
envelope
is
also
important
when
you
sign
any
payroll,
and
if
you
want
to
do
it,
you
can
do
it
this
way,
and
I'm
not
talking
about
the
course
pack,
I'm
talking
about
the
other
revenue
where
we
know
we
want
to
discuss
this
use
cases
there.
We
should
take
all
three
options
and
you
know
provide
recommendation
accordingly.
L
A
So
so
niche
you've
got
a
lot
of
feedback.
How
would
you
like
to
proceed.
H
I
would
like
the
comments
to
be
owned
over
the
pr
so
that
I
can
address
on
them
and
then
how
I
see
is
at
least
currently
we
probably
don't
want
to
deal
with
the
integrity
issue-
data
integrity
issue
right
now
till
we
start
addressing
it
as
a
topic.
So
how
about?
We
simply
say
right
now
that
currently
we
do
not
mandate
it
and
then
we're
gonna
address
this
issue.
H
Overall,
once
we
try
to
pin
down
the
data
integrity
topic
in
general,
because
this
completely
deals
with
us
not
having
a
mandate
towards
an
authorization
principle
or
a
security
model
at
least
right
now,
and
then
we
would
probably
address
it.
It's
not
like
we
are
not
going
to
address
it,
but
this
is
something
I
think
it
needs
a
bit
more
deeper
discussions
down
the
line.
A
Right
but
it
I
want
to
make
sure
I
understood
what
you're
saying
there.
I
are
you
going
to
update
your
pull
request
to
make
it
clear
that,
basically
we're
we're
not
touching
security,
and
that
includes
authorization,
integrity,
checks
and
yeah.
I
would
say
so:
okay,
okay,
okay,
so
we're
looking
for
an
updated
pr.
Then.
A
And
so
people,
please
add
your
comments
to
the
pr
if
you
have
not
done
so
already
so
that
so
a
niche
has
all
the
feedback
written
down
and
get
you
can
get
your
thoughts
out
there.
A
A
Those
are
minor
things.
I
think
that
was
the
only
comment
in
there.
Let
me
show
just
make
sure
yeah
yeah,
okay,
cool
okay.
So
yes,
please
everybody
leave
your
comments
on
there,
even
if
you
said
it
on
the
call
here.
Please
leave
your
comments
in
the
issue
itself,
so
that
so
a
niche
can
remember
it
and
and
take
it
into
account
as
he
edits
the
text.
I
A
I
A
G
I
read
the
spec
and
it
seems
like
database
64
as
an
empty
string
is
technically
valid,
base64
encoded
data,
so
I
left
it
alone.
A
A
A
I
A
All
right,
so
it
seems
to
me
based
upon
our
previous
discussions
about
things
like.
Maybe
we
shouldn't
tackle
importing
and
exporting
or
synchronization
between
discovery
endpoints.
A
So
user
queries
discovery
endpoint
with
the
services
they
select,
one,
they
maybe
they'll
they'll
only
look
for
the
one
that
supports
hdb
push
delivery.
They
subscribe
to
it.
They
verify
that
subscription
looks
right
by
doing
http
get
to
the
subscription.
They
verify
that
they
get
at
least
one
event,
because
this
is
the
service
is
going
to
be
required
to
send
at
least
one
event
every
30
seconds,
so
they
verify
they
get
at
least
one
the
user.
A
When
they're
all
done,
they
can
delete
the
subscription
and
then
verify
they
don't
get
any
more
events
ignoring
any
possible
things
already
in
flight.
But
I
was
thinking
if
we
can
at
least
do
this
simple
flow
at
least
test.
I
think
some
of
the
basic
stuffs
or
stuff
in
the
spec-
and
it
does
do
discovery
spec
a
little
and
a
little
bit
of
the
subscription
spec.
A
If
we
wanted,
then
we
can
go
a
little
further
and
say:
okay,
let's
start
adding
some
filtering,
possibly
updating
the
subscription
and
get
if
we
really
ambitious.
Some
non-http
plus
push
event
delivery,
but
that
was
just
some
initial
thoughts
that
I
had
because
I
feel
like
we
needed
to
to
fill
out
the
document
a
little
bit
better
in
terms
of
what
the
actual
scenario
is
going
to
be.
G
A
G
It
doesn't
need
to
be,
though,
right.
I
think
we
really
need
to
pull
back
all
of
the
management
apis
that
have
been
added
and
and
just
wait
and
see,
because
I
think
that's
that
should
be
up
to
the
implementation
detail.
I
don't
think
the
specification
needs
to
define
how
to
aggregate
stuff.
We
just
need
to
talk
about
what
the
endpoint
provides
and
what
the
data
means.
G
I
I
think
it's
an
implementation
choice
of
whatever
is
going
to
aggregate
stuff
right
like
this
is
a
this
is
a
feature
that
the
downstreams
implement
and
they
to
the
to
the
upstreams.
They
look
like
just
another
consumer
asking
for
the
discovery
endpoint,
but
to
them
like
to
to
the
down
to
the
sorry
I
always
get
the
upstream
to
downstream,
so
the
for
the
upstream
service
that
downstream
thing.
So
the
the
aggregate
looks
just
like
another
client
to
it.
Okay,
so
he's
just
doing
a
series
of
gets
just
doing
gets.
G
Okay
now
the
the
thing
that's
interesting
that
doesn't
have
to
be
written
down
in
the
spec
but
could
be
in
some
kind
of
primer,
is
that
if
you
are
a
discovery
endpoint,
you
can
also
implement
the
the
the
subscription
api
for
the
catalog
content
of
the
discovery,
api,
which
is
very
tricky
and,
and
it
doesn't
have
to
be
specified
right,
like
that's
just
something
that
you
can
do
if
you
interpolate
between
the
discovery,
endpoint
spec
and
the
the
subscription
api
spec.
G
A
Sorry
go
ahead,
yeah
go
ahead,
I
was
going
to
say.
I
think
I
think
what
you're
describing
there
sounds
sounds
nice
and
it
certainly
would
be
easier
than
I
think
what
I
was
had
in
my
head.
Can
you
actually
just
replace
this
section
with
what
you
sort
of
described
there
sure.
A
O
I
think
it's
good
to
yeah
for
me,
it's
good
to
try
to
do
that,
to
make
it
more
concrete,
okay
and
to
kind
of
follow
on
scott's
thoughts,
I
that
was
what
I
discussed
a
bit
yesterday
with
you.
O
Then,
as
an
idea
mean,
I
can
add
new
services
into
it
and
for
my
old
company,
they
will
all
list
that
gateway
discovery
service
that
static
to
all
the
other
platforms
through
all
we
defined
and
make
them
available
without
to
think
about
anything
like
basically
just
have
like
the
new
github,
and
that's
the
kind
of
that.
I
think
it
spawned
a
new
just
project
that
is
called
like.
I
don't
know
cloud
events
gateway
or
something
like
that.
That
would
then
have
to
implement,
subscription
and
and
the
discovery
service.
G
Not
the
details
of
how
to
implement
that
the
aggregation
pieces,
because
that's
completely
dependent-
and
I
think
that
those
aggregates
need
to
be
free
to
make
decisions
around
like.
Maybe
they
do
want
to
change
the
epoch
or
maybe
they
don't
expose
the
epoch
they
got
from
downstream
and
they
save
it
in
some
sort
of
cache
and
rewrite
it
right.
So
then
they
could
do
paging
and
a
bunch
of
other
fancy
stuff
as
an
internal
detail.
But.
O
So
I'm
like
I'm
eager
to
stop.
I
don't
know
if
there
is
already
a
project
that
does
that,
but
I
think
it
will
help
me
at
least
get
really
into
the
full
credit
work.
If
I
initiate
some
kind
of
project
like
that,
but
I
mean
if
the
work
already
exists
somewhere.
I
know
I
should
not
do
it.
I
guess,
but.
O
I,
like
I,
really
don't
care.
I'm
not
saying
that
go
is
my
favorite.
If
I
had
to
learn,
go
and
do
it
in
good
and
I
can
learn
it
like.
G
O
Lots
of
typescript,
but
I'm
open,
I
mean
I.
G
Think
we
need
a
typescript
version,
so
so
the
point
of
the
interop
demo
that's
happening
in
november-
is
that
we
would
like
to
be
able
to
run
through
this
simple
flow
and
then
maybe
run
through
more
complex
thing,
with
several
implementations
that
read
from
the
spec
that
implemented
what
the
spec
said
to
validate
that
the
spec
is
actually
feasible
and
doable
and
implement
implementable
in
several
languages.
O
Yeah
and
my
my
goal
like
at
least
when
I
thought
this
week
was
like,
even
though
I
would
like
to
have
just
a
small
react
or
whatever
ui
framework
you
prefer,
but
like
a
small
ui
that
is
basically
for
a
human
to
really
see
those
endpoints
a
little
bit
nicer
than
just
apis
and
that's
basically
the
beginning
like
the
way
I
see
it
but,
like
I
don't
know,
if
I'm
hijacking
this
meeting
is
that
the
case
you
can
tell
me
he's
like,
I
would
love
to
have
a
ui
where,
basically,
I
say,
okay,
I
have
a
new
server
like
service
that
I
know
that
is
on
that
url.
O
Just
it
is
the
discovery
point
and
just
import
all
the
services.
Then
I
have
a
third
one.
That
is
whatever
language
it
is.
I
don't
really
care
because
then
I'm
just
gonna
use
like
the
discovery
api
and
then
they
they
subscribe
automatically
and
then
you
can
just
come
and
subscribe
to
this
gateway.
That
will
basically
get
all
the
information
from
the
other
services
and
aggregate
like
and
act
as
an
aggregate.
O
But
I
think
this
will
be
super
concrete
to
me
and
I
would
really
understand
what
we
are
trying
to
do.
While
in
the
last
months
I
was
a
bit
more
confused,
but
again
it's
maybe
just
like.
I
can
take
the
blame
without
any
issue
and
that
I
think.
G
O
G
A
Yeah
and
in
other
interops,
we
did
have
different
people
signed
up
to
do
different
parts
of
the
overall
demo
like
they.
That
way,
everybody
didn't
have
to
implement
everything
in
this
particular
case,
though
I
do
think
it'd
be
useful
if
everybody
did
implement
everything,
meaning
they
they
implement
a
discovery
endpoint
they
interrupt
they.
They
provided
a
service
that
you
can
subscribe
to.
They,
everybody
wrote
their
own
client
and
that
way
we
can
test
again.
You
know
an
end
matrix.
O
I
think
it's
good
right
so
yeah
my
vision
there
is.
There
is
like
the
basic
discovery
api
that
I
was
trying
to
put
in
the
sdk.
Just
because
when
you
do
a
simple
service,
I
think
you
have
value
to
be
able
to
ex
like
a
basic
discovery
service
and
then
for
the
whole
interrupt.
I
think
it
has
value
to
get
the
more
complex
aggregator
that
they
have
in
mind
I'll
try.
A
One
thing
I'd
like
to
you
consider
not
necessarily
for
this
call,
but,
as
you
write,
this
up
is
to
explain
how
you
see
it
working
when
you
have
another
party
involved,
who's,
doing
the
gets
against
both
the
upstream
and
the
downstream,
and
then
the
same
service
comes
from
both
guys,
right
and
and
the
epoch
values
don't
match,
or
something
like
that,
and
you
know
what,
if
one
or
both
of
those
of
those
upstreams
to
that
third
party
guy
update
it
right,
which
one
does
the
guy
use,
that
that
kind
of
stuff
right
I'd
like
to
understand
how
you,
how
you
see
all
that
playing
out
so.
G
H
You
can
you
just
go
to
the
view,
options
and
click
on
annotate
and
then
I'll
start
to
put
a
white
screen.
You
request
annotate.
Okay,
here
we
go
okay,
uh-oh.
A
A
G
G
To
make
it
clear
that
the
arrow
of
direction
is
where
the
request
is
coming
from
so
so
c
here
is
the
well,
maybe
we'll
call
it
x
because
that's
a
little
easier
to
draw,
oh,
my
goodness,
okay,
so
x
is
the
the
final
consumer
and
it's
making
a
aggregate
request
to
a
and
b,
because
it
has
a
bunch
of
other
users
that
are
going
to
aggregate
from
it
or
or
this
descri
ask
for
subscriptions
or
whatever
right,
and
it
sees
there's
there's
a
foo.
Oh
my
goodness,
oh
my
goodness
wait
hold
on.
G
G
So
when
when
x
sees
a's
subscription
list
and
sees
the
e
pocket
one,
it
says:
okay,
cool
I'll
store
that
and
then
it
goes
and
calls
b
and
says:
okay,
oh
you
also
have
a
foo
and
your
epoch
is
two:
that's
more
better.
I'm
gonna
save
that
one
and
I'm
going
to
drop
what
a
gave
me
so
now
I
have
everything
that
b
had
I
have
everything
that
a
gave
b
but
b
could
have
filtered
some
of
things
from
a
out
right.
G
G
A
A
Yeah,
we
just
need
to
specify
that
we
just
need
to
write
it
down
and
don't
have
to
solve
it
on
this
call
here.
But
those
are
the
kind
of
things
that
I
worry
about,
because
I'm
not
sure
you
can
always
guarantee
that
x
is
the
end
of
the
chain,
because
b
may
have
thought
he
was
the
end
of
the
chain
and
he's
wrong.
A
G
Yeah-
and
so
this
is
kind
of
why-
I
I
think
that
the
the
whole
management
api
probably
needs
to
get
pulled
from
the
spec,
because
it
complicates
this
situation
and
it
makes
us
have
to
figure
it
out,
and
I
think
that
that
the
push
based
management
api
probably
should
be
an
implementation
detail
of
a
particular
implementation
instead
of
specified
by
the
cloud
event.
Spec.
G
Yeah:
okay,
let's
so,
okay,
let's
pause
on
trying
to
delete
all
of
doug's
work
until
we're
gonna
wrap
them
up.
You
need
to
make
me
implement
all
your
crazy
crud.
No.
A
No,
no,
that
notice
notice
the
stuff
I
wrote
up
here
does
not
do
anything
with
the
crud
okay.
I
purposely
did
not
even
touch
that,
because
I
agree
with
you
I
that
stuff
very
likely
is
going
to
get
pulled.
I
have
no
problem
with
pulling
it.
I
just
want
to
make
sure
we
have
an
understanding
of
how
that
synchronization
that
you
just
drew
on
the
board.
There
is
going
to
play
out,
even
if
it's
all
done
through
gets
I'm
okay
with
that.
I
just
want
to
understand
it
all
right.
G
G
G
A
G
F
All
right,
anish
your
hands
up,
I'm
just
a
bit
confused.
H
G
But
that
may
be
just
one
in
a
a
series
of
clusters
that
are
connected
through
some
sort
of
means
and
the
discovery
and
subscription
apis
are
what
I'm
trying
to
get
those
clusters
to
link
together
so
that
they
can
pull
down.
What's
available
in
the
universe
of
events
to
be
subscribing
to
and
then
aggregate
up
subscriptions
that
apply
to
that
particular
endpoint.
H
That's
a
fair
thing
to
tackle
down,
at
least
in
terms
of
distributed
system
for
sure,
but
where
I
got
confused
is
like
how
can
how
how
does
it
I
mean?
How
does
the
collision
happen?
So,
in
what
scenario
is
it
like?
The
epochs,
for
example,
are
gonna
be
mutated
by
because
they
have
to
work
on
the
same
object
right
if
they
are
trying
to
mutate
it
and
every
piece
in
the
puzzle,
or
basically
a
b
or
c
individually.
They
have
their
own
discovery
specific
their
own
discovery,
endpoint
right.
G
Right
the
the
epoch
came
about
because
my
first
prototype
of
this
I
implemented
a
ring,
and
I
implemented
a
very
simple.
I
think
10
second
sync
timer,
and
it
very
quickly
showed
that,
based
on
timing,
I
could
get
a
bubble
of
incorrect
data
flowing
through
each
node
where
it
goes
and
it
it
propagates
the
wrong
data
down
and
then
aggregates
up
to
the
correct
data
and
replaces
the
wrong
data.
G
But
you
have
this
little
bubble
of
incorrect
data
being
synchronized
between
all
the
clients
and
then
it
gets
replaced
by
what's
behind
it,
because
there's
no
way
to
compare
it.
And
so
that's
where
that's
where
epoch
came
from.
S
Yeah
it's
just
if
I
may
draw
go
for
it.
I
open
the
world
for
everyone
yeah,
it's
just
that's
the
first
time.
O
J
O
O
So
then,
my
internal
employee
will
only
subscribe
to
this
gateway
and,
if
b,
needs
to
see
a
basically
the
way
I
will
see
it
is,
I
will
ask
b
to
subscribe
to
my
gateway,
because
I
probably
need
to
filter
some
of
the
a
event,
because
I
don't
want,
like
let's
say
it's
github
on
that
side,
and
I
don't
know
it's
my
ideas
on
the
beach
or
my
cia
and
the
blade
a
will
start.
Sending
me
all
kind
of
events,
and
I
I
don't
want
b,
to
see
some
private
events
from
github.
O
So
this
way
I
will
have
better
control
if
it
goes
through
a
gateway.
So
then,
I
won't
have
those
kind
of
token,
and
that's
why
I
was
talking
about
like
kind
of
gateways
or
aggregators
is
just
because
if
I
have
lots
of
connection
between
like
a
and
b
and
c
and
id
and
things
like
that,
the
way
to
manage
permission
in
between
might
become
harder
for
me,
but
maybe
I'm
wrong.
That's
what
I
have
in
my
brain
currently
any
comments.
G
O
G
O
Yeah,
like
I
will
go
to
the
team
that
managed
c
say:
okay,
like
you,
don't
don't
go
to
b
directly
because,
like
it's
not
manageable
for
me
in
a
good
way
like
because
then
I
have
too
many
flows
that
goes
everywhere
and
to
explain
to
like
our
compliance
officer.
It's
going
to
be
hard.
O
O
Yeah-
and
that
means
then
the
concrete
is
more
using
that.
So
that's
why
I
really
want
the
gateway
product
and
because
without
it
I
don't
see
how
I
will
do
a
good
implementation
in
my
company.
G
Yeah
absolutely-
and
I
think
that's
that's
why
the
gateway
needs
to
be
able
to
write
epochs
and
things,
but.
P
A
Okay
class,
your
hands.
T
T
Something
more,
I
wonder
if
it's
really
a
good
idea
to
do
this
via
the
same
api
as
the
discovery
itself,
because
you
will
also
have
to
deal
with
different
kinds
of
authorization
models
for
those
gateways
and
for
consumers.
I,
I
would
suppose
at
least.
T
O
O
While
on
github
I
have
like
my
application
that
is
like
put
on
the
organization
which
I
don't
want
to
see
to
be
aware
of,
but
like
we
need
authorization
and
that's
why,
like
earlier
when
we
talk
about
authorization,
kind
of
leading
the
subject,
I
think
it's
still
really
important
because
coming
from
security
like
we
don't
live
in
an
open
world,
so
we
don't
like.
We
need
to
have
a
way
to
close
it
down.
So
maybe
we
should.
T
But
the
gateway
again
needs
some
kind
of
token,
then,
to
access
a
and
b
so
correct,
yeah
back
to
dns.
So
in
dns
you
have
servers
that
are
authoritative
for
certain
zones,
and
so
this
fully
distributed
approach,
I
think,
is-
is
really
hard.
I
mean
in
distributed
systems
that
you
always
reach
the
point
when
you
have
some
central
component.
T
So
that's
why?
I
wonder
if
this
this
fully
distributed
approach,
what
scott
was
mentioning
before
is
really
feasible.
Another
thing,
I
wonder
if
also
something
like
a
document
format
for
exchanging
events
between
discovery
and
points
might
be
a
solution
so
that
you
don't
use
the
usual
discovery
api,
but
something
like
a
document
format
where
you
can
have
a
well-defined
bundle
of
events.
You
you
transfer
to
another
discovery,
endpoint.
I
I
elaborate
a
little
what
why
do
you
think
that
it's
a
bit
like
the
zone
transfer
you
might
have
in
dns
or.
T
A
T
No
insane
event,
so
what
I
mean
is
well
that
a
could
provide
some
some
document
containing
the
services
or
events
it's
making
discoverable
and
then
the
gateway
could
then
retrieve
that
document,
and
you
don't
run
into
all
these
authorization
issues
and
yeah
more
more
in
the
in
the
spirit
of
yeah
async
api
open
api
in
those
standards.
O
A
J
Simon
your
hands
up
yeah,
so
I
also
see
the
problems
with
distributed
systems
which
have
so
many
relations
between
them
to
think
it,
and
one
approach
we
are
currently
evaluating
is
to
make
a
distinction
between
aggregators
and
providers
basically
of
such
information.
So
in
that
picture
a
and
b
could
be
relatively
stupid
and
just
implement
xposed.
J
Than
one,
but
you
won't
have
that
many,
so
it's
more
manageable.
O
Okay,
if
I
mean
sir,
because
if
you're
right
yeah,
that's
but
that's
why,
like?
If
you
look
on
the
the
way
I
first
implemented,
the
discovery
was
exactly
that
the
sdk
had
like
a
simple,
not
intelligent
discovery
system
to
just
publish
what
he
was
emitting
as
cloud
events
and
and
then
my
second
thought
is.
O
I
need
to
have
that
gateway
because,
like
I
need
something
that
is
way
more
cleaver,
but
that
and
then,
as
a
developer
of
a
it's
easy,
because
within
a
few
lines
of
code,
you
just
have
your
discovery,
service
running
and
then
in
the
gateway.
I
have
my
my
team,
who
will
basically
connect
all
those
small
services
and
then
we
can
just
publish
to
the
whole
company
which
sits
on
the
seaside,
all
the
events
that
they
can
consume.
J
Yeah,
that
was
also
we
had
a
very
similar
motivation
behind
that,
also
because
we
had
a
lot
of,
we
have
a
lot
of
yeah
systems
which
would
provide
events,
and
we
want
to
keep
the
effort
to
provide
discovery
as
low
as
possible
and
then
just
add
all
the
extra
functionality
in
a
single
place,
or
maybe
two
places,
but
a
very
limited
amount
of
places.
J
Okay,
john:
your
hands
up.
B
Yeah,
so
there's
so
many
things
going
on,
so
I
apologize
for
not
keeping
up
with
the
discovery
stuff
in
general,
but
there's
there's
there's
like
so
let
me
go
back
to
this
epoch
issue
right.
If
you're,
if
you're
going
to
allow
rewriting,
you
now
have
identity
problems
right
so
that
that's
you
know,
I
think
what
scott
he
had
to
leave.
But
the
you
know
the
issue
of
creating
a
bubble
behind
the
gateway
is
if
somebody
wants
to
create
a
bubble
that
that's
up
to
them,
but
then
you
have
all
these
restrictions
right.
B
You
also
have
all
sorts
of
security
problems
when
you're
now
basically
inducing
a
man
in
the
middle
right.
So
it's
not
just
for
authentication
and
authorization.
It's
it's
integrity.
It's
trust!
It's
it's
all
these
additional
features.
So
it's
not
just
the
issue
of
well.
Are
we
allowing
people
or
not
or
whatever?
However,
you
want
to
say
it
in
in
specification,
speak
but
like
what's
the
identity
like?
Are
we
changing
the
identity
of
events
coming
from
a
and
b
in
the
gateway
such
that
the
gateway?
Is
the
authoritative
truth
right
or
are
we
pretending?
B
B
You've
got
multiple
dimensions
that
are
that
are
now
in
conflict
that
you
don't
have
any
ability
to
tease
apart,
because,
like
all
bets
are
off
right
either
you
say
that
the
you
know
c
is
talking
to
the
gateway,
and
it
only
knows
about
the
gateway,
and
so
the
catalog,
this
aggregated
catalog,
coming
from
the
gateway,
is
the
source
of
truth.
So
you
can
think
about
the
gateway
as
changing
the
reference
frame
of
the
universe
relative
to
its
consumers
right
so
c.
In
this
case,
right.
J
Yes,
but
I
would
argue
that
the
aggregator
and
the
gateway
can
be
two
different
concepts
and.
B
B
Recursive
resolvers
there
there's
the
right,
we're
adding
complexity
and
we're
not
adding
the
capability,
or
at
least
so
far,
what
we're
talking
about
is
not
adding
the
capability
and
the
expectation
management
around
okay.
Well,
how
do
I
resolve
these
different
complexities
that
we've
we've
allowed
for.
O
For
me,
the
way
like
because
there
is
an
intermediary
that
is
defined
on
cloud,
even
so
you
can
just
like
be
the
one
passing
the
message.
I
will
consider
that
in
that
case,
like
I'm,
not
a
big
fan
of
rewriting,
I
I
suppose,
if
you
rewrite
it's,
it's
not
really
a
rewrite.
Then
you
create
a
new
event
based
on
the
previous
events.
But
for
me
it
should
not
be
a
modification.
So
basically
for
c
is
either.
O
I
provide
them
like
a
comm
dot,
github
event,
which
is
basically
what
they
will
find
from
github
documentation,
and
then
I
don't
do
anything
or
like
my
company
is
nuxero.
If
it's
nuke
ceo,
then
it's
gonna
be
nuxero.github
and
then
it's
a
completely
different
event
that
might
be
a
like
of
the
github
or
it's
something
completely
different.
That's
my
own
decision
to
transform
it.
O
If
I
transform
it,
then
the
gateway
becomes
like
the
source
of
the
event,
because
then
that
means
it
creates
new
type
of
event
that
is
specific
to
my
company,
but
so
this,
but
I'm
really
not
a
big
fan
of
like
rewriting
the
message
without
because,
as
you
said,
even
for
authentic,
like
integrity,
if
you
start
signing
the
message,
it's
not
gonna
work
anyway.
So
right.
B
So
if
you
look
at
the
the
work
these
days
in
you
know
whatever
I
hate
the
term
but
zero
trust
right
networking
is
this
just
like
more
and
more
problems
that
we're
adding?
So
my
my
concern
is
that
if
we're
going
to
you
know
open
up
these
kinds
of
things
like
epoch,
rewriting
and
those
kinds
of
things
I
mean
from
the
standard
perspective,
we
can
take
a
totally
neutral
perspective
and
say
hey.
If
you
do
that,
then
that's
up
to
you,
we
don't
we
don't
guarantee
anything.
B
But
if
we
take
that
loose
position,
then
now
we're
we're
basically
opening
the
floodgates
to
interrupt
problems
by
not
specifying
enough
about
well
what
should
be
done?
What
could
be
done?
What's
you
know
these
best
practices
of
you
know
if
the
identity
is
ultimately
github,
then
whatever
your
gateway
is
is,
is
really
a
proxy.
B
So
then,
are
we
specifying
enough
enough
grip
in
the
system
to
pass
through
credentials
and
whatever
we
need
to
do
so
that
it's
it's
actually
a
secure
or
securable
proxy
versus
a
new
source
of
truth,
that's
doing
whatever
it
wants
to
do.
A
Yeah
I
like
I,
like
the
fact
you
focused
on
identity,
because
that's
an
interesting
aspect
that
I
was
kind
of
wondering
about
is,
if
we're
going
to
allow
one
of
these
nodes,
like
the
gateway
to,
in
essence,
not
just
be
a
pass-through
for
the
epoch.
But
it's
going
to
allow
itself
to
set
the
epoch
value.
Then,
if
I
understand
you
correctly,
you're
almost
implying
that,
if
he's
going
to
take
ownership
of
the
epoch
value,
then
he
needs
to
almost
set
a
new
identity.
In
other
words,
a
new
guide
for.
O
A
And
I
like
that
approach
because
that
that
could
solve
a
lot
of
the
problems
right
it,
and
so,
if
you
yeah
so
yeah,
if
you
start
looking
with
the
epoch,
then
you
now
become
the
source
of
truth.
This
guy
so
yeah
give
it
a
new
identity,
and
then
it's
no
longer
the
same
thing
as
where
you
got
this
information
from
they
are
not
two
separate
resources
or
students.
O
Either
you
proxy,
or
you
create
your
own
based
on
something
like
another
source
of
truth.
If
you.
A
A
B
B
B
I
mean
you
have
all
the
politics
right,
all
the
politic
political
problems
right.
Yes,
you
know
big
customers
demanding
punch,
throughs,
one
way
or
the
other
and
all
that
kind
of
stuff.
So
there's
there's
plenty
of
external
nightmares
that
we
can
add
on
top,
but
if
we
don't
give
them
the
right
building
blocks,
it's
it.
It
can't
possibly
work
in
any
sort
of
secure
manner.
Right
and
certainly
you
know
at
ariba
as
part
of
sap.
We
ran
into
this
all
the
time,
like
literally
huge
customers
trying
to
say.
A
Yeah
okay,
so
this
has
been
a
wonderful
discussion.
It
is
a
slight
tangent
from
the
interop.
However,
it
is
all
good
if
somebody,
why
am
I
still
in
this
darn
mode,
I'm
in
annotation
mode?
If
somebody
wants
to
write
up
the
stuff
we
talked
about
here
as
a
proposal
for
the
spec
itself,
I
would
love
to
see
that,
but
I
know
everybody's
busy
with
other
stuff
and
we're
focused
on
the
interrupt
which
is
not
going
to
touch.
I
think
this
stuff
anyway,
except
for
maybe
scott's.
O
A
A
O
Yeah
and
my
goal
is
so
for
me
and
b
was
supposed
to
be
the
small
pr
I
did
in
the
sdk
like
for
discovery
service,
but
the
gateway
is
clearly
another
open
source
project
that
I
can
start
on
my
own
repository
for
now,
but
I
think
it
will
help
explaining
that.
So
I
can
work
on
it
and
definitely
for
if
we
do
an
interrupt.
I
think
it
would
be
nice
to
have
at
least
some
draft
on
that.