►
From YouTube: CNCF Serverless WG Meeting - 2018-02-08
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
A
A
E
G
H
A
D
A
A
D
C
A
L
E
M
A
Actually,
the
Theo
to
vanish
I
think
Theo
vanished.
Okay,
no,
no,
that
one
was
all
right.
Give
you
another
30
seconds
or
so.
Is
there
anybody
on
the
call?
Who
is
not
any
attendee
list
me
paste
the
each
end
into
the
chat
again
in
case
you
don't
have
it
there?
Anybody
on
the
list
who
does
not
have
an
asterisk
next
to
their
name,
I
think
I
got
everybody
so
far,
Oh
Joe
Scherman!
Are
you
there?
Yes,
I'm
here
excellent
Thank,
You
Chad
already
got
you
put
the
asterisk
there,
so
don't
miss
it.
A
Chris
Santa
check:
hey
there.
Yes,
thank
you,
don't
sound
so
excited
okay,
all
right
when
we
go
ahead
and
get
started,
you
kind
of
full
agenda
here.
So,
first
of
just
a
little
bit
of
warning,
we
may
actually
do
a
vote
for
the
very
first
time-
and
this
is
a
very
important
issue.
So
I
want
to
draw
people's
attention
to
it
and,
let's
scroll
down
a
little
Austin
asked
through
the
slack
channel,
should
our
official
domain
name
be
cloud
event
org
or
cloud
evencio
now.
This
is
obviously
critical
importance
to
us.
A
So
we're
gonna
take
a
vote
on
this
later
now.
The
reason
I'm
mentioning
this
now,
though,
is
because
each
company's
aligned
can't
get
it
one
vote,
and
so
you
guys
need
to
discuss
among
yourselves
which
how
your
particular
company
is
going
to
vote
so
I
figure.
You
probably
need
most
of
the
call
to
decide
that,
because
it's
so
important,
but
we've
all
probably
taking
a
boat
later
on
now,
keep
in
mind
if,
for
some
reason
you
guys
think
it's
unfair
to
spring
this
on
you
and
you
want
to
wait
another
week.
A
You
can
mention
that
it's
part
of
it
and
we'll
defer
it,
but
if
no
one
really
objects,
we're
gonna
do
a
vote
later.
So
just
think
about
that
have
to
go
through
the
rest
of
the
call
for
those
of
us
that
didn't
see
the
slack
channel.
Is
there
a
pros
and
cons
for
one
or
the
other
we're
gonna
get
to
that
later?
I,
don't
want
to
I'm
gonna,
save
the
radical
err.
A
N
The
email
is
drafted,
I've
got
authorization
codes
for
for
both
domains.
I'm
just
waiting
on
this
last
issue
of
what
domain
is
actually
gonna,
be
our
primary
to
me.
So
as
soon
as
I
could.
As
soon
as
we
get
clarity
there
I,
you
know,
emails
drafted,
I'm
gonna,
send
it
over
to
Eric
on
I've
been
chatting
with
at
the
LF
who's
gonna
handle
this
alright.
A
Okay
cool,
so
it's
almost
done
all
right.
Thank
you
and
then
just
remind
you,
you
have
two
other
outstanding
ones
that
are
in
the
backlog,
all
right
white
paper
status,
the
final
review
of
the
documents
and
the
PR
material
is
currently
under
way.
We
are
hoping
to
get
it
done
in
time
for
the
service
conference
in
Paris,
I
believe
that's
next
week,
so
hopefully
all
be
wrapped
up
really
soon
we
good
and
let's
go
ahead
and
jump
into
PR
review.
I
tried
to
order
these
based
upon,
hopefully
the
easy
ones.
A
A
K
A
A
A
Okay,
so
quick
question
for
you
guys
for
issues
like
this
or
peers
like
this
that
are
so
blindingly
obvious.
Is
there
any
objection
to
me
or
one
of
the
admins
waiting
a
day
or
two
to
make
sure
there
isn't
something?
Never
missing,
but
if
it's
something
I've
obvious
is
this
that
we
have
merged
it
or
do
you
guys
want
to
follow
the
process
explicitly
and
waited
till
this
Thursday
phone
call
I'm
like
I
like
this
to
be
able
to
just.
D
A
A
That's
fine,
but
wait
till
you
get
one
more
I
have
no
problem
with
that
all
right.
Next
one
all
right.
This
was
as
a
result
of
last
week's
phone
call.
There
was
a
request
to
actually
add
some
of
that
get
helped.
We
ran
through
on
the
call
into
the
contributing
doc
itself.
Here
I
disremember
some
trailing
spaces.
The
bulk
of
the
actual
text
is
right
here.
That
just
says
make
sure
you
sign
it
and
to
make
sure
that
this
line
and
that
line
actually
match
because
I
believe
that's
what
the
DCO
checker
is
verifying
we're.
A
H
H
L
D
B
D
A
A
Okay,
this
one:
what
do
I
do
here?
Rove
trailing
spaces,
just
added
some
information
to
our
readme
about
our
email
list,
our
slack
channel
our
meeting
times.
For
the
most
part.
This
was
just
a
copy
and
paste
from
the
main
working
groups
readme.
So
there
shouldn't
be
anything
that
you
should
me
surprises
in
here,
basically,
and
then,
of
course,
a
link
to
our
meeting
minutes,
like
I,
said
just
before
our
original
readme.
A
K
Are
adopting
it
because
I
think
it's
it's
net
positive,
but
I
think
we
should
be
a
little
careful
because
I
know
some
confusion
is
January
about
when
the
meetings
were
because
things
got
out
of
sync.
So
then,
if
the
only
changes
to
this,
we
should
think
about
refactoring
it
so
that
it's
in
one
place
but
I
think
it's
like
it's
great
to
have
documented
yeah.
D
A
G
G
K
K
I
Was
me
Thomas,
I
I,
don't
know
if
I
missed
one
of
the
meetings
words
does
clarify
better.
That's
just
been
an
open
item
where
we
talked
about,
for
example
like
minimum
entropy
or
global,
you
think
is
for
an
event.
I
know
it's
been
discussed
several
times,
I'm,
not
aware
of
any
time
we
actually
resolved.
It
must
be
global,
unique,
so
I,
don't
think.
A
A
K
L
Actually,
I
have
a
question
for
the
previous
item,
so
this
is
a
clarification
but
I.
Think
one
point
is
the
events
yeah,
so
the
event
is
uniquely
each
each
occurrence.
Maybe
you
need
to
identify
with
data
in
the
event.
I
could
be
also
identified
by
the
context
right
because
we
not
just
because
here
they
mentioned
you
know
it
include
context
and
data
I.
Remember
some
some
other
I
really
some
other
places
is.
A
L
K
I
think
that
this
is
exactly
the
point
that
I
was
it's
related
to
the
point.
I
was
bringing
up
I,
think
that
since
since
the
Edit
doesn't
change
the
meaning
I
propose
we
accept
this
and
then
whoever
wants
to
can
like
open
up
an
issue
about
the
uniqueness
question.
It's
like
I
need
to
reread
the
spec
to
really
think
about
where
uniqueness
is
mentioned,
to
propose
something
specific,
and
you
know
somebody
else
works
I
think
any
of
us
can
propose
that
we
clarify
the
universe
question.
L
A
That
sounds
good.
Obviously
it's
true
for
anything.
We.
We
approve
people
on
PRS
to
help
by
things
that
they
think
it's
needed
all
right,
so
moving
forward,
then,
is
this
about
148
yeah
make
this
can
be
read
about
there:
okay
yeah,
so
this
one's
mine,
so
this
one
just
made
it
try
to
make
it
clear
that
what
is
it
at
that
type,
then
type
version
and
schema
URL
are
all
related
to
the
information
within
the
data
property
and
that's
basically
it
that's.
K
A
A
N
N
A
A
A
We're
not
you
here,
okay,
I,
think
I
just
made
some
updates
to
our
readme.
Just
add
pointers
to
we
thought
we
read
was
this
okay,
so
this
is
in
the
main
working
group
repo
itself.
This
is
not
in
the
cloud
events
readme
just
to
be
perfectly
clear,
which
we
probably
talking
about
here.
So
what
I
did
here
is
I
added
some
links
to
our
white
papers
because
in
our
serverless
landscape
spreadsheet,
because
apparently
they
were
missing.
I
then
added
some
more
pointers
to
our
cloud.
Eventing
work.
A
Talked
about
a
I'm
sorry
provided
a
pointer
to
our
proposals
directory
where
then
later
on,
have
a
readme
that
talks
about
how
to
add
ideas
for
future
work
items.
Right,
I
talked
about
how
to
submit
a
new
proposal
by
adding
something
to
the
proposals
directory
and
then
adding
it
to
our
agenda
doc.
So
we
can
talk
about
the
next
meeting
if
you
think
it's
ready
to
be
discussed,
and
then
I
had
to
come
in
here.
A
That
said,
basically,
if
the
proposal
extends
the
scope
of
what
the
TOC
has
already
agreed
to
that,
we
work
on
that.
We're
probably
gonna
have
to
take
this
back
up
to
the
TOC
for
review
and
approval,
just
as
a
sort
of
a
foreshadowing
of
the
process,
we
were
going
to
go
through
and
then
down
here
we
have
a
list.
We
have
events
as
something
that's
already
underway,
but
that's
basically
it
it's
just
adding
more
information
to
our
main
working
groups,
repo.
J
A
L
A
L
A
L
A
J
J
A
J
So
maybe
we
need
some
some
time
down
the
road
to
say
you
know
if
you're
gonna
send
a
message
over
80
HTTP,
so
both
sides
will
be
able
to
intercept
that
you
need
to
define
how
they're
sterilizing
the
context
or
over
a
right,
you're,
MQTT,
etc.
But
the
point
is
that
in
an
API
object,
you're
not
supposed
to
to
understand
how
those
things
arrive,
because
you
were
defining
them
as
a
string,
so
you
don't
need
to
decipher
it.
J
K
I
guess
my
question
is:
if
I'm
reluctant
to
create
a
specification
where
any
event
producer
can
say:
oh
this
isn't
Jason,
and
this
is
an
XML.
This
is
in
you
know
all
these
different
formats
and
then
every
parser.
Then
every
consumer
of
those
events
needs
to
support
a
huge
range
of
different
formats
that
you
know.
Maybe
we
should
consider
that
there's
some
more
detail
on
that
that
prevents
just
fall
of
different
format.
I
I'm
also
a
little
bit
cautious
I.
It's
never
been
entirely
clear
to
me
whether
we
are
defining
logical
types,
memory,
types
or
transport
types,
and
you
know,
for
example,
with
the
firebase
SDK
for
cloud
function.
We
have
non
serializable
types
that
we
actually
exposed
the
developers,
so
we
have
like
we
take
underlying
JSON
and
construct
actual
objects
that
are
native
to
one
of
our
SDK,
which
it
seems
like
with
a
content
type
which
would
disallow
these.
J
Again,
you
need
to
look
at
it
from
a
different
perspective.
There
is
a
you
know.
Eventually,
those
event
events
need
to
be
produced
and
consumed
by
different
entities.
You
know
one
would
be:
let's
say
your
service
function,
the
other
one
would
be
someone
generating
an
event
that
an
s3
bucket
was
created
for
those
two
entities
to
communicate.
J
I
And
so
to
clarify,
I
mean
I'm
in
favor
of
actually
being
explicit
about
what
the
transfer
encoding
is
or
the
the
the
coding
of
the
object
in
transport
method,
but
I
don't
know
that
it
necessarily
I
think
that's
a
property
of
it
when
it's
on
the
wire,
not
necessarily
once
in
memory,
and
it's
not
clear
which
this
Beck
is
talking
about.
There.
J
J
You
if
you're
saying
that
you
know
for
the
Python
go
Java,
etcetera,
API
definitions,
it's
essentially
a
language
dependent
object
which
is
already
deserialized.
Then
you
don't
need
the
content
type.
This
we're
saying:
okay,
I'm
gonna
leave
the
application
to
decide
if
he
wants
to
be
sterilized
or
the
sterilized
portions
of
the
event
etc.
Then
you
would
need
some
way
to
decide
on
that
or
potentially
in
the
API
object,
if
it
even
defined
two
ways
to
consume
the
event,
one
in
sort
of
a
row
and
one
which
is
a
sort
of
disarray.
M
We
intended
you
routing
based
on
pools
and
that's
assumed
any
content,
type
routing
or
would
be
done
on
the
product
of
the
protocol
level
that
need
that.
Basically,
everything
inside
the
body
message
would
just
be
the
event
and
the
data
that
the
already
determined
the
runtime
would
use
the
object.
That's
been
our
assumption
for
a
long
time.
K
I
This
is
that
this
is
the
logical
type
which
will
translate
very
cleanly
to
a
in
memory
type,
but
we
will
then
probably
need
to
once
the
stabilisers
go
to
the
HTTP
spec,
which
means
that's
like
we
might
unroll
certain
nested
fields
or
say
extensions
are
X,
in
which
case
the
content
type
will
actually
just
follow
up
an
actor
because
content
type
is
on.
You
will
recognize
I
completely.
M
G
G
So
is
this
field
telling
me
that
if
you're
using
HTTP
transport,
then
this
is
where
you
read
the
content
type
from,
and
this
is
where
you
should
go
eventually
in
the
HTTP
header
or
if
you're,
using
a
different
transport,
then
this
is
where
you
need.
This
is
the
field
for
that
transport
target
transport,
yeah.
M
G
J
I
think
my
my
all
assumption
around
this
effort
is:
we
want
to
be
able
to
transfer
advance
between
one
system
to
another
system.
I
think
we
want
to
do
that.
We
also
have
to
define
how
to
independent
systems.
Work
I
mean
a
sort
of
interoperable
messaging
scheme.
Even
if
that
message
scheme
will
run
different
transports,
you
know
it
can.
Actually,
you
know,
work
over
Kafka
and
then
be
routed
into
Kinesis
you're
going
into
let's
say
an
Amazon
infrastructure.
That's
okay!
J
A
Isn't
it
true
that
this
content
type
is
about
how
the
data
properties
are
had?
Data
field
itself
is
encoded
which,
for
example,
may
be
in
JSON,
and
so
the
content
type
here
would
say
you
know
application,
JSON
or
whatever
it's
supposed
to
be,
but
then,
when
we
actually
transmit
on
the
wire
that
could
be
something
radically
different
like
I,
say
XML
or
something
like
that
right
they
mean.
There
are
two
different
content
types
at
play
here
and
this
one
here
is
just
about
how
the
data
itself
looks
right.
J
A
A
P
J
P
J
But
you're
saying
that,
eventually
it's
going
to
be
deserialized.
Okay
in
the
API
you're
gonna
get
things
already.
You
know
its
language
objects.
Why
do
you
need
the
schema
you,
assuming
that
the
schema
is
required
for
the
thing
that
we
see
realizes
in
order
to
form
an
a
language
objects?
It
contains
a
field
called
foo
and
you
know
whatever.
If,
if
you're
already
serializing
and
you're
saying
the
schema,
URL
is
required
by
the
guy
that
these
serializes
to
create
the
relevant
application
objects.
J
P
But
when
we
put
the
two
types
are:
aren't
we
opening
ourselves
to
the
fact
that
this
envelope
could
be
in
JSON
and
then
the
body
could
be
something
else
like
protobuf
or
something
and
like?
How
is
how
is
the
JSON
serializer
gonna
deal
with
that?
It's
just
I,
don't
I,
don't
think
our
intent
I,
don't
think
our
intent
is
to
do
the
full
end-to-end
it's
to
just
do
the
data
representation
of
the
event
itself
right.
J
I
agree
with
you:
that's
why
it's
divided
into
sections.
One
is
the
context,
we're
not
saying
how
the
schema
URL,
which
is
a
string,
how
its
transfer
it
over
the
protocol,
but
we
are
saying
that
the
event
itself,
which
have
very
different
schemas,
is
decoded,
because
there
the
context
we
don't
need
a
schema.
We
essentially
defined
here
already
how
we
serve
what
are
the
fields
and,
if
they're,
mandatory
or
optional,
so
we
don't
need
a
schema
for
the
context
field
that
will
define
it.
J
This
document,
we
don't
need
the
deserialization
mechanism
because
we
define
that
there
are
extreme
or
other
values
or
URLs
etcetera,
but
for
the
content
within
the
data,
we
need
a
way
to
decipher
it,
and
if
we
define
that
we
need
the
schema
URL
to
decipher
it.
We
also
need
to
understand
the
encoding
of
that
package.
K
You
know
I
was
thinking,
maybe
that's
the
semantics
of
the
attributes,
so
what
I
would
suggest
is
that
we
pull
out
this
conversation
into
like
a
transport
question
transport
encoding
question
right.
How
often
these
events
transported-
and
you
know
related
to
that-
is
your
on
point
on.
Then
you
know
after
transport
and
routing
and
all
those
things
how
what?
How
does
it
has
this
interpreted
by
a
runtime
and
so
I
think
this
is
a
broader
question
that
we
need
to
address.
That
contact
in
order
to
have
this
conversation
productively,
it.
O
Isn't
part
of
the
reason
for
this
PR
that
the
transport
and
the
content
encoding
of
the
transport
can
be
different
from
the
content
encoding
of
the
data
that
the
the
envelope
says?
You
know
the
HTTP
headers
or
whatever
they're
saying
this
is
the
the
entire
event
and
within
that
event
there
are
other
objects.
This
is
saying:
okay
here.
If
this
data
object,
that's
how
this
one
is
serialized
which
might
be
different.
O
K
Questions
one
is
around
the
semantics
of
you
know,
attributes
or
whatever
that
is
in
the
data.
The
other
is
how
its
encoding
and
I
think
there
are
different
people
who
make
it
making
assumptions
about
Oh
meh
today,
of
course,
that
will
be
HD
attributes
and
data.
Of
course,
that
will
be
a
host
body
or
something,
but
that's
like
a
bunch
of
things
that
we
haven't
finalized.
A
So
it
seems
to
me
we
have
two
different
conversations
going
on
here
right
we
have.
How
do
you
specify
the
encoding
of
the
data
attribute,
and
then
we
have
entire
transport
little
encoding
question
my
understanding
from
on
here
that
this
PR
is
just
about
the
encoding
of
the
data
attribute
alone
and
I'd
like
to
focus
the
discussion
on
that
and
then
have
someone
volunteer
to
take
the
issue
or
take
the
the
next
step
open
up
an
issue
or
PR
to
discuss
possible
transfer
level
discussions
right.
J
K
I
Understand
need
to
make
the
thing
that
I'm
trying
to
avoid
so
a
lot
of
us
are
worrying
about,
for
example,
HTTP
encoding,
which
I
think
we
have
some
intuition
and
is
why
we
just
assume
that
all
these
other
attributes,
in
the
context
are
no
author
encoding,
but
with
something
like
pub/sub.
For
example,
we
might
actually
wrap
an
entire
envelope
in
as
a
message
as
it
pops
of
message,
in
which
case
the
content
type
and
the
data
could
even
be
required
to
have
the
same
encoding
or
they
could
allow
double
encoding
and
I.
I
Think
that
without
actually
like,
this
is
a
hugely
important
discussion
that
we
need
to
get
a
prerequisite
out.
First,
like
we
need
to
be
able
to
say,
okay,
do
we
allow
double
encoding
in
situations
we're
actually
doing
the
envelope
or
not?
Because,
like
that's
my
main,
my
main
concern
is
it's
not
clear
yet
until
we
cover
transport,
whether
content
type
should
be
applying
to
data
applying
the
whole
envelope
or
like
does
it
depend
on
the
transport
I'll.
J
Give
you
another
challenge,
if
that's
what
you're
planning?
Let's
assume
someone
wants
to
sign
the
data
portion,
because
the
metadata
doesn't
necessarily
have
to
be
signed
because
it
may
be
generated
by
transport
or
intermediate
routers,
etc.
Let's
assume
I
want
to
sign
the
data.
If
you're,
if
we're
going
to
change
the
content
type
across
the
hops,
I
have
an
IOT
sensor
that
generated
binary
message
for
MQTT
and
I
want
to
transfer
it
to
box
up
okay,
if
you're
going
to
convert
it
to
JSON
you're
gonna
violate
the
signature
that
potentially
is
building.
A
Okay,
so
it's
let
me
let
me
do
this.
It
sounds
like
we're
knocking
builders
all
this
today.
What
I
would
like
to
do
is
take
this
conversation
back
to
the
PR
itself
and
everybody
that
has
concerns.
Please
add
comments
and
we
could
have
the
discussion
in
there.
I,
don't
think
we're
gonna
come
to
a
resolution
here,
so
I
think
people
need
to
go
off
and
think
about
it,
and
I'd
also
encourage
you
to
think
about
ways
to
split
this
up,
because
I'd
rather
not
have
a
look-see.
Are
the
choice
in
this
solve
everything
at
once?
N
A
May
be
good.
I
would
actually
recommend,
though,
that
we
first
decide
on
what
is
the
scope
of
these
properties
at
all,
because
I
think
what
I'm
hearing
this
call
is.
Some
people
thought
that
they
applied
to
the
transport
layer
and
of
guilt.
No,
they
applied
just
to
basically
what's
in
memory,
I'm
gonna
be
available
at
runtime
and
so
I
think.
There's
a
little
level
of
disconnect
there.
So
it'd
be
a
useful
someone
volunteered
to
take
an
issue
or
PR
or
something
to
help
try
to
resolve
exactly
what
the
scope
is.
Maybe
it's
both.
G
A
Have
the
grade,
okay
and
before
we
move
on
I'd
like
to
remind
people
that,
please
don't
wait
for
these
phone
calls
to
raise
those
concerns.
I
would
preferred
not
to
raise
what
I
would
call
pretty
fundamental
concerns
about
the
pr
only
during
these
calls
itself
and
this
PR
has
been
out
there
pretty
much
in
its
current
state
for
several
days
now.
So
please
try
to
review
these
things
in
advance.
To
call
that
way.
We
can
have
those
discussions
as
best
we
can
all
fine
all
right.
A
So
with
that,
let's
move
to
the
next
topic:
cat
events,
org
or
cloud
events
IO,
okay.
So
in
order
to
avoid
a
potential
rathole,
what
I
would
like
to
do
is
Oh
is
give
each
company
each
one
person
from
each
company
the
opportunity
to
speak
in
favor
of
one
or
the
other.
Only
once
and
then
we're
gonna
do
a
vote.
I'm
gonna
use
the
attendance
tracker
to
do
a
vote,
so
only
people
who
have
been
three
out
of
the
four
times
from
votes.
A
If
someone
votes
that
they
would
like
another
week,
I'm
gonna
accept
that,
because
this
says
it
is
if
they
kind
of
spring
up
on
people.
So
if
you'll
want
another
week,
that's
fine,
but
let's
go
through
that
process,
because
I
don't
want
to
rattle
on
this
too
much.
So
is
there
anybody
on
the
call
from
a
picker
company?
He
wants
to
speak
in
favor
of
one
or
the
other
cloud
events
that
IO
versus
cloud
events
org.
F
A
G
H
A
J
L
B
This
is
Chad
I'm,
obviously,
a
big
believer
in
I/o,
given
that
we
are
iron
IO,
but
it's
it
does
tend
to
be
more
startup,
be
hipper
cooler
company,
whereas
org
tends
to
be
more
open
and
it's
more
traditional.
And
if
we
want
this
to
be
widely
applied,
it
might
be
sort
of
have
a
weakly
held
opinion.
That'll
work
might
be
more
relevant
or
appropriate.
Okay.
E
A
G
A
A
A
C
A
K
Sir,
is
the
primary
in
Reichle?
Is
the
backup.
A
A
A
H
A
A
G
N
A
N
L
K
So
I
also
just
want
to
highlight
for
our
request
for
like
input,
Austin
I
got
together
last
week
and
sort
of
came
up
with
an
alternate
road
map
for
milestones.
Cuz
like
we
already
haven't,
hit
January
and
a
current
road
map,
and
so
if
people
could
just
chime
in
there's
a
Google
Doc
there
I'm
not
wed
to
whatever
it
is
it's
just
trying
to
provide
some
structure,
that's
more
based
on
named
milestones,
rather
than
dates.
A
A
F
There
was
a
kind
of
catch-all
landing
page
as
serverless
dots
against
the
f
thought
I.
Oh,
that
was
a
that's
only
gonna
redirect
that
to
a
new
route
book
called
service
landscape,
which
is
where
the
white
paper
and
the
the
competitive
landscape
would
be
I.
Don't
know
it's
kind
of
the
our
own
group
here,
but
I
guess
we'll
follow
that
up
to
chat
and
he's
like
interesting.
A
Okay,
cool
all
right,
any
other
last-minute
comments,
all
right.
So
just
a
quick
reminder:
please
everybody
review
the
PRS
and
advance
the
meeting,
especially
the
ones
that
maybe
is
a
controversy
or
require
more
deep
thought.
So
we
can
try
to
get
as
many
of
those
result
offline
as
possible.
All
right
and
I
guess
I
begin
next
week,
thanks
guys
hi.