►
From YouTube: CNCF Serverless WG Meeting - 2018-08-16
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
Let's
seize
three
after
so
why
don't
we
go
in
and
get
started?
Let's
see,
AI
is
the
only
one
I
really
want
to
talk
about
with
logo.
So
Brian
look
at
that
one,
let's
jump
right
into
the
extension
stuff.
So
come
on
a
second.
Let
me
open
this
up.
So
Sarah,
that's
air.
After
Mary
Rachel,
they
said
a
comment
in
their
last
evening.
I
think
so.
I
can
find.
B
A
There
is
it
right
here,
and
hopefully
everyone
had
a
chance
to
look
at
those
comments.
I
guess
just
as
a
quick
refresher.
So
in
last
week's
call
we
were
gonna,
be
taking
we're,
gonna
be
taking
votes,
but
then
Cathy
had
some
last-minute
changes,
you'd
like
to
make
to
the
PR
shoot
and
we
got
those
in
so
that's
behind
us.
A
So
the
plan
was
to
actually
have
a
vote
first
thing
on
the
call
today
right
now,
however,
with
Rachel's
comments,
I'm
pretty
much
interpreting
her
comment
as
a
request
to
delay
the
votes
so
that
they
can
prepare
some
material
to
explain
some
of
their
concerns
and
do
those
and
do
that
presentation
to
us
on
next
week's
phone
call.
I
might
have
interpreted
correctly.
Rachel
yeah.
C
A
A
E
E
But
that
should
be
something
that
most
people
can
go
and
follow.
That
basically
proves
that
you
can
go
and
do
not
only
that
flow,
but
also
you
can
actually
do
extensibility
in
the
sense
of
you
know:
Provo,
promoting
properties
out
of
the
1.0
assumed
one
for
no
standard
21.1
standard
and
then
also
have
kind
of
flexibility.
An
upgrade
ability
in
that
model,
so
I
would
ask
people
to
go
and
review
then
and
I'm
happy
to
go
and
hear
google's
arguments
next
week
and
then
end
that
call
next
week
with
the
vote.
A
Right,
okay,
so
there
are
couple
of
things
that
are
mentioned
in
there.
One
is
I'm,
not
I,
don't
think
I'm
hearing
any
objections
yet
deferring
the
vote
until
next
week
and
have
the
discussion
obviously
I'll
ask
again,
because
only
two
people
got
to
speak
there,
but
two
there
was
some
requests
there
made
as
part
of
Google's
sort
of
presentation
to
the
group
to
address
some
of
what
Clements
mentioned
there.
The
other
thing
is
Clements.
You
have
mentioned
your
POC
III
preferred
not
to
necessarily
take
up
time
on
this
call
to
talk
about
your
POC.
A
F
A
G
G
I
A
H
A
A
A
K
A
A
No
objection
to
that
plan-
oh
great,
so
that
is
the
plan
moving
forward.
Thank
you
guys
very
much
all
right.
Next
on
the
agenda,
it
was
brought
up.
I
came
around
I
apologize
Kimber
who
mentioned
it,
but
someone
mentioned
in
slack
about
the
possible
the
face-to-face
meeting
at
the
OSS
summit
in
Vancouver
at
the
end
of
the
month,
so
I
said,
I'd
bring
it
up,
I'm
just
curious:
do
people
want
have
a
face-to-face
or
heard
enough
people
gonna
be
there
to
warrant
it
face
to
face
who's
gonna,
be
there
yeah.
L
A
E
A
A
A
Good
to
yes,
okay,
so
tell
you
what
I'm
not
hearing
a
whole
bunch
of
people
speaking
up.
But
let
me
do
this:
what
if
I
started
doodle
poll
and
make
it
last
not
too
long,
because
people
would
need
to
make
plans
if
we
do
set
it
up.
So
maybe
a
doodle
poll
that
ends
end
of
day
tomorrow
and
if
we
can
get
a
signal
but
number
people
saying
yes,
then
we'll
see
if
we
can
set
something
up.
A
H
H
H
A
Is
definitely
true
yeah,
so
we
don't
have
quorum.
We
can
still
meet
if
we
chose
change,
but
it's
not
a
for
a
working
group
session
and
you're
right,
Clemens,
I'll,
double-check
I,
think
at
our
charter
it
actually
may
require
certain
number
of
weeks
and
I'll
go
back
and
double-check
if
it's
within
I'm.
Sorry,
if
it's
too
soon
for
the
Charter,
then
I'll
drop
the
entire
idea.
I,
don't
double-check!
On
that:
okay,
great
yep,
all
right
community
time
are
there
any
community
questions?
A
A
B
B
B
B
A
M
A
A
A
I
Okay,
so
we
have
had
multiple
meetings
in
a
working
on
this
document.
I
The
subgroup
has
been
working
on
this
document
and
updating
it
adding
address
in
the
comments,
and
then
we
wrapped
up
in
last
week's
meeting,
and
so
now
we
would
like
to
bring
this
to
the
and
to
the
through
this
workgroup,
to
discuss
where
we
should
put
this
document.
Should
we
put
into
a
separate
repo,
or
should
we
put
it
put
it
in
crowd
events,
repo.
A
Right
so
I
was
my
personal
view
was
to
create
a
separate
vivo
for
this,
because
it's
not
part
of
the
cloud
events
work.
Obviously,
but
it
does.
In
my
opinion,
it
warrants
its
own
little,
its
own
little
people,
because
it's
also
not
part
of
the
service
stuff.
It's
sort
of
a
new
side
project.
What
is
ideal
in
the
working
group
think
a
brand
new
repo
de
tous.
This
is
that
ok,
everybody.
I
So
I
was
this
is
part
of
Cerberus,
but
it's
not
I
agree
with.
You
is
not
it's
not
I'm.
Really.
You
know
a
section
of
cloud
events
I
think
it's
parallel
to
cloud
events,
but
it's
a
server
list
function,
workflow,
so
I
think
Bobby
I
agree.
It's
a
separate
ripple
is
better
yeah.
A
I'm
trying
to
think
we
this
server,
this
working
group
has
its
own
repo
under
C
and
C
F,
so
we
can't
keep.
We
can't
create
a
repo
under
our
our
repo
under
the
working
group
service,
repo
I
think
we'd
have
to
create
a
new
repo
under
C
and
C
F
I
think
that's
the
only
work
we
have
access
to
at
this
point
right.
A
H
So
maybe
the
workflow
we're
calling
a
working
group
but
like
the
workflow
working
group,
is
a
sub
or
the
service
working
group
and
artifact
go
there
until
such
a
time
that
the
server
working
group
thinks
it
should
be
a
project
and
potentially,
what's
it
or
whatever
is
going
to
or
documents
it
or
whatever
the
outcome
I'm
going
to
be.
Okay,.
B
H
You
know
I,
don't
like
I
haven't
been
involved
in
it.
So
I,
don't
know
what
exactly
the
proposal
is,
but
it
does
seem
like
you,
it's
premature
or
two
and
like
maybe
tailed
Li
GOC,
like
that
there's
something
in
honor
at
worst.
At
a
time
or
something
I
think
this
there
should
be
a
like.
We
need
a
kind
of
a
like
Kathy
Stanley.
We
need
to
figure
out
like
what
is
this
thing?
So
it's
you
know
it
may
be
a
service
working
group
work
stream,
okay,.
A
I
A
A
Cool,
thank
you
all
right
cool
all
right
moving
forward.
Then
we
don't
have
any
issues
in
terms
of
maintenance
that
I
want.
I
was
hoping
we
get
too
close,
let's
jump
right
into
PRS
all
right.
Hopefully
this
one
is
an
easy
one.
I
did
give
you
guys
a
warning
that
I
considered
it
to
be
such
it
so
Thomas.
Would
you
like
to
talk
to
this
sampling
extension
PR
be
reopened
yeah.
This
is.
K
Once
again,
it
was
a
vendors,
a
change
or
an
adaptive
change
from
what
honeycomb,
who
posed
long
ago.
They
want
to
have
an
extension
where
system
may
send
a
subset
in
order
to
do
observability
without
overloading
a
system
with
too
much
data,
and
so
this
is
the
data
layer
that
the
event
itself
would
include
a
an
extension
for
the
sampling
rate,
which
basically
tells
you
how
many
events
this
supposedly
represents
so
to
speak.
K
Not
talk
to
those
sure
the
spec
had
never
supported
the
idea
of
an
integer
before
so
I
had
to
add
it
into
the
episode
it
seems
like
32-bit
integer
solves
our
needs
for
now,
so
I'm
not
inventing
a
whole
bunch
of
types
of
integers.
If
we
needed
some
more
clarity
in
the
future,
we
might
that
you
integer
or
human
54,.
A
K
E
Nobody
I
think
it's
great
for
first
for
for
our
first
example
of
an
extension
and
it's
it's
good
use,
yeah
I,
think
having
for
the
formal
language
of
the
integer
type,
we
could
be
a
little
bit
like
a
32-bit
hold
number.
We
could
go
and
formulate.
This
is
a
little
bit
more
kind
of
like
its.
It
needs
to
be
clear
that
it's
signed
or
unsigned-
that's
not.
There.
F
K
64-Bit
is
not
JSON
safe.
You
cannot
represent
a
64-bit
number
in
JSON,
because
JSON
takes
a
lot
of
well,
not
in
all
languages.
For
example,
JavaScript
can't
handle
64-bit
integers,
so
there's
actually
a
lot
of
controversy
around
those
numbers.
Some
systems
will
say
that
64-bit
numbers
are
actually
the
50
something
52
bit
numbers
for
the
mantissa.
Some
will
say
that
they
should
always
be
strings,
that
they
can't
be
lost
in
any
language.
There's
just
a
lot
of
sharp
edges
when
you
include
JSON
and
64
bit.
Okay,.
K
A
A
E
E
K
K
I
don't
want
to
let
good
be
the
enemy
or
great,
be
the
enemy
of
good.
If
a
company
like
if
it
if
Amazon
wants
for
cloud
events,
it's
totally
okay,
that
the
plot
events
can
be
compatible
with
SMS
or
sqs.
It's
also
totally
okay,
that
that
the
working
group
doesn't
want
to
be
the
place
that
hosts
that
documentation.
K
E
Sqs
is
using
sqs
is
using
HTTP
and
you
can
go
and
just
map
that
on
there
on
to
their
protocol,
is
that
I,
like
I,
don't
see
necessarily
being
like,
like
you,
can
go
and
take
a
cloud
event
and
map
it
into
an
HTTP
message
and
I
would
think
that
in
the
way,
how
we're
doing
that
mapping
into
the
body
of
the
the
message
ought
to
be
compatible
with
sqs,
both
on
the
receive
and
the
sin
side.
I
haven't
I
haven't
validated
that
but
I
think
it
would
be
it
might
not.
H
Like
like,
I,
actually
like
it
have
like,
if
there
was
some
kind
of
follow-up
where,
like
I,
think
we
have
this
for
just
general
open
source
stuff.
That
would
be
like
you
know,
and
maybe
this
is
maybe
okay
I'm,
not
sure
what
I'm
confusing
two
places
but
like
if
there
was,
if
this
pointed
to,
we
encourage
vendors
to
support
plot
events
and
list
yourself
here
with
a
reference
to
your
dock.
E
Point
that
I
think
the
point
I'm
trying
to
make
here
and
so
we're
the
follow-on
piata
would
be
would
be
might
be
the
best
way
to
go,
and
some
works
with
that
particular
part
is
that
when
I
want,
what
I
want
to
express?
Is
that
not?
This
should
not
be
the
place
where
you
make
your?
You
know
your
proprietary
protocol
known
to
a
broader
audience,
that's
what
I
want
to
say
and
and
really
what
we
want
to
do.
We
don't
want
to.
E
We
don't
want
to
contribute
to
the
proliferation
of
more
proprietary
protocols
with
products
which
could
go
and
snap
to
a
standard
protocol
without
it
without
any
problem,
but
just
choose
to
use
a
proprietary
protocol,
because
it's
app
just
happens
to
be
more
convenient
for
them
or
because
they
just
want
to.
They
don't
want
to
standardize
because
they
want
to
go
and
lock
customers
into
their
into
their
new
protocol,
because
we've
seen
all
of
that
so
I
would
work.
E
H
Yeah
I
think
that,
like
I,
think
I
think
it
I
think
I
agree
with
you
like
we
did.
We
want,
we
want
I
agree.
We
want
to
promote
interoperability
and
I.
Think
that
that
is
the
spirit
of
this
paragraph,
so
I
I,
so
I
think
that,
like
I'd
move
forward
with
this
paragraph
and
then
like
you
know,
people
can
wordsmith
it
as
follow-ups.
H
A
E
For
instance,
solaar
has
it
elicits
alarm,
one
of
the
one
of
the
brokers
that
we
had
a
proposal
for
adding
a
protocol
to
has
a
completely
proprietary
protocol
holds
our
that's.
What
it
is
has
a
completely
proprietary
protocol
that
only
it
uses,
and
so
here's
the
question
of
whether
we
should
go
and
give
a
blessing
to
that
nasan's
product,
while
the
rest
of
the
pops
up
space
is
using
as
basically
convening
on.
E
You
know
one
of
two
protocols,
so
that's
an
example
of
years
of
prior
here's,
a
project
which
comes
up
with
their
own
protocol,
obviously
very
early
in
the
cycle.
That
then,
is
only
used
by
that
project.
Also,
has
you
know
obvious
things
that
protocol
a
more
mature
protocol
would
have
are
missing
like
versioning,
etc,
and
then
we
had
another
part.
E
Another
proposal
out
of
the
openness
from
from
open
messaging,
which
also
doesn't
kind
of
meet
the
bar
in,
in
my
view,
in
terms
of
participation
of
usage,
and
so
there's
there's
just
a
bunch
of
so
the
question
is:
if
we
take
twenty
of
these
things,
instead
of
kind
of
the
the
protocols
that
the
industry
has
mostly
been
focusing
on
over
the
last
last
ten
years,
are
we
helping
your
operability
and
I
don't
think
we
are
so
those
are
examples
exactly
from
here
that
I
find
problematic
for
us
to
endorse.
That's.
A
Right
any
other
comments
or
questions
on
this
one:
okay,
not
hearing
any
Thomas,
Clemens
I
have
a
question
for
you,
so
you
actually
created
a
brand
new
doc
for
this.
So
two
things:
one
is:
if
nothing
else.
If
we
keep
this
brand
new
doc,
we
need
to
reference
it
from
the
readme
at
some
point,
but
also
would
it
be
appropriate
in
your
mind,
to
move
this
into
the
primer
or
do
you
think
this
needs
to
be
a
standalone
doc,
I
I.
E
No
I
didn't
say
that
explicitly
so
the
way
I
think
about
this
is
this
is
a
section
that
ought
to
go
into
the
primer.
Okay
and
I.
Just
didn't
have
a
better
place
for
it
and
I
think
when
we
talked
about
this
Doug,
then
and
I
think
this
was
also.
We
talked
about
this
on
the
call
I
said:
I'm
gonna
go
and
write
a
PR
I'll
write
this
up
in
the
PR,
and
really
it's
meant
to
go
into
the
primer,
so
I,
don't
I
I
think
this
should
like
it.
A
We
can
do,
though,
is
assuming
the
work
group
adopts.
The
the
PR
you
and
I
can
work
offline
to
actually
modify
the
PR
data
to
the
primer
cuz,
nothing
that
the
text
of
the
PR
won't
change.
It's
just
its
location
will
be
correct
right.
So
let
me
ask
the
question:
is
there
any
objection,
then,
to
adopting
the
PR.
I
A
A
A
My
assumption
was
that
people
may
not
have
actually
had
a
whole
lot
of
time
to
review
those,
especially
in
light
of
Clemens
PR
that
we
just
adopted.
Do
people
wish
to
discuss
these
to
peers
today,
or
do
you
want
to
defer
that
until
potentially
after
next
week's
phone
call
since
next
week
will
be
about
extensions,
it's
up
to
you
guys
how
you
want
to
proceed
here?
A
E
E
So
give
us
some
advice
about
it.
At
the
episode
of
six
days
ago,
it
was
common,
so
I
think
that
PR
as
it
stands,
it
doesn't
even
define
a
transport
binding
and
it
doesn't
define
like
it
doesn't.
It
doesn't
create
a
an
implementation
guideline
for
how
you
realize
cloud
events
on
either
open
messaging,
Oh,
messengers,
native
transport.
If
there
is
one
and
messaging
is
native
encoding
is
there
if
there
is
one,
but
it
it
just
I,
don't
even
quite
really
understand
what
it
does,
but
it
kind
of
alludes
to
that.
E
E
What
I
as
I,
believe
that
the
the
wire
format
here
is
whatever
rocket
MQ
uses,
because
the
the
effort
here
is
based
on
apparently
based
on
rocket
MQ,
so
it
would
have
to
have,
would
have
to
be
effectively
binding
to
that
protocol
and
then
will
have
to
go
and
check
that
against
the
rules
that
we
just
adopted
but
like
as
it
stands,
the
after
I've.
You
reviewed
this.
This
is
not
a.
This
is
not
a
like.
That's
not
even
a
speculum.
A
E
Know
it's
if
you
look
at
open
messaging.
If
you
look
at
the
open
messaging,
the
the
the
effort.
I
only
see
three
people
contributing
an
officer
company,
so
even
if
it's
even
if
it's
running
under
the
CNC
F,
there's
there's
some
there's
some
external
contributions
that
are
being
made
by
by
folks
into
the
benchmarking
effort,
that's
running
in
the
open
messaging
group,
but
but
in
terms
of
really
the
specifications
that's
affecting
you
all,
marching
straight
from
whatever
rocket
MQ
does
into
open
messaging
and
then
rocket
and
pew
itself
is
an
effort.
E
That's
also
a
kind
of
fairly
solitary
by
what
it
looks
like
also
by
affected
by
single
forever.
So,
even
though
it's
been
politically,
it's
been
politically
smartly
done.
That
would
say
to
run
these
things
under
the
under
the
umbrella
of
Apache
and
and
CN
CF.
It
doesn't
from
for
me
personally.
It
doesn't
meet
the
bar
of
being
open
source
efforts
and
standardization
efforts
that
really
a
community-driven
okay.
This
looks
like
this
looks
like
illegal
rubber,
stamping
to
me.
Okay,.
A
A
F
F
So
obviously
I
have
a
calf
code
interest,
but
I
didn't
want
to
come
forward
and
say
anything
till
I
see
how
these
transport
bindings
kind
of
progressed
at
the
moment,
I'm
kind
of
at
a
loss
as
to
value
until
cloud
events
and
the
extensions
that
everything
gets
mapped
out
a
bit
further,
so
I'm
kind
of
just
sitting
back
trying
to
observe
how
this
is
going
to
make
sense.
At
the
moment,
with
the
transport
bindings,
and
especially
with
the
the
latter
stuff,
the
Clements
has
just
added
in
the
previous
PR.
So.
N
G
N
A
So
I'm
not
hearing
anybody
jumping
up
and
saying
you
that
they
believe
that
both
of
these
PRS
meet
the
new
bar
that
we
just
adopted.
So
what
I'd
like
to
do
is
give
people
at
least
another
week
to
look
at
these
two
PRS
just
to
make
sure
that
I'm
not
missing
something
but
I'm
getting
the
general
sense
that
we're
probably
going
to
choose
to
close
both
these
PRS
with
no
action.
A
A
A
Let's
see,
I
guess
the
JSON
format
doc
had
a
reference
to
the
JSON
schema
doc
and
they
actually
included
the
Jason
Skinner
here
itself.
So
with
that
do
people
have
any
comments
or
concerns
about
this.
I
did
actually
run
this
schema
Jason
scheme,
but
through
a
checker
it
did
pass.
Okay
I
gave
it
some
sample
Jason
to
make
sure
it
did
seem
to
catch
all
the
required
fields
and
stuff
like
that,
though,
make
sure
they
were
there,
it
seemed
like
it.
It
did
work
for
my
point
of
view.
A
N
A
E
So
one
of
the
questions
I
have-
and
that's
really
jason
schema
question,
because
I
have
to
admit
that
I
haven't
studied
that
in
and
whether
yeah.
So
that's
exactly
that
comment
that
you
just
point
you
to
whether
JSON
schema
actually
allows
if
we,
if
we
then
adopt
277
next
week,
if
we
were
whether
Jace's
schema
actually
supports
an
open
schema
model
where
you
can
go
and
add
stuff
to
the
JSON
and
then
thus
the
Jason
like.
Can
you
tell
the
JSON
schema
validator
to
to
be
okay
with
that?
E
A
A
He
beat
you
to
it
yeah,
so
that
might
be
a
good
thing
for
us
to
find
out
I'm
sure
every
one
of
us
knows
a
Jason
seen
a
person
someplace
in
our
companies.
So
maybe
people
can
go,
try
to
find
from
their
skimming
expert
what
they
think.
Okay,
but
that
definitely
something
we
should
talk
about
at
some
point.
E
A
E
A
C
You've
been
real,
quick.
This
is
Chris.
Can
you
repeat
the
exact
question
again
because
I've
actually
been
working
pretty
closely
with
the
maintainer
zuv
Jason
schema?
Oh.
E
E
A
I
A
A
A
All
right
cool,
thank
you
very
much.
Alright,
Christophe
I,
don't
believe
Christophe
is
on
the
call.
However,
he
wanted
to
add
some
guidance
on
extensions,
and
this
I
believe
applies,
regardless
of
whatever
happens
with
our
current
extension
discussion.
That's
why
I
thought
it
was
safe
to
bring
it
up
on
today
call
so
you
want
to
add
this
little
bit
of
text
here
to
the
primer
I'll.
Leave
you
guys
a
chance
to
read
it
in
case
you
haven't,
read
it
so
nail,
it's
very
short:
I.
A
A
A
H
So
I
think
that
needs
to
be
referenced
because
when,
when
I-
and
you
know
like
I'm
sort
of
coming
in
having
missed
some
of
the
calls,
but
it
it
seems
like
this
is
caught.
This
should
be
like,
if
you're
thinking
at
it,
of
adding
the
extensions
to
attribute.
Maybe
you
shouldn't
rather
than
the
number
of
extensions
attributes
and
volume
of
data
required
in
a
single
cloud
event
should
be
small
and
I
can
write
that
down.
But
I
think
that
that
I
don't
know
the
intent,
wasn't
clearly
yeah.
A
K
There's
also
like
way
way
back
when
this
was
the
open
events
group.
We
had
thought
like
tried
to
work
through
what
extensions
might
make
sense
and
just
kind
of
like
guidance
to
the
full
stack,
and
we
came
up
with
this
idea
of
it
seems
in
practice
the
data
in
a
cloud
event,
it's
easier
for
developers
if
we
reuse
existing
types
literally
like
in
client,
libraries-
and
you
know
API
specs-
that
it
be
the
viet
event
for
service.
Foo
would
include
data
type
T
of
service
foo,
but
what
happens
is
sometimes
there's
additional
data.
K
That's
only
useful
in
the
context
of
an
event,
so,
for
example,
in
a
FTP
service,
it
might
include
metadata
about
what,
whether
or
not
it
just
over
wrote
one
file
by
uploading
a
new
one,
and
it
wasn't
clear
whether
the
definition
of
what
a
file
is
should
change
and
add
additional
properties
that
are
only
ever
used
in
cloud
events
and
muddy
than
normal.
Like
request
response,
api's
or
whether
that
type
of
data
should
be
put
in
extensions.
E
K
So
what
I'm,
what
I'm
suggesting
is
that
there's
a
couple
of
these
cases
where
it's
a
fuzzy
concept
where
that
is
in
some
sense
a
I?
Did
it
about
the
events
the
data
could
be
just
like
the
class.
You
know
system
dot
file.
This
isn't
that
file
doesn't
include
a
property
that,
unless
you
describe
what
this
file
overrode,
it's
not
going
to
be
a
persistent
feature.
It's
not!
You
can't
get
that
property
when
you
just
say
list
files,
and
so
from
these
eventful
systems
perspective.
K
It
is
a
little
bit
money
and
I'm,
not
giving
guidance
I'm
just
raising
a
thought
experiment
that
never
can
we
did
from
long
ago.
It
is
a
little
bit
money
whether
or
not
they
should
edit
all
of
their
existing
classes
to
include
this
field
that
will
only
ever
be
used
in
an
eventful
format,
whether
they
should
have
a
different
version
where
it's
file
event
as
opposed
to
just
an
event
file
or
whether
they
should
just
put
eventful
metadata
about
that
file.
In
the
extensions
header.
E
K
E
K
Trying
to
step
into
your
court
and
try
to
expose
that
like
yes
on
the
they.
We
have
this
thing
that
we
call
just
bytes
or
any
urgent
like
that,
but
at
the
layer
in
the
stack
by
the
time
it
gets
into
one
of
in
Azure
customers
and
they're,
probably
going
to
program
using
a
programming.
Language
I
think
that's
a
safe
assumption.
So
let's
work
through
their
perspective
and
see
what
is
best
for
them.
Okay,.
D
Yeah,
so
a
couple
of
weeks
ago,
I
tried
to
food
what
I
should've
put
in
beta,
in
extension,
because
it
wasn't
clear
to
me
that
they
were
HTTP
headers,
actually
part
of
the
humble
of
another
message
and
I
did
not
as
part
of
a
network
or
before
that.
I
was
working
with
who
wanted
to
use
called
event
for
internal.
D
For
internal
function
still
like
using
cloud
events
to
pass
event
from
one
function
to
another
say,
put
a
cloud
event
in
sqs
and
another
Lamba
Ikeda,
and
my
issue
for
me
was
not
the
example,
but
where
details
regarding
authentication
I
wanted
to
put
that
into
the
expansion,
and
that
was
a
bad
idea.
The
effort
who
was
put
suppose
this
is
some
other
architectural
concerns,
but
the
idea
was
to
do
to
add
inside
the
data
payload
another
metadata
field
and
as
relevant
stopped
there.
D
A
Ok,
so
it
was
running
a
little
short
on
time
here,
but
I
think
a
couple
of
next
steps
on
this.
One
first
is
I.
Don't
think
we're
ready
to
accept
this
one,
yet
if
nothing
else
I
think
Sarah,
you
want
to
make
some
some
editorial
changes,
so
that
public
comment
will
come
soon.
Thomas
relative
to
your
concerns.
It
wasn't
clear
to
me
whether
you'd
like
to
see
those
types
of
changes
made
as
part
of
this
PR
or
is
that
a
piece
of
following
work?
A
K
I
have
enough
battles
and
Fighting's
I'm,
trying
not
to
put
my
foot
down
too
much
and
anything
without
caution.
I'm,
just
expressing
that
I
I
have
run
into
issues
in
the
past,
working
on
the
full
stack
problem
where,
like
it
was
reasonable
to
say
that,
maybe,
like
you
know,
like
I,
said,
the
an
FTP
server
would
have
an
extension.
K
A
D
A
N
M
A
Jinusean
you
there,
yes
I'm
here,
thank
you
and
Scott
Andrews
Scott,
and
what
about
Mark
Fisher?
Yes,
I'm
here,
okay,
Scott
last
chance
and
what
a
Doug
all
right,
cool
anybody
else,
I
missed
from
the
agenda
or
for
the
roll
call
all
right
cool!
Thank
you.
Guys
are
nice
and
please
do
take
you
get
a
chance.
Please
do
review
the
other
two
PRS
for
transports,
so
we
can
resolve
whether
those
meet
the
bar
or
not
next
week,
and
thank
you
guys
very
much
next
time.
Thanks.