►
From YouTube: CNCF Serverless WG Meeting - 2018-09-13
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
B
All
right
looks
like
oh:
there
we
go
203,
okay,
first
off
I
apologize
if
the
sound
quality
isn't
up
to
par
I'm
feeling
the
weather
in
this
area.
Raleigh
area
may
cause
some
problems,
but
if
not
don't
worry
about
it
anyway
does
I
mention
that
SC
going
through
the
agenda,
Austin
did
create
I,
guess
well,
I,
am
it
okay,
I'm
very
sorry,
Austin
d
create
a
doodle
poll
for
the
next
SDK
I
working
a
call.
So
please
take
a
look
at
that.
You
get
a
chance.
B
The
link
is
right
here
and
the
CH
in
the
agenda,
so
please
go
ahead
and
feel
like
your
times
in
there.
If
you
get
a
chance,
we
do
have
a
new
website
layout,
as
well
as
the
new
icons
dan.
Is
there
anything
you
wanted
to
mention
about
this?
I
just
want
to
make
sure
people
are
aware
of.
It
looks
really
kind
of
cool.
C
B
B
All
right
cool,
nothing
forward.
Ok,
so
we
do
have
a
doc
of
I'm.
Sorry,
we
took
a
doodle
poll
and
I
think
correctly
about
six
or
so
people
said
they're
going
to
show
up
for
ku
Khan
in
Shanghai.
I
did
create
a
document,
try
to
gather
a
list
of
topics
to
discuss
at
the
intro
and
deep
dive
sessions
that
we
have
for
service
as
well
as
cloud
events,
please,
even
if
you're
not
going
to
be
there.
B
If
you
have
some
ideas
for
things,
you
think
might
be
interesting
to
discuss,
add
them
to
the
doc
here.
I
figure
out
give
people
another
week
or
so
before
we
take
the
next
step
of
trying
to
group
these
things
into
what
it's
appropriate
for
intro
versus
deep
dive
and
I
will
be
looking
for
people
to
volunteer
to
actually
presents
various
topics.
It
is
only
35
minutes,
so
I'm,
assuming
we
do
have
more
than
one
person
wanted
to
talk
either
session.
We're
thinking,
car
I'm
thinking
at
most
two
people
per
session
is
about
thirty.
B
Five
minutes
will
go
really
really
fast
and
I.
Don't
think
they
have
time
to
switched
out
speakers
too
many
times.
So
and
most
two
people
per
session
so
be
thinking
about
that,
but
if
you
have
other
ideas
for
how
to
organize
it,
obviously
please
just
write
it
down
to
the
document.
I
will
discuss
it.
B
B
All
right
cool,
thank
you
guys
are
lunch
moving
forward
any
time
all
right,
a
quick
time
for
people
who
don't
normally
join
the
phone
call
who
are
part
of
the
broader
community?
Do
you
have
any
particular
topic
you'd
like
to
bring
up
for
discussion?
That
would
be
the
time.
Is
there
anybody
new
in
the
community
or
on
the
call
who
like
to
grab
something.
B
D
Hi
duck
hey
everyone
regarding
SDK
work,
there
is
a
cloud
event:
SDK
design
proposal,
I'm
gonna
paste
that
into
the
slack
cloud
events
channel
right
now.
This
is
where
we
left
off.
In
that
we
we
listed
out
all
the
initiatives
we
wanted
to
focus
on
in
the
context
of
the
cloud
event
SDK,
we
stack
rank
them
so
they're
prioritized,
and
then
we
actually
created
a
roadmap
for
different
SDK
versions
and
map
those
initiatives
to
do
a
lot
of
n
test.
D
D
We
could
I
think
we're
at
a
great
place
to
move
forward
here.
We
realized
early
on
that
extensions
is
going
to
be
something
we
want
to
consider
in
the
SDK
design
from
day
one,
because
we
think
that
extensions
is
where
the
community
is
really
going
to
hook
into
the
specification
it
is
in.
The
ability
for
vendors
is
in
the
ability
for
the
open-source
community,
as
well
as
organisations
who
are
implementing
odd
effects,
their
ability
to
create
their
own
extensions
to
do
more.
D
What
the
cloud
event
spec
is
super
important
and
we
think
that,
having
a
great
time
into
the
SDK
for
extension,
is
a
great
story.
There
will
really
help
boost
community
growth
overall.
So
now
that
we
have
some
clarity
on
that,
we
can
figure
out
how
to
actually
make
that
work
and
I.
Think
that's
gonna
be
one
of
the
conversation
topics
for
the
next
SDK
call.
That
is
okay.
D
What
is
extensibility
via
extensions
look
like
in
the
SDK
and
how
does
that
work
with
what
we've
decided
as
to
how
extensions
work
with
the
specification
so
that'll
be
one
thing
we
need
to
clarify
on
the
next
call.
However,
everything
else
is
pretty
well
defined
and
I
think
we're
just
going
to
continue
to
seek
volunteers,
to
do
some
implementation
and
then
check-in
to
see
what
has
already
been
implemented
but
I
think
that's
it
off
the
top
of
my
head.
Does
anyone
have
any
questions
about
the
SDK
efforts
so.
E
Not
really
I
think
we
are
they.
We
merge
the
first
draft,
and
so
if
people
have
on
time
can
go
and
take
a
look
and
give
comments
or
poor
poor
new
PR
yeah.
That's
pretty
much
about
it.
Oh
cool.
F
G
F
G
B
H
B
G
Well,
I
think
it's
all
tied
up
together,
like
I
I,
do
think
that
like
if
we
decide
that
we
want
to
accept
specs
from
from
any
technology
that
is
owned
by
private
company,
then
that's
one
thing:
if
we
decide
that
we
don't
that
we
have
a
different
stare
and
that's
another
thing.
We
should
just
decide
one
way
or
the
other
well.
A
I
actually
think
it's
not
formal,
because
both
Bazaar
and
open,
so
polls
are
runs
under
Apache
Apache,
Software,
Foundation
and
messaging
runs
under
the
Linux
Foundation,
so
they
both
qualify
her
for
the
the
running
under
the
umbrella
of
foundation.
It's
just
the
question
for
those.
The
question
is
a
different
one.
Is
that
do
they
actually
have
uptake
and
that's
and
that's
a
different
thing,
there's
a
so
that
we've
been
having
these
two
discussions
that
are
separate.
A
B
B
B
A
A
It
is
only
I,
only
know
of
it
being
implemented
in
rocket
in
queue.
So
that's
one
project
and
then
then,
that's
actually
being
contributed
to
only
by
effectively
one
company
and
so
I
find
this
friendly
and
that's
my
perspective,
the
reach
of
either
to
be
constrained
to
the
particular
project
and
that's
not
going
to
further
and
drop.
B
B
Take
the
AI
to
put
a
comment
in
both
the
RS
asking
them
to
to
explain
why
they
think
they
meet
the
minimum
bar
either
as
it
currently
stands,
or
with
the
changes
that
being
proposed
by
Sarah
and
her
pull
request,
and
if
they
either
don't
come
back
to
us
by
next
week,
or
they
don't
give
us
convincing
arguments,
then
I
think
it
might
be
fair
to
push
for
some
sort
of
decision.
Does
that
sound
fair
to
people.
B
B
B
Forward
then
Kathy,
your
PR
is
next,
bring
it
up
here,
all
right.
Just
so
you
guys
know.
While
there
were
some
changes
made
yesterday
in
this
per
request,
I
believe
they
were
simply
typographical
or
syntactical
in
nature.
They
were
not
changing
the
semantics
of
what
Kathy
was
looking
forward.
That's
why
I
feel
comfortable
asking
people
to
look
at
it.
For
the
most
part,
her
text
just
moved
to
a
different
spot
in
the
spec.
The
text
itself,
for
the
most
part,
really
did
not
change.
B
B
B
E
Please
know
158,
so
158
is
talked
about,
there's
no
restriction
on
the
format
and
the
type
of
semantics
of
the
extension
attributes,
and
this
one
is
talk
about
that.
You
know
we
even
producer
can
add
additional
attributes.
In
addition
to
was
defined
in
the
current
spec
and
then
specifically
to
give
example.
E
Some
example
like
why
you
know
what
kind
of
just
example,
what
kind
of
additional
attributes
can
be
added
to
enable
support
for
more
on
use
for
some
service
use
cases
which
I
you
know
presented
the
other
day
for
the
correlation,
and
also,
of
course,
what
sentence
said.
You
know
these
articles
will
be
used
or
for
for
routing
purpose
and
other
purpose,
which
people
has
you
know
as
have
suggested
before
yeah,
so
there.
This
is
this.
They
serve
different
purpose.
H
B
B
Of
it
was
sometimes
it's
useful
in
specifications
to
give
a
little
more
concrete
examples
to
help
clarify
how
the
spec
authors,
weren't
thinning
things
to
be
used
and
I,
think
I.
Think
Kathy
was
looking
at
this,
as
as
as
one
of
those
cases,
at
least
that's
my
interpretation
of
it.
This
extra
this
extra
exactly
this
helps
provide
clarity.
A
K
So
so
it
doesn't
hurt,
but
how
does
it
help?
Maybe
that's
the
question
yeah,
if
your
extensions
allow
stuff
to
be
transported
and
if
I
knew
what
those
were
I
could
route
on
them.
Yeah
is
there
stuff
more
in
this
example,
somewhere
there
describes
a
proposed
mechanism
for
standardizing
the
way
that
those
sort
of
correlations
would
be
represented.
E
This
one
does
not
like
you
know,
propose
you
know
how
those
correlation
would
be
standardized
it
just
a
given
example,
and
so
this
just
said
you
know
the
even
producer
can
include
additional
context
attributes
and
those
attributes
are
not
restricted
to
a
need
to
either
Cartesian
or
routing
it.
Just
you
know,
give
some
examples
which
you
know
on
the
correlation
route
in
which
has
been,
and
this
issue
has
been
raised
and
discussed
multiple
times.
You
know
previous
meetings,
so
I
think
he's
good
clarify
here.
E
Otherwise
we
have
to
revisit
these
issues
again
again,
but
those
are
just
examples,
I
think
the
general
property
just
said.
You
know,
because
it's
extension
attributes
right.
So
people
can
add.
You
know
the
I
mean
the
even
producers
can
add
additional
contrast
attributes
when
they
for
their
when
they
see
that
it's
going
to
help
actions
relate
to
the
processing
of
the
event,
just
to
clarify
that.
K
B
H
A
H
L
Yeah
I'm
very
strongly
about
having
this.
In
a
blog
post,
a
blog
posts
may
get
old
or
outdated.
I
would
much
rather
have
time
in
a
single
place,
which
is
the
spec
and
more
events,
and
probably
blog
posts
will
be
up
as
soon
as
the
SDKs
all
ready
and
more
and
more
people
start
using
cloud
events
yeah.
B
And
keep
in
mind
we
could
also
choose
to
to
to
make
changes
to
the
spec.
We
have
some
point
when
you
look
at
this
and
say
no
one
sees
that
this
is
needed
anymore,
right
and
they'll
get
used
to
remove
it,
but
for
as
it
right
now,
it's
clear
that
at
least
to
me
that
some
people
do
think
this
text
is
needed
and
therefore
I'm
going
to
opt
on
the
side
of
caution.
J
A
J
This
this
example
extension
information
should
be
in
a
slightly
less
prominent
space,
so
the
the
the
following
data
on
1x
done
158,
for
example,
is
part
of
the
the
total
kind
of
definition
of
these
things,
and,
and
so
it
seems
like.
Maybe
the
examples
of
extensions
that
people
might
want
to
use
should
follow.
After
that
complete
declaration.
B
I
think
what
are
you
suggesting
is
that
whoops
perhaps
take
this
text
and
put
it
down
here
on
line
171,
because
the
more
I
think
we're
suggesting
is
that
an
example
type
language
perhaps
should
go
after
we
talk
about
the
the
topic.
Basically
right
topic
here
is
extension,
so
talk
about
extensions
from
a
more
spective
and
then
and
then
end
it
with
an
examples.
I
think
what
he's
suggesting
do
I
have
that
right.
That's.
E
G
G
E
E
E
B
Why
don't
you
go
to
make
those
okay?
Let
me
ask
this:
if
we
were
to
make
those
those
changes
that
were
proposed,
the
stuff
in
the
chat
from
Doug
and
Christophe,
and
moving
the,
for
example,
text
to
be
after
my
round
line
171
then,
are
people
okay
with
those
sets
of
changes,
and
so
could
they
accept
the
PR.
L
B
B
H
All
right,
if
you
like
to
talk
to
this
one
Thomas
sure
this
is
just
a
thing
that
we
covered
a
handful
of
times.
People
often
suggest
like.
Oh
clearly,
you
need
routing
information
and
like
yes
in
a
holistic
system,
you
eventually
need
to
know
what
the
event
goes.
However,
we
believe
in
separation
of
concerns-
and
we
have
found
through
plenty
of
time
working
the
space
that,
when
you
encode
the
destination
of
the
message
in
the
message
itself,
it
ends
up
being
a
really
bad
idea.
H
It
is
not
that
we
have
merely
overlooked
it
in
the
spec.
It's
that
we
proactively
have
investigated
this
topic
and
found
out.
We
disagree
with
its
use,
so
this
is
kind
of
explaining
a
case
where
we've
chosen
not
to
do
something
and
why
which
hasn't?
Let's
do
it,
because
without
this
prose
it
has
come
up
a
few
times
I'd,
like
some
connectors,
referred
to
it's
like
by
the
way
we
explicitly
cut
this
out
of
this
back
or
emitted
it
from
this
back
yeah.
H
I
can,
if
someone
has
suggestions
in
the
wording,
I
think
that
that's
fine,
this
I'll
go
back
to
that.
That
point
I
said
earlier
that,
like
clearly
in
a
holistic
system,
you
need
to
know
where
to
deliver
the
message,
so
you
need
the
attributes
required
in
order
for
an
application
to
implement
routing.
However,
if
the
event
itself
dictates
the
routing,
then
it
couples
it
with
the
actual
application
or
invitation.
So,
for
example,
you
know-
we've
talked
a
number
of
times
about
labels.
Labels
are
very
very
different
than
saying
here's,
your
explicit
topic
or
explicit
sharky.
H
They
can
be
used
by
an
application
to
say:
oh
I
would
like
to
shard
on
this
label
or
the
resource
tree
or
sorry.
The
source
string
words
like
that,
but
we
haven't
dictated
in
the
event
message
that
this
is
the
final
destination
of
the
message.
This
is
the
sharding
key
for
this
message
or
that
guys
yeah.
B
G
A
So
so
the
way
I
see
that
objection
is
going
back
to
the
discussion
we've
had
about.
You
know,
subject
topics
and
sources
and
beginning
where-
and
this
is
called
out
in
the
proposed
change.
Let
me
just
erase
it
again.
You
can
see
the
concept
of
topic
either
as
a
as
a
thing
which
is
kind
of
the
concrete
entity
in
a
message
broker
or
that
you
want
to
go
and
send
stuff
to
that's
one
way
to
look
at
it,
the
other.
The
other
is
to
go
and
look
at
a
topic.
A
You
generally
have
this
notion
of
a
you
know,
a
topic
of
sorts
that
you're
sending
broad
sets
of
events
into
or
via
that
Lane.
That
then,
will
be
further
routed
based
on
the
criteria
that
we
have.
So,
even
if
you,
if
you
look
at
Kafka
or
if
you
look
at
you,
know
most
of
the
message
workers
that
we
haven't
used,
you
send
data
down
the
channel
or
pipe
or
top
people.
However,
that's
called,
but
then
kind
of
any
differentiated
subscriptions
are
being
made,
then
on
the
properties
and
metadata.
A
H
For
example,
in
the
HTTP
web
hook,
spec
you
proposed
there
was
never
a
reason
for
the
HTTP
spec
to
include
like
oh,
the
message.
Data
should
have
the
destination
in
the
routing
information
no
HTTP
handles
and
the
application
that
set
up
the
HTTP
web
hooks
is
probably
stored.
The
way
books
of
our
one
of
the
big
concerns
is
like.
H
Yes,
of
course,
there
is
some
optimum
structure,
a
coffee
topic,
but
you've
actually
been
a
champ
for
these
Multi
multi
stage
pipelines
with
IOT
devices,
and
you
have
you
know
one
robot
that
sends
something
to
a
nexus
in
a
factory
which
sends
things
to
commence,
and
there
may
be
a
regional
one
which
goes
up
to
a
global
thing
and
that
Kafka
topic,
our
public
topic,
is
only
a
really
relevant
or
I
should
say.
It's
only
really
true
in
one
hop
yeah.
A
So,
if
we're,
if
we're
disallowing,
it's
disallowing
that
that
extra
step
there
is
kind
of
a
filter
opportunity
that
you
have.
That
is
probably
not
there
I'm,
not
sure
when
the
source
represents.
That
represents
it
completely
in
mice.
I
just
want
to
say,
I
just
want
to
say
that
that's
it,
because
the
topic
this
tops
our
topic
may
quite
well,
not
to
you
know,
logically,
map
to
the
concept
of
source.
A
K
K
I
read
that
the
way
that
you
guys
had
defined
the
structure
of
that
that
looked
to
be
something
that
I
would
use
to
do
that
sort
of
routing
or
propagation
on
and
similarly
combining
that
with
the
source
information
to
do
additional
filtering
yeah,
so
I,
never
I,
I,
guess
I
read
into
the
spec
that
that
event
type
would
could
be
used
in
that
fashion
and
that's
separated
from
a
you
know,
a
topic
or
a
queue
in
a
typical
messaging
infrastructure.
So
after
Thomas
after.
B
N
Yeah
I
would
probably
even
go
further
than
this
does
I
think
the
whole
distinction
between
payload
and
metadata
is
is,
basically,
people
are
going
to
wrote
on
whatever
fields
they
want
to
they're
going
to
filter
on
whatever
fields
they
want
to.
Once
you've
sent
the
message,
you
know
you're
piñon
about
what
is
roading
and
what
is
tit.
It
doesn't
matter
right
the
people
who
get
it,
who
receive
it,
get
to
make
that
that
distinction.
N
H
Sure
sure
now
I
can
jump
in
I
will
express
money
thanks
to
the
previous
speaker
as
well.
I
forgot,
the
name
I
do
appreciate
fresh
points
of
view,
since
it
feels
like
we
just
have
a
rating
click.
I
I
am
not
naive
on
the
idea
that
people
will
Bend
and
abuse
the
speck
from
our
point
of
view
as
much
as
possible.
I
do
think,
there's
a
difference
between
saying
we
know
people
are
going
to
use
these
fields
as
routing.
H
We
could
even
add
into
this
section
that,
like
sums
some
suggested
or
observed
ways
that
people
have
implemented
routing
on
top
of
the
fields
we've
already
had
versus
saying
this
is
shard
ID.
This
is
topic
name
I
mean
like
clearly
routing
used
to
happen
somewhere,
there's
a
difference
between
being
prescriptive
in
in
the
spec
about.
We
believe
that
this
is
the
routing
key
or
that
there
should
be
one
explicit
one
and.
G
G
G
B
Off
the
face
of
the
earth,
so
what
I
was
saying?
I,
don't
think
we're
ready
to
definitely
vote
on
this
because
it
sounds
like
there
was
more
discussions
need
to
happen
unless
completely
misinterpreting
it
I
think
we
should
push
this
back
and
say,
discuss
this
more
in
the
PR
itself.
H
K
K
If
I'm
reading
between
the
lines,
its
you'd
really
don't
want
to
encode
transport
specific
stuff
in
that
header,
and
that
that
seems
that
I,
that's
who's
basically
correct
to
me
and
what
I'm
not
quite
sure
on
is
why
what
drove
you
to
have
to
make
these
sort
of
clarifications
yeah,
that
maybe
this
is
similar
to
the
previous
PR,
where
you
sort
of
adding
commentary
or
clarification
to
something
that
the
way
I
read
the
spec.
It
didn't
need
to
be
there,
but
but
that
maybe
just
make
okay.
A
B
A
A
So
I
agree
with
the
intent
of
not
including
direct
addressing
information
into
the
event,
like
the
event
should
never
say
exactly
well
wants
to
go,
but
there's
a
concept
like
like
a
topic
is
it's
fairly
abstract
and
it
doesn't?
It
doesn't
really
tell
where
to
go.
It
just
tells
you
that
there's
an
indirection
point
where
you
then,
whether
message
from
it
gets
routed
from
and
then
the
other
thing
is
that
partition
keys
is
something
that
is
also
that
it
has
a
similar
function.
It
helps
it.
A
Aids,
routing
and
routing
is
something
that
we'll
have
to
do
and
having
aid
based
routing
aids
in
the
message
is
something
that
I
would
rule
out
as
a
as
a
matter
of
principle,
I
would
I
would
certainly
say
a
target
address
is
something
that
I
would
we
should.
We
should
preclude
as
a
matter
of
principle,
but
that's
how
far
I
would
go.
Okay,.
H
I
think
go
ahead.
Tell
me
sign
well,
thank
you
for
the
feedback.
I
will
try
to
clarify
it.
A
little
bit
more
I
actually
had
the
honor
of
getting
to
talk
to
a
couple
of
customers,
particularly
when
it
Nordstrom,
who
you
know,
has
really
really
been
investing
in
platinum
structure
and
eventing
infrastructure
thoughts.
Whether
use
cases
were
very
informative
here,
where
they
talk
about
events,
for
example.
Maybe
that
someone
walks
into
store.
They
pick
up
a
dress,
they
buy
the
dress,
and
that's
particularly
you
know.
H
One
of
the
reasons
why
we
might
have
a
shard
key
is
to
choose
the
scope
at
which
you
must
only
process
one
event
at
a
time
or
process
them
in
order.
It
was
very
interesting
about
their
use
case
was
that
even
they
in
house
have
different
consumers
who
need
to
see
the
scope
in
a
particular
order.
So,
for
example,
you
might
say
that
you
need
to
see
all
events
in
order
where
the
shard
key
effectively
the
ordering
key
or
the
key
parallelization
is
a
store
versus,
is
a
tailor.
J
H
Is
even
like
a
category
of
fashion
and
thence?
That's
again,
part
of
the
point
of
what
I
was
trying
to
say
here.
Is
that
the
absolutely
we
should
have
the
ability
to
shard
our
data
and
process?
In
parallel,
absolutely
we
should
have
the
ability
to
put
data
over
pubs
over
Kafka
or
whoever
else.
The
concern
was
that
systems
like
when
you
look
at
a
system
for
the
first
time.
You
may
not
see
the
value
and
having
separate
moving
parts
here
and
that
may
be
the
transport
orchestration
layer.
B
And
I
just
want
to
point
out
that
the
talk,
the
text
that
we're
talking
about
here
is
actually
not
for
the
spec.
It's
for
the
primer
to
provide
guidance
for
people
or
I'm.
Sorry,
information
for
readers
to
understand
the
some
of
our
motivations.
So
there
is
technically
nothing
normative
about
this
text.
This
would
not
preclude
anybody
from
adding
any
other
attribute.
They
want,
including
information
if
that's
what
they
choose
to
do.
B
B
B
B
I
know
that
some
of
the
Texas
was
changed,
I
think
maybe
three
or
four
days
ago
camera
how
long
ago,
but
I
want
to
get
out
there
front
of
you
guys
and
see
what
you
guys
thought
keep
mind.
This
is
just
an
extension:
it's
not
part
of
spec,
so
the
bar
is
technically
lower
than
normal
attributes
that
go
in
the
spec,
so
we're
out
looking
for
absolute
completeness
or
perfection
here,
just
whether
it
seems
like
it's
good
enough
to
say
yeah.
This
might
be
interesting
for
people
to
play
with.
I
B
B
So
you
can
look
at
this
as
two
different
things,
one
as
a
testbed
for
properties
that
may
one
day
want
to
include
the
specification,
so
they
could
use
this
to
sort
of
prove
their
worth.
One
way
to
look
at
it.
Another
way
to
look
at
this
is
to
have
a
common
location
where
people
can
collaborate
on
these
extensions
in
just
a
will
known
location,
even
if
they
don't
initially
become
part
of
the
formal
spec
itself,
rather
than
having
popular
extensions
spread
out
across
the
entire
internet.
B
H
H
The
idea
I
tried
to
justify
the
idea
originally
of
documented
extensions
or
well-known
extensions
from
the
JWT
spec,
which
actually
does
have
this
trichotomy
as
well,
where
they
they
have
a
place
where
you
could
submit
your
extension,
because
auth
is
another
place
where
Interop
is
pretty
key
and
then
I
guess.
The
third
reason
is
there's
a
couple
of
things
that
we
really
like
like
tracing
where
we
just
don't
want
to
be
kingmakers.
H
There
are
a
lot
of
good
tracing
attributes
and
it
just
it
would
make
sense
putting
it
in
kind
of
a
secondary
section,
say
hey
by
the
way
we
figured
out
how
you
plug
into
open
tracing,
but
we
wouldn't
want
to
say
that
open
tracing
is
better
than
some
other
tracing
framework.
So
here's
what
we
recommend
with
how
you
plug
in.
I
Okay,
so
that
all
makes
sense.
Just
question
was
the
bar
for
documenting
a
particular
extension
versus
not
documenting
it.
I
mean
like
this
is
similar
to
discussion
you
had
before
about
which
protocols
apply
and
which
protocols
don't
apply.
So
does
it
have
to
pass
a
certain
bar
before
we
decide
recommended
or
any
extension
that
anyone
wishes
to
add
to
the
spec
shall
be
documented,
I.
B
Yeah,
it
might
be
useful
just
to
add
some
to
language
in
here.
That
explains
why
we
chose
some
over
others
at
some
point,
I'm
sure
someone's
can
propose
something.
We're
gonna
just
gonna
say:
oh
gosh,
no,
all
right,
I,
don't
know
what
that
would
be,
though,
but
we
should
at
least
have
some
bar.
So
it's
not
just
completely
subjective.
H
And
then
I
think,
even
along
with
that
bar,
we
can
say
basically
what
the
whole
scrutiny
we
plan
to
to
put
in
here.
I
think,
frankly,
at
some
point,
because
it's
an
extension,
we
can
give
editorial
opinions
on.
Oh,
we
think
you're
doing
this
wrong,
but
it
really
doesn't
matter
as
much
because
there's
two
consenting
parties
that
would
like
to
use
some
data
in
exchange
and
they
explicitly
didn't
ask
to
put
in
the
course.
H
That
text,
it
would
take
me
a
couple
weeks
to
get
the
time
to
do
so.
So
yes,
if
everyone's
okay
with
that
taking
like
about
two
weeks,
minimum
yeah.
I
I
H
B
G
E
Have
a
question
on
this
PR
so,
for
the
sequence
is
for
the
same
and
the
sequence:
the
order
of
the
event
from
the
same
event
source,
so
that
if
that
event
is
too
bleak,
I
mean
so
so
this
in
box
are
from
the
same
event,
source
right.
It
could
emit
a
No
duplicate
event.
Is
this,
for
that?
Is
that
counted
as
a
sequence,
number
or
I.
B
I'm,
not
the
expert
on
this
I
only
wrote
it
up
to
to
move
the
ball
forward.
I'd
like
to
get
the
people
who
actually
were
really
promoting
this
to
respond
and
I,
don't
want
it
I,
don't
think
I.
Do
it.
Justice,
Jim
I,
try
to
respond
right
now;
okay,
so
that's
good
thanks,
okay
and
so
Thomas.
Since
you
said
it's
gonna,
take
you
four
weeks,
I'm
assuming
you're,
okay,
that
if
someone
does
have
time
before
then
to
try
to
draft
some
texture.
Okay
with
that
I'm,
always
okay
with
people
do
my
work,
I
assume
so!