►
From YouTube: CNCF SIG App Delivery 2020-04-15
Description
CNCF SIG App Delivery 2020-04-15
A
A
A
It's
a
busy
Wednesday,
but
I
am
doing
well
great.
All
right
so
today
is
April,
15th
2020
and
let
me
actually
bring
up
the
agenda
here.
Real
quick
before
we
get
started
just
keep
in
mind
that
this
meeting
is
recorded
and
will
be
available
for
the
whole
world.
To
see
so
don't
say
anything
you
can
want
the
whole
world
to
see.
A
A
There
are
some
items
that
are
going
on
in
the
background
right
now,
namely
around
SiC,
app
delivery
versus
the
working
group
serverless,
and
we
are
currently
working
those
issues
out,
but
first
up
is
a
presentation
here
from
I'm,
not
gonna,
all
right
is
it
t
or
mer
yeah
you
guys
all
right
so
I'll.
Let
you
take
over
right
now
and
thank
you.
So
let
me
stop
sharing.
C
All
right,
so,
first
of
all,
thank
you
guys
for
having
us
today,
thanks
for
allowing
us
to
present.
This
is
presentation
for
sandbox
proposal
for
the
service
work
well
specification.
My
name
is
Takumi
Rudy,
which
I
am
a
developer
at
the
breadhead,
been
there
for
11
years
and
I'm
working
on
business
automation
there.
As
far
as
CN
CF
goes,
I've
been
contributing
to
the
service
workflow
spec
for
about
close
to
a
year
now,
and
I've
also
done
couple
contributions
to
the
cloud
event
specification.
C
Just
so
you
guys
know
who
I
am
so
the
agenda
here
for
today's
talk
is
we're
just
gonna
give
an
introduction
to
what
a
service
work
for
specifications
and
the
motivations
behind
it.
You
know
get
a
couple
of
key
features
and
a
use
cases.
So
everybody
understands
what
this
project
is
about,
then
we'll
go
into
kind
of
like
the
project,
information
and
stuff
like
that,
and
then,
if
there
is
time,
of
course,
we'll
do
a
quick
demo
and
and
of
course,
any
questions
that
you
guys
might
have.
C
So
if
we
can
summarize
the
service
work
of
sophistication
in
one
sentence,
we
want
to
focus
on
then
being
a
vendor
neutral
specification
for
defining
workflow
models.
This
workflow
models
are
responsible
for
orchestrating
microservices
and
when
we
talk
about
orchestrating,
we
talk
about
coordination
and
management
on
both
services,
loosely
distribute
services,
micro
services
and
also
events
they
can
trigger.
For
example,
these
services.
C
This
slide
kind
of
want
to
get
right
into
it,
what
we
are
and
what
we're
not
in
the
top
left
corner
in
the
box.
You
see
what
the
service
work
was
specification,
provides
or
is
striving
to
provide.
The
core
of
the
specification
is
the
Jason's
key,
and
this
is
something
we
have
been
working
on
and
also
have
released
version
0.1
recently
of
the
schema,
alongside,
of
course,
a
specification
document
and
everything
examples,
use
case
documents
and
everything
else.
C
This
JSON
schema
clearly
describes
the
workflow
model
that
you
can
use
to
describe
serverless
workflows
out
of
this
json
schema.
Then
we
strive
to
provide,
hopefully
in
the
near
future.
A
lot
of
different
things
like
SP
is
AP
is
TC
case
for
conformance
purposes.
In
many
different
languages,
we
read
will
contribute
in
spi
and
java
spi.
C
But,
however,
we
have
to
wait
until
we
have
a
proper
github
structure
in
place
for
that,
so
that
is
kind
of
like
the
core
aware
the
specification
does
the
in
the
community
there
has
to
be
implementers,
so
these
are
basically
runtime
implementations.
They
can
use
the
provided,
spi,
say
an
API
to
create
a
runtime
implementations
for
the
server
service
workers.
C
They
have
to
use
that
or
create
their
own,
and
they
have
to
in
order
to
conform
to
the
specification
they
have
to
conform
to
it,
to
given
tests
in
the
TCK
and
what
we're
actually
trying
to
achieve.
The
main
goal
is
to
be
able
to
write
JSON
or
yamo,
based
which
specification
the
FIR
has
both
formats
available
workflows,
which
can
execute
on
many
different
runtimes
and
by
that
be
able
to
be
deployed
on
many
different
cloud
providers.
So
that's
kind
of
like
the
core
idea
behind
the
specification
and
what
we're
striving
to
do
now.
C
As
far
as
the
motivation
go,
why
are
we
even
attempting
this,
or
why
is
this
project
interesting
or
important?
If
you
look
good
in
this
slide,
there's
a
whole
bunch
of
serverless
work
link
the
patient's
already
in
place,
and
these
are
just
some
of
them
and
seems
new
ones
are
popping
up
every
month.
It
seems
they
go.
Of
course,
you
guys
heard
about
AWS,
Microsoft,
Azure
and
there's
a
bunch
of
other
ones
that
that
are
available
and
a
lot
of,
if
not
all,
of
the
cloud
providers
have
realized.
C
Now
again,
but
that
doesn't
mean
we
need
the
specification.
So
why
do
we
actually
need
a
specification?
The
current
user
situation
for
service
were
close
as
we've
seen
with
all
those
implementations
are
once
you
choose
cloud
provider
that
offers,
for
example,
a
service
workflow
mutation.
You
run
into
big
vendor
locks
on
both
the
workflow
model
level,
so
you
basically
stuck
with
the
proprietary
in
most
cases,
definition
of
a
workflow
definition
and
that's
also
you're
stuck
with
workflow
notation,
which
is
the
visual
or
presentation,
not
the
work
way
itself.
C
So
you
know
it's
very
hard
currently,
if
not
impossible,
to
take
your
workflow
definitions
and
moving
from
one
cloud
provider
to
the
next,
and
this
creates
this
situation
where
we
need
a
portable
and
vendor-neutral
specification.
Now,
as
far
as
the
service
workflow
specification
really
focused
on
the
workflow
model,
we
are
not
currently
looking
at
notation.
C
We
have
attempted
edit
a
little
bit
here
and
there,
but
we're
waiting
to
grow
and
have
get
a
community
in
place
before
we
attempt
to
actually
deal
with
the
notation
part
of
it,
but
we
are
focusing
definitely
on
the
workflow
model.
So
this
is
why
the
motivation
behind
a
specification-
and
this
is
why
we
believe
that
it
is
very
important
currently
given
the
situation
of
what's
going
out
there
with
service
workflows
and
cloud
providers,
that
a
specification
is
is
much
needed.
C
So,
let's
take
a
look
at
some
of
the
key
features
of
the
service,
workable
specification.
They
all
fall
into
kind
of
two
buckets
and
everything
that
we're
doing
or
adding
to
the
specification.
We
are
looking
into
these
two
buckets
and
see
how
we
improve
based
on
them.
The
first
one,
of
course,
is
something
the
workers
are
doing
and
have
been
around
for
a
very
long
time
and
what
they're
very
good
at
it's.
C
The
clear
separation
of
concerns
you
would
like
workflows,
are
really
used
to
allow
developers
to
build
their
business
logic,
their
functions,
their
services,
to
focus
on
business
logic
and
workflows.
What
they
do.
They
offload
a
lot
of
cross-cutting
concerns
such
as
parallel
execution,
so
data
management
things
like
that.
All
the
orchestration
logic
is,
this
is
kind
of
like
where
workers
are
responsible
for
at
the
same
time,
we
have
to
look
at
our
workflows
running
in
the
service
environment
and
especially
the
cost.
C
The
cost
of
running
in
service
environments
might
be
quite
different
than
in
the
typical
or
or
other
types
of
environments.
Where
closed
a
lot
of
times
are
either
charged
based
on
some
sort
of
transitions.
So
if
your
workflow
goes
from
one
state
to
the
next,
you
get
charged
a
certain
amount
of
money
or,
in
some
cases,
you're
charged
again
for
execution
time
of
the
workflow.
C
So
in
both
cases,
all
the
control
for
logic
and
the
in
the
things
that
we're
adding
to
our
specification
we're
looking
at
how
we
can
structure
those
and
build
those
to
lower
the
overall
execution
cost
of
of
the
services
running
it
now.
The
core
of
the
service
workflow
is
the
model
definition
like
I
said
we
both
support
both
Jason
any
animal
for
format,
so
we're
kind
of
machine,
readable,
understandable
and
embeddable.
C
This
is
kind
of
like
you
can
see
the
core
model
definition.
Each
workflow
has
a
unique
ID
can
have
a
name
of
version
description
and
the
court
parts
of
the
model.
Definitions
are
function,
definitions,
these
are
reusable,
is
you
can
define
and
once
you
will
look
at
specific
examples
and
their
reference
them
throughout
your
workflow
States
or
the
building
blocks?
They
execute
control
flow
logic
that
can
reference
them
and
call
different
services
were
close.
Can
both
react
to
events?
So
it's
been
stated
by
by
existence
of
events,
and
it
can
also
produce
events.
C
So
the
second
bucket
of
the
model
definitions
are
reusable
event:
definitions,
those
conform.
We
conform
to
the
cloud
events
specification,
so
all
of
our
event,
types
that
the
workflows
can
connect
upon
have
to
be
in
the
cloud
events
version
1.0
forming.
The
third
bucket
is
the
workflow
control
flow
logic
or
the
building
blocks.
We
call
them
States
currently,
and
we
will
look
at
that.
Those
are
really
the
building
blocks.
They
allow
you
to
do.
For
example,
for
example,
gateways
where
you
can
split
your
work
flow
execution
in
two
different
branches.
C
C
We
each
function
can
have
a
name
a
resource
at
a
type
so
from
the
service
workflow
definition,
you
can
really
use
a
whole
bunch
of
different
ways
of
accessing
and
defining
our
services
that
should
be
invoked
within
during
the
workflow
execution.
Now,
of
course,
we
know
functions
also
where
services
need
input
parameters
and,
since
those
are
defined
actually
in
the
state's
their
reference,
because
multiple
states
can
can
execute
different
functions
with
different
types
of
parameter.
Wrinkled.
C
C
They
have
a
type
which
has
to
match
the
cloud
event
type
parameter
source
and
we
also
use
correlation
because
within
work
for
installation
a
lot
of
times,
you
have
to
correlate
different
events
to
the
same
work,
for
instance,
for
example,
to
resume
execution
of
all
the
work,
for
instance,
or
even
start
a
new
instance
of
a
workflow.
In
this
case,
we
use
a
correlation
token.
This
is
just
within
cloud
event
specification
a
parameter
in
this
case.
C
We
use
the
applicant
ID
because
we
want
to
correlate
all
the
events,
for
example,
in
this
case,
applications
method
SATs
course
received
and
stuff
like
that
to
the
applicant
same
applicant
in
this
case,
and
in
most
likely
the
same
workflow
instance
that
handles
on
this
application
process.
That
consumes
these
events.
C
C
Each
state
of
our
service
Werfel
can
define
the
start
of
the
work,
for
instance.
So
this
is
where
the
the
start
parameter
cut
types
comes
in.
We
have
different
types
of
starts
that
we
have
currently
defined
there
expanding
on
the
default.
One
just
means
the
world,
for
instance,
is
started,
but
there
can
also
be,
for
example,
one
thing
that
we
currently
have
is
a
scheduled
work,
for
instance,
where
you
can
say
I
want
to
schedule
these
execution
of
this
workflow
in
this
particular
time
frame.
C
Next
comes
specific
parameters,
for
each
state
has
different
parameters
depending
what
it
does,
and
also
each
state
has
an
end
definition
again.
This
denotes
that
it
is
the
end
of
the
workflow
execution.
It
can
be
different
things.
It
can
be
there
to
terminate
workflow
execution,
which
means
stop
it
or
in
this
case,
in
this
example,
it
can
be
an
end
type
of
event
where,
when
the
workflow
instance
is
completed,
we
produce
a
cloud
event
which
then
can
be
consumed
by
either
services
or
other
data
indexing
or
whatever.
C
You
want
to
do
to
say,
hey
this
workflow
is
completed
or
it
can
trigger
other
instances
as
well.
If
it's
not
an
end
State
our
workflow
has
to
transition,
so
we
have
transitions
from
one
state
to
the
next,
and
this
is
denoted
with
the
transition
parameter,
which
we
defined
an
unique
name
of
the
state
that
we
want
to
transition
to
state
types
and
I'm.
Sorry,
if
this
is
hard
to
read,
we
currently
define
nine
types
of
states.
C
We
go
from
of
course,
and
we
feel
that
these
are
kind
of
like
the
core
states,
especially
for
our
versions
Europe
on
one
that
we
have
released,
we're
looking
into
adding
more
states
and
refining
the
ones
that
we
currently
have.
But
currently
we
deal
with
events.
We
have
the
core
one
so,
for
example,
the
event
state,
which
is
a
state
that
is
it,
has
ability
to
consume
events.
C
The
operation
state
is
a
state
that
allows
us
to
do
actions
and
actions
can
reference
function,
executions
switch
state,
so
we
have
support
for
gateways
which
are
data
based
so,
for
example,
given
some
information
or
data
that
is
provided
either
with
the
starting
of
the
work,
for
instance,
or
the
events
that
we're
consumed
the
event
data
can
trigger
different
actions
or
different
paths
throughout
the
workflow,
as
it's
being
executed.
Of
course,
parallel
state
allows
parallel
execution
and,
for
example,
the
callback
state
which
is
the
newest
one
that
we
added.
This
really
allows
us
to
do.
C
Integration
with
different
services
and
also
user
tests,
so
being
able
to
wait
for
a
user
decision
is
very
important.
Sometimes
during
work
look
secure
when
human
decision-making
is
important,
so
this
is
kind
and
I
like
the
core
of
the
states
that
we
have
available
in
the
in
the
specification
correctly.
C
C
In
this
case,
we
we
have
an
online
vehicle
auction
where
users
from
different
types
of
devices
mobile
web,
you
name
it
can
bid
on
vehicles
and,
for
example,
in
this
case,
the
serverless
workflow
can
be
used
very
nicely
to
orchestrate
different
services.
In
this
case,
the
authentication
service
bidding
service
and
in
an
inventory
service
at
the
same
time,
be
able
to
store
something
in
the
common
data
store.
C
As
far
as
communication
goes,
we
have
monthly
zoom
calls
and
which
happen
first
Monday
every
every
month.
This
is
the
document
where
you
can
track
our
meetings.
We
also
meet
almost
weekly
on
working
on
the
specification
primary
document,
which
is
still
ongoing
and
should
be
done
in
the
near
future.
As
far
as
github
goes
we're
currently
under
the
cnc
fwg
service.
Github
repository
in
the
work
flow
directory-
and
here
is
also
a
link
for
our
0-1
release.
They
happen
about
two
weeks
ago.
C
As
far
as
governance,
we're
consensus
in
community-driven
we're
still
a
very
small
project
as
far
as
numbers
goes
as
far
as
community
goes,
but
we're
growing
fairly
fast
and
we're
hoping
that
within
the
inclusion-
and
you
know
into
yes,
you
have
sandbox
project.
We
can
really
grow
this
community
as
far
as
owners
goes
and
ahead.
Hey.
There
word
owners,
currently
the
companies
that
have
the
decision-making
power.
C
Currently
a
redhead
Nokia
come
under
way
and
we're
looking
at
expending
that
as
well
as
far
as
license
go
we're
currently
Apache
V
version,
2.0
and
I'm
no
Brandon
burns
mentioned
in
the
tear
CPR
that
this
might
not
be
the
perfect
license
for
for
a
specification.
So
we
will
hopefully
work
with
him
on
defining
that
in
the
near
future.
To
make
sure
it's
it's
the
correct
licensing,
but
either
way
it
should.
It
should
be
open
source
completely.
C
C
Our
chat
goes,
and
we
also
started
a
blog
with
where
we
are
posting
information
in
just
community
blogs,
about
the
specification
itself.
As
far
as
TOC
sponsors
I
know,
from
the
PR
that
we
have
created,
Brandon,
Burns
and
Liz
Rice
have
raised
their
hand
to
to
sponsor
our
project
and
I.
Don't
know
really.
Somebody
can
explain
me
be
if
we
need
three
or
how
does
their
work
I
don't
know
very
well
how
there
goes.
C
C
Show
you
guys
so
what
I've
created
is
is,
yes,
we
are
doing
a
specification,
but
also
a
red
head.
What
we
have
done
and
and
will
contribute
back
to
to
CN
CF
is
actually
an
API
and
also
a
runtime
implementation,
which
of
course,
is
red
head
specific
in
this
case,
but
it's
an
first
implementation
of
of
the
serviceworker
specification.
It
is
not
bounding
bound
to
the
entire
specification
version
0.1
yet,
but
we're
kinda
getting
there,
but
for
the
sake
of
this
example,
I
wanted
to
show
you.
C
This
demo
and
I
will
go
into
presentation
mode.
What
we're
actually
doing
is
we
have
this
particular
server
list,
workflow,
which
is
called
JSON
service
call,
and
what
this
will
do
is
we
want
to
start
the
workflow
we
want
to
access
an
existing
service
in
this
case
is
the
rest
service
which
is
freely
available,
rest
countries,
dot,
EU
and
specifically
the
name
endpoint,
which
we
want
to
access
the
other
workflow.
So
this
is
our
services
Ellucian
and
get
the
list
of
current
get
information
by
the
country
that
that
are.
C
Our
input
is
for
at
that
point,
go
back
to
this.
This
simple
work,
so
this
is
the
operation
state
which
actually
calls
has
an
action
that
gets
the
country
information
all
right.
So
we
reference
the
country
info
function,
the
country
for
function.
Then
it
will
execute
the
the
particular
call
to
the
rest
service.
The
are
just
showed
to
get
in
country
information.
C
At
that
point,
it's
very
simple:
we
have
a
switch
state
which
you
can
look
at
it
as
a
gateway
and
which
has
two
choices
or
two
from
the
Gateway
and
it's
based
on
the
population.
So
if,
for
example-
and
this
is
just
for
the
test,
if
the
population
size
that
we
get
back
from
the
service,
there
is
less
than
20
million,
we
say
classified
the
population.
Size
of
this
country
are
small
or
medium
or
if
it's
greater,
we
want
to
classify
this
country.
C
Population
size
is
large
and
you
can
play
with
the
numbers
it
doesn't
matter
is
just
for
the
text.
The
classification
actually
again
calls
to
functions
or
to
services
which
store
this
information
and
they're
defined
up
here
as
well.
So,
basically,
it's
a
simple
workload.
We
just
receive
the
country
information
and
we
classify
it
and
that's
it
and
we
can
run
this
locally
and
I
will
show
you
guys
there.
C
And
what
our
implementation
does
that?
This
is
something
that
we
also
want
the
substation
to
show
the
work
loss
can
be
exposed
in
services
as
well,
and
what
the
what
really
happens
is
our
workflow
is
going
to
be
exposed
as
on
a
rest,
endpoint,
so
calling
this
rest
endpoint
and
giving
it
some
JSON.
Data
in
this
case
is
going
to
trigger
the
execution
of
the
work.
So
if
I
go
here
and
I
go
to
localhost.
C
And
we
created
a
small
little
web
page,
it's
just
an
HTML
page,
which
calls
the
HTTP
GET
for
Jason
service
call.
So
this
is
also,
if
you
see
Jason
service
call,
is
the
ID
of
our
workflow,
so
the
ideal
work
for
which
is
unique,
ID
is
actually
going
to
be
the
same
name
as
the
rest,
endpoint
that
the
work
was
exposed
for.
B
C
C
Just
finish
minutes,
so
basically,
this
clicking
on
classify
will
trigger
the
workflow
execution
passing
in
the
name
of
the
country.
Germany,
you
will
get
the
information
classify
the
population
size
is
large
and
displayed,
and
we
can
do,
for
example,
here
in
a
small
medium
and
just
to
show
you
also
just
an
example.
One
other
thing
things
we
have
done
to
show
that,
yes,
you
can
deploy
the
workforce
locally,
but
they're
also
deployable,
in
this
case
an
open
and
shift.
C
B
B
C
Everything
that
I've
shown
so
far
is
open-source
and
the
actual.
There
is
two
things
that
I
have
shown:
that
one
is
the
API,
which
is
the
actual
ability
to
parse
the
JSON
and
the
yamo
from
the
workforce
specification.
Yes,
this
that
is
completely
open
sources
Java,
and
there
is
something
that
we
will
contribute
back
to
the
project
once
we
have
like
I,
said
the
proper
github
structure
in
place,
and
we
hope
that
the
community
then
will
pick
that
up
and
help
us
not
only
with
that,
but
also
be
contribute.
B
C
Everything
that
we
do
is
open
source
but
again
I'm
not
promoting
their
runtime
implementation,
because
he
has
nothing
to
do
with
the
specification.
It
was
just
for
the
example
to
show
you
guys
something
running,
and
we
also
hope
that
more
and
more
companies,
if
they
get
involved
with
specification,
will
create
open-source
runtimes
for
it
as
well.
If.
B
C
B
So
the
reason
why
I'm
asking
specification
projects
I
would
be
different
to
to
implementation
projects
in
what
that
somebody
needs
to
implement
specification
are
busy
which
requires
it
to
be
handled
a
bit
differently,
and
if
the
goal
is
interoperability,
I
think
it's
a
good
thing
to
do.
But
I
would
really
have
this
almost
as
a
prerequisite
for
your
project
that
you
act
is
we
engaged
with
the
agro
and
brigade
folks
or
your
own
interest,
because
otherwise
you
go
build
a
specification
and
all
the
other
projects
in
the
CNCs
are
not
not
actively
using
itself
I.
B
B
I
would
propose
reaching
out
is
approaching
and
engaging
them
early
on.
So
obviously
the
MTF
might
help
you,
but
you
at
the
very
early
stage
with
the
0.1
and
I
mean
I've
done
a
lot
of
standardization
work
myself
and
everybody
recommends
getting
them
on
board
and
really
agreeing
on
the
common
prophethood
that
he
wants
us
off
with
respect
because
just
be
a
mercy
in
zf1
resolve
this
issue
for
you.
So
if
they're
interested,
if
they
see
value
in
doing
this,
they
should
see
actually
their
value
right
away.
B
So
I
know
it
sounds
required
in
your
vision.
Sandbox,
since
you
have
documents,
but
I
would
really
strongly
encourage
you
to
two
years
beforehand
because,
like
there
is
no
silver
bullet
just
by
being
in
the
CNC
after
suddenly,
people
will
magically
show
up
and
contribute
to
a
project.
So
that
would
be
my
proposal
for
YouTube
to
actively
reach
out
to
them.
Okay,
so
good
I
do
it's
I.
C
Yeah,
but
one
thing
is
yes:
we're
currently
still
small
as
far
as
community
go,
but
we
do
have
some
a
lot
of
big
companies
in
place
that
have
been
around
workflows
and
business
animation
for
years
so
that
we
have
the
advantage
of
that.
So
but
yes,
definitely,
as
you
said,
we
will
engage
and
and
and
try
to
see
you
know
where
their
leads
us
definitely.
C
B
C
That's
a
good
question
for
service
is
really
kind
of
like
a
buzz
word.
Anyways
we
describe
spiralis,
we
use
the
word
service
because
we
focus
the
niche
of
this
specification
is
to
orchestrate
serverless
functions,
and
this
is
kind
of
like
what
we're
what
the
way
service
is
used.
Yes,
there
is
some
community.
You
know
there
was
some
question
in
the
past.
Maybe
we
can
call
it
cloud
workload.
B
B
Service
like,
if
you
look
at
lambda
I
know
they
can
fly
here
just
taking
number
as
an
example,
you
know:
there's
lots
of
other
service
implementations
out
there,
like
what
payloads
I
can
expect
if
I'm,
like
writing
a
service
or
step
in
your
any
workflow
process,
you're
planning
to
standardize-
and
this
as
well
like
this
is
like
the
biggest
punch
in
it
again.
I
mean
cloud
events
define
parts
of
it,
but
they're
more
less
defined
it
raipur,
but
not
the
actual
payloads,
and
you
have
some
pain
of
components
in
there.
B
B
C
Call
the
restriction
that
we
currently
is
the
data
structures
within
the
server.
The
workflows
is
JSON
based,
alright,
so
right
now,
as
far
as
payload
goes
in
order
for
them
to
be
merged
within,
for
example,
the
workflow
context
or
the
state
data
context,
they
have
to
be
in
JSON
format.
That
is
currently
our
restriction.
That
doesn't
mean
the
data
we
send.
This
JSON
structure,
which
defines
the
data
or
the
payloads,
cannot
be
anything
basics
before
encoded
images.
C
B
As
you
see
from
an
interoperability
perspective
might
come
to
detect
on
people
as
well
and
I.
Don't
know
that
possibly
a
policy
yes,
but
they
not
hard
exactly
discussing
these
detail,
interoperability
working
group
discussed
exactly
those
details
and
how
to
name
things
that
other
parents
like
parameter
banks
along
and
there's,
also
a
lot
of
work
for
it
sounds
like
a
totally
different
field
in
the
open,
telemetry
project
like
instead
of
these.
These
are
these
and
have
like
this
David
I
start
this.
B
E
E
Now
I
have
no
further
questions.
I
think
your
is
consonant
very
meaningful
because
if
you
are
trying
to
talk
about
a
specification-
and
they
really
need
to
care
about
that,
what
can
a
feature
different
implementations,
instead
of
just
an
specification
and
I
think
for
the
discussion
around
this
talking.
Maybe
this
right,
like
one
person
and
also
I,
think
they
need
to
involve
the
service
working
group
in
the
discussion
to
see
on
their
point
of
view,.
C
C
D
E
C
We
have
we
have
we
give
status
updates
on
the
in
the
service
working
group
meetings
and
we
have
been
working
with
we're
part
of
the
group,
so
we
have
received
some
valuable
information
and
so
far
they
have
been
also
helping
us
some
with
comments
on
the
primary
documentation
that
we're
working
on
so
yeah
we're.
We
have
been
working
closely
with
with
them
for
close
to
a
year
now.
C
They
also
helped
us
summer
with
the
correlation
from
you
know:
data
firm
from
servers
from
called
event
specification,
so
yeah
we're
working
close
and
we
will
continue
working
with
them
as
far
as
being
a
subgroup
under
service
working
group
currently
yeah.
So
there
is
communication
and
you're,
definitely
looking
for
more
or
more
advice
or
whoever
is
interested
in
to
into
giving
us.
B
B
Next
one
is
a
quick
one
for
those
of
you
who
have
been
with
us
for
a
while.
We
seek
a
delivery
working
group.
There
is
a
second
round,
there's
also
an
if
you
link
in
the
agenda.
If
you
haven't
shared
your
ideas
where
you
want
just
to
go
and
provide
your
input,
please
do
so,
ideally
yeah,
but
by
the
end
of
the
week.
Well,
this
is
a
short
week
already.
So,
let's
say
by
mid
of
next
week,
so
Wednesday
next
week,
please
provide
your
input,
so
we
can
then
eventually
move
this
forward
here.
I.
B
C
B
B
D
B
E
B
E
B
Yeah
for
for
Kudo
and
operate
the
framework
I
would
ask
you
to
ping,
maybe
that
T
of
C
mailing
this
directly
with
awning
approaches,
updates
that
might
be
the
quickest
one,
video
get
it
so
for
CUDA.
We
are
still
waiting
for
the
final
decision
of
the
proceed
and
for
operator
framework
and
hub.
The
video
has
been
done
by
the
working
group
that
is
now
risk
to
see.
If
it
is,
he
has
to
decide
on
and
accept
so
yes
then
happiness
on
its
review.
B
See
so
if
not,
what
are
there
just
give
them
a
minute?
In
case
you
did
not
have
a
look.
The
air
get
working
group
and
I
will
posted
in
the
agenda
started
to
work
on
a
best
practices
document
on
how
we
do
area
deployments
and
I
thinking
right
now.
They
only
they
have
already
one
customer
example
in
there
I
think
it's
from
I
think
it's
from
great
from
crazy.
Sorry,
in
case
you
are
running
an
air
gap
environment
or
are
interested.
You
should
have
a
look
at
it.
B
D
Now
we
can
do
I
I'm
here
yeah.
We
don't
really
have
anything
like
we've.
We've
had
to
kind
of
recent
meetings
in
the
area.
Are
the
operator
working
groups
still
kind
of
working
through
the
definition
of
the
operator?
There's
some
interesting
conversations
that
happen
every
couple
of
weeks
like
encourage
anybody
who
has
an
opinion
about
what
defines
an
operator
we're
still
at
the
phase
right
now,
I'm
just
trying
to
define
what
the
operator
is
I
believe
we
have
our
next
meeting
next
week
on
this,
encourage
anybody
to
come
and
join
and
participate
in
it.