►
From YouTube: OpenStack DefCore Community Meeting #1 2015-4-21
Description
Review current DefCore status and ask for community to review.
Presentation: http://www.slideshare.net/rhirschfeld/community-defcore-presentation
A
B
A
The
so
x,
dekka
join
me
at
the
beginning
of
the
year
for
this
execution
phase
for
deaf
core
and
so
I'm
going
to
lead
the
presentation,
then
we'll
both
take
questions
for
the
end.
I
have,
I
think,
twenty
slide,
so
forgive
me
for
moving
quickly,
I'm
going
to
assume
that
you
haven't
heard
anything
about
what
that
core
is
now
and
will
address
those
questions,
but
there's
a
very
clear
call
to
action
for
us
in
the
in
this
and
once
again
will
record
this.
A
A
There's
a
very
specific
call
to
action
here
and-
and
so
let
me
give
you
a
little
background
in
Vancouver,
so
in
about
a
month
we're
going
to
be
approving
the
official
that
process.
That
process
has
been
under
discussion
and
review
for
actually
over
18
months
in
last
18
months,
we've
spent
a
lot
of
time
doing
principles
and
guidelines
and
sort
of
figuring
out
why
we
were
doing
this
and
what
was
important.
The
process
that
we're
asking
people
to
review
now
is
about
how
we
do
it.
A
It's
very
nuts
and
bolts
these
people
do
this
at
this
time.
In
order
for
you
to
review
that
and
give
us
input
about
it,
you
need
to
understand
what
our
objectives
are
with
deaf
course,
so
we're
going
to
spend
some
time
giving
you
background
about
what
deaf
core
is.
What
core
is,
why
we're
doing
it?
How
it
actually
has
a
real
material
impact
in
the
OpenStack
community,
and
when
we
asked
for
for
comment
comments
is
not
just
I,
don't
like
things.
A
Obviously,
part
of
our
community
needs
to
be
able
to
affirm
that
this
is
the
right
thing,
so
we're
asking
for
feedback
to
improve,
but
also
feedback
to
endorse,
and
then
at
the
end
of
this
presentation.
Hopefully,
you'll
have
enough
to
be
an
informed
reader
of
that
20.
What
we
call
the
2015
a
process.
A
So
starting
really
simple,
def
core
and
we
chose
def
named
f,
qor
intentionally
because
it's
something
that
is
googleable
unless
you're
into
very
loud
music.
It's
the
only
other
reference
for
deaf
corps
de
AF
score,
and
it's
important
to
understand
that
when
we
talk
about
core
in
this
case,
there's
three
places
where
we
have
open
stack
of
the
community
has
used
core
we're
really
only
covering
one
of
them.
So
people
talk
about
community.
C
A
Around
the
openstack
they
talk
about
OpenStack
and
they
create
OpenStack
meetups
and
things
like
that.
That's
perfectly
fine,
that's
a
use
of
the
OpenStack
mark.
They
talk
about
code,
so
the
OpenStack
code
is
in
itself.
You
know,
there's
a
much
broader
body
of
code
in
OpenStack
and
projects
in
OpenStack,
an
activity
and
OpenStack,
then
deathcore
will
cover
it's
really
focused
on
the
commercial
use
of
brand.
So,
very
specifically,
when
somebody
says
they
have
an
OpenStack
product.
A
Def
cores
is
the
way
the
foundation
measures
and
governs
that
use
of
the
mark,
and
it's
very
important
for
OpenStack
to
control
its
mark,
because
we
don't
want
OpenStack
to
be
deluded
as
a
brand.
It
needs
to
mean
something
specific
in
order
for
four
tet
value
for
the
community
and
also
for
it
to
have
value
for
the
vendors
and
the
foundation
itself.
A
When
somebody
says
they're
an
OpenStack
product
and
the
goal
has
been
for
quite
a
while
interoperability
so
that
if
you
have
to
OpenStack
clouds
from
two
different
vendors
or
to
OpenStack
public
clouds,
that
they
should
have
a
degree
of
high
degree
of
interoperability
and
open
sex
should
be
reliable,
they
should
be
tested,
it
should
have
a
common
implementation
and
then,
very
importantly,
we
don't
want
to
impede
growth
and
innovation.
So
we
have
a
balance
between
stability.
B
A
This
is
the
starting
point
in
the
Deaf
court
process,
where
we
sort
of
define
the
principles
by
which
we
were
going
to
make
these
decisions.
Things
like
there
was
going
to
be
a
common
definition
of
OpenStack
that
we
would
allow
people
to
substitute
parts
of
the
code
but
require
other
parts
of
the
code
and
then
that
we
would
use
tests
to
validate
what
OpenStack
was
to
the
point
where
we
would
say
there
were
some
tests
that
you
must
pass
to
be
an
openstack
cloud
and
that
vendors
could
test
it
by
themselves.
A
So
all
these
these
sort
of
base
principles
were
outlined
by
Hong
Kong.
If
the
Hong
Kong
summit
are
approved
at
the
Hong
Kong
summit,
and
then
we've
been
marching
towards
to
finding
a
process
that
embodies
these
programs
and
what
that
ends
up
looking
like
is
something
we
built
sort
of
out
of
these
nine
points.
A
So
the
community
part
of
this
looks
like
a
right
test
or
truth
is
very
important
to
us,
but
not
only
tempest
that
it's
important
that
there
are
helping
fact
paths
but
we're
working
to
expand.
What
the
scope
of
that
means.
It's
one
of
our
active
discussions
for
our
next
review
cycle,
but
we're
talking.
B
A
Building
an
inner
up
map,
so
we
want
to
find
which
capabilities
are
important
to
the
community
and
widely
used.
Those
are
the
ones
it
should
be
become
core.
We
expect
the
community
to
be
the
one
writing
test,
so
we're
placing
a
high
premium
on
people
who
contribute
tests
and
making
the
test
valuable
and
then.
A
To
create
capabilities
out
of
the
test,
so
it's
not
just
a
single
item
test,
but
something
that
people
can
understand
at
a
higher
level.
So
capabilities
have
been
very
important
based
on
groupings
of
tests,
the
testable
capabilities,
the
vendors
in
this
case
have
responsibilities.
Also
they
actually
run
the
tests.
A
We
are
not
a
police
state
we're
not
trying
to
create
a
certification
agency,
so
we
expect
the
vendors
to
be
self
policing
and
because
we're
using
community
resources,
users
can
validate
the
vendors
pet,
clear
pass/fail
results,
transparent
reporting,
and
we
do
have
a
way
that
the
vendors
can
say,
wait
a
second.
This
test
doesn't
work
outside.
A
You
the
board's
responsibility
here.
It's
actually
define
core
and
that's
a
big
job
in
the
sense
that
we
want
to
do
it
in
a
fair
and
transparent
way.
So
we
have
a
lot
of
mechanisms
that
allow
us
to
gauge
those
and
get
those
through
the
process
and
the
Deaf
core
committee
is
the
conduit
for
that
and
we'll
talk
about
how
we
communicate
a
lot
of
what
today's
meeting
is
actually
talking
about
the
communication
path,
but
really,
fundamentally,
the
board's
job
is
to
pick
the
required
test,
the
foundation
and
not.
A
The
foundation
from
the
board,
the
foundation
is
actually
the
staff.
The
executive
director
is
paid
staff
that
oversees
the
project
and
protects
the
brand.
The
board
is
really
the
governance
body
and
the
Foundation's
role
is
actually
the
manas
vendors
and
enforce
the
brand
new.
So
if
you
use
OpenStack
incorrectly
you'll
get
letters
from
the
foundation.
A
A
A
Justification
of
what
to
enter
without
and
it
looks
sort
of
like
what
I've
put
on
screen
here,
there's
a
dated
version.
So
2015
03
was
our
first
approved
spec
and
then
every
time
the
board
acts
will
add
a
date,
a
new
news
back,
we
talked
about
which
releases
or
starboard.
That's
in
that
guideline
we
talk.
A
Platform
components
are
in
or
out
what
capabilities
are
in
or
out
and
then
which
sections
are
in
route
and
we
have
a
common
lexicon
of
required
advisory,
deprecated
and
removed.
So
the
goal
here
is
that
nothing
should
catch
people
by
surprise.
So
when
things
come
into
the
guidelines,
they
go
through
advisory
before
becoming
required
and
as
they
go
out,
they
go
to
deprecated
before
they're
removed,
pretty
straightforward.
Our
goal
is
really
not
too
surprised
anybody.
A
A
The
Jason
is
the
official
approved
version,
and
so
this
is
how
it
looks
when
you,
when
you
look
at
the
guidelines,
it's
important
to
understand
and
this
if
you've
been
tracking
def
core.
This
was
a
change
in
the
last
cycle.
Def
core
is
not
about
releases.
We
used
to
talk
about
havana,
def,
core
and
slow
desk
or
in
juneau
desk,
or
what
we've
really
done
in
changing
to
guidelines
as
we
switch
to
date,
and
that
was
really
important
in
our
process,
because
we,
you
know
def
course
not
really
about
the
release.
People
would
ask.
A
Oh,
is
this
feature
going
to
be
in
and
def
core
or
not,
and
def
core
is
not
really
about
tracking
the
latest
features.
As
a
matter
of
fact,
it's
about
lagging
features.
So,
if
you
look
at
this,
this
graphic
we've
tried
to
capture
the
deaf
core
guidelines:
capture,
a
subset
of
capabilities
within
the
overall
OpenStack
integrated
release.
So
we
pick
things
out
and
then
they
lag
after
the
the
feature.
So
it's
pretty
common
for
us
to
have
somebody
say:
oh,
is
this
new
feature
from
kilo
going
when's
it
going
to
make
it
into
Def
core?
A
C
C
A
Another
way
to
look
at
this
and
I've
mentioned
these
things,
but
hopefully
visualizing
in
different
ways
will
help
people
sort
of
get
a
handle
on
it.
The
guidelines
cover
releases,
so
we
will
say
this
release
or
that
release
is
actually
covered
by
the
f
course.
So
we
we
don't
expect
people
to
apply
def
cord
entries
for
saying
platform
components
will
talk
about
that
capabilities
which
are
really
api's.
A
So
the
black
marks,
at
the
edge
of
the
circles,
are
reflect
the
idea
that
we
have
capabilities
that
are
really
api
tests,
not
inside
and
they're
tested
and
then
designated
sections,
which
is
code.
So
one
of
the
things
that's
been
very
important
in
the
OpenStack
community.
Although
contentious,
not
everybody
agrees
with
this
point
of
view
is
going
to
consensus
view
to
say
that
OpenStack
must
have
certain
code
to
be
considered.
A
Nope
affect
product
and
there's
some
code
that
you
can
replace
the
designated
sections
embodies
this
concept
that
if
you
are
an
openstack
cloud,
you
are
running
OpenStack
code
and
passing
the
required
implementing
the
required
API
is
to
pass
the
test.
So
it's
between
the
Deaf
poor
has
both
components
and
then.
B
A
A
So
what
are
what
our
platform
platforms
and
components
so
this?
This
is
a
change
for
the
cycle.
Before
last
you've
been
tracking
def
core.
We
introduced
the
concept
of
OpenStack
platform
and
components.
So
the
idea
here
is
that
of
the
capability.
So
capabilities
are
groups
of
tests,
the
capabilities
roll
into
a
component
so,
for
example,
object,
storage
or
compute,
potentially
databases
service
could
be
a
component
one
day.
B
A
Is
a
license
that
the
foundation
can
confer.
It
is
a
more
restricted
license
and
if
you
pass
the
test
for
all
the
capabilities
that
we
cover
and
that
would
enable
you
to
become
a
notice
that
our
platform,
so
the
platform
means
that
you've
enabled
all
of
the
components
that
we've
identified
as
being
platform
required.
A
A
A
Code,
it's
a
signal
for
what
should
be
up
streamed
in
what
shouldn't
be.
So
you
know,
our
expectation
is
that
vendors
will
actively
participate.
The
designated
code
is
where
the
upstream,
what
must
be
upstream,
not
designated
code?
Some
people
call
plug-ins
for
modules
where
you
can
substitute
and
we
have
guidelines
to
identify
what
should
be
designated
or
not
very
important.
To
understand.
We're
not
trying
to
take
a
micrometer
and
figure
out
which
line
of
code
is
dead.
Jadeja
are
not
designated
code
is
a
general
definition.
A
A
Capabilities
themselves
are
pretty
straightforward
in
the
fact
that
they
are
literally
just
groups
of
tests.
So
we
spend
a
considerable
amount
of
time
and
there's
a
team
with
people
is
doing
excellent.
Work
literally
saying
these
tests
are
in
these
tests
are
represent
this
capability
today
they
have
been
limited
tips,
but
in
the
future
we
expect
them
to
not
be
limited
to
a
tempest
and
that's
a
little
bit
of
a
funny
definition.
People
use
the
word
tempest
to
mean
the
the
K
test.
A
You
could
clearly
run
multiple
tests
under
tempest
as
framework.
The
idea
is
that
the
tests
will
be
in
the
community
and
we're
in
the
OpenStack
community,
managed
by
OpenStack
we're
not
expecting
test
to
be
third-party.
Somebody
wrote
some
tests
that
they
use
on
their
internal
OpenStack.
The
tests
have
to
be
community
governed
tests,
but
then
the
kick
those
bubble
into
capabilities,
and
then
we
spend
a
significant
amount
of
time
of
year
ago,
defining
capability
groups.
How
do
we
score
capabilities
and
principles
by
which
capabilities
are
identified
as
core
or
not
core?
It
is.
A
It
is
worth
noting.
We
don't
pick
individual
tests,
we
don't
score
individual
tests,
we
actually
bubble
them
into
groups
and
then
we
score
capabilities.
So
a
lot
of
time
in
the
Deaf
core
process
is
spent.
Saying
is
this
capability,
one
that
should
be
core
or
not
core
and
because
that
in
itself
can
be
a
very
controversial
or
contentious
discussion?
We
have
a
12-point
score.
You
can
go
back
to
previous
def.
Core
material
I
walked
quite
a
bit
about
this.
Where
we
actually
identify
is
something
core
capability
or
not.
A
That
in
itself
is
an
hour
discussion
good
very
quickly,
so
we'll
have
lots
of
times
your
questions
and
I
appreciate
people
queuing
them
up,
we'll
go
back
through
and
we'll
take
them
out
as
we
go.
So
the
2015
a
is
the
name
of
the
process
document.
There's
a
bit
ly!
Think
for
it.
It's
that
will
take
you
to
our
github.
A
This
is
this:
is
Maya
Austin
shirt,
Austin
conference
shirt
2015
a
we
spent
a
lot
of
time
talking
through
this
process
and
what
we
found
was.
It
was
easiest
to
understand
if
you
started
with
a
timeline.
So
in
that
we
have
a
six-month
guidelines
right
now,
we're
doing
a
guideline
ever
even
months
because
we're
trying
to
catch
up
some
may
what
we
plan
to
have
a
guideline
August.
We
plan
to
have
a
guideline
and
then
from
there
they
will
start
following
this
time.
This
normal
the
guidelines
will
follow.
A
The
timeline
in
this
case
in
between
summits,
deathcore,
will
start
the
process
of
the
preliminary
draft
using
the
current
guideline,
which
we
call
like
2015
next
and
at
that
process.
That's
really
the
busywork
time
for
the
Deaf
court
committee,
where
we
are
being
new
capabilities,
we're
scouring
the
capabilities
we're
coming
up
with
what
we
think
is
the
solid
draft
of
the
the
next
guideline.
A
The
goal
is:
have
that
presented
at
the
summit
for
the
board
to
review
it
and
then
to
allow
the
community
at
the
summit
to
begin
the
engagement
process
of
understanding
what
will
be
in
deaf
court?
Remember
this
isn't
about
the
release
at
you
know
at
the
summit
or
the
release,
its
being
finished,
def
core
is
really
going
to
be
lagging.
So
a
lot
of
this
process
is
focused
on
the
previous
release,
not
on
the
current
release.
By
definition,
anything
new
and
the
current
release
is
not
going
to
be
core.
A
It
has
to
be
there's
actually
a
scoring
component.
That
says,
it
must
be
stable
for
multiple
releases.
After
the
summit
we
move
into
a
secondary
phase
where
vendors
can
start
looking
at
that
list
and
seeing
things
make
sense,
they
can
ask
to
have
test
flagged
as
the
test
doesn't
conform
to
limitations,
and
we
can
also
start
getting
feedback.
I
welcome
to
be
a
nurse
in
here
turn
it
off
they're.
A
Debating
consider
ever
joined,
please
mute,
we've
gotta
echo,
thank
you
and
then
from
there.
We
would
be
moving
into
review
and
cycle
and
talk
about
this
on
the
next
slide.
So
those
four
phases
sort
of
break
into
this
these
guidelines,
and
if
you
look
at
this
draft
document,
which
is
what
we're
asking
you
to
do
as
a
result
of
coming
to
me
in
this
draft
document,
you'll
see
there's
the
four
phases
translate
in
the
DL
needs
to
me.
Please.
A
So
the
four
phases
translate
into
we
gave
them
letters
and
that
have
a
significant
amount
of
text
detail
in
each
inside
of
each
letter
with
multiple
points
in
it,
and
I
would
ask
when
you
read
it.
Remember
the
FAQ
document
another.
Why
document
so
that
we
have
tremendous
amounts
of
Y
backing
up
the
things
that
we're.
B
A
A
Okay,
let
me
go
backwards,
so
the
four
sections
are
generally,
this
I
keep
back.
Now
we
have
a
guide
lines,
review
cave.
We
could,
where
we
collect
the
data
summit,
we
actually
start
doing
review
from
that
point
forward.
We
will
be
using
Garrett
so
changes
that
we're
tracking
will
go
through
a
community
review
process.
It's
very
important
for
us,
since
this
is
such
a
broadly
impacted
process
where
vendors
operators,
users
and
developers
all
have
interests.
A
C
A
Number
three
is
very
much
about
that
and
then
guideline
approval
is
where
the
Board
meets
to
approve
these
guidelines.
Make
you
go
in
it
if
we
need
to
accelerate
or
decelerate
this
guideline,
we
can
definitely
do
that.
We
have
been
accelerating
it.
One
thing
I
neglected
to
put
in
here
is
that
foundation.
The
foundation
licensing
requires
vendors
to
submit
to
the
one
of
the
last
two
guidelines,
and
then
their
certification
state
is
valid
for
a
year.
A
So
we
have
two
guidelines
out
right
now:
2015
0,
3,
2015
04
a
vendor
could
pass
either
of
those
and
then
be
able
to
use
the
trademark
for
a
year
for
the
pepto
recertified.
When
we
introduce
2015
05,
then
2015
03
will
be
deprecated
and
vendors
would
no
longer
be
able
to
use
that
for
certification.
I
should
have
put
that
in
the
slide,
and
so
what?
What
are
we
asking?
If
you're,
a
user,
in
addition
to
helping
review
the
materials
time
to
start
asking
vendors
your
vendor?
A
If
they've
passed
the
guidelines,
if
you're
a
vendor
time
to
start
validating
your
product,
if
you
are
an
operator,
is
just
using
OpenStack,
we
would
love
to
have
you
participate
and
give
feedback
about
which
capabilities
you
think
are
important.
Getting
involved
in
defining
capabilities
is
what
they
said,
and
also
tests
that
help
to
find
capabilities
is
what
are
going
to
drive
interoperability
for
OpenStack.
We
have
the
2015
next
guideline
is
in
github
we're
constantly
working
to
designate
work
with
designated
sections
of
code
running
tempest
and
uploading.
A
Your
results,
we're
still
working
on
a
project
called
ref
stack
in
the
past.
If
you've
gone
to
pass
desk
or
meetings,
you've
heard
me
talk
a
lot
about
restack
and
the
that
project
is
still
continuing
with
decoupled
deathcore
a
little
bit,
because
we
don't.
We
haven't
reached
a
point
yet
where
we
can
really
publicly.
A
Hopefully,
ref
cycle
contradict
this,
but
where
you
can
run
tempest
and
then
upload
the
results
that
is,
that
is
a
very
strong
soul
and
this
part
of
the
Deaf
poor
objective
collects
meaningful
data
so
that
we
can
score
capabilities
using
these
are
tests
that
are
really
passing.
These
are
capabilities
that
are
really
present
and
then
you
know
we
need
people
to
say
yes,
a
silent,
yes
is
not
as
helpful
for
us
as
we
go
through
this
process.
We
need
both
people
giving
us
constructive
feedback.
You
don't
like
it.
A
Let's
tell
us
it
tell
us
why,
and
if
you
do
like
it
is
a
silent
majority
is
not.
We
need
a
active
majority
and
then
we
have
some
references
in
the
material
github.
We
have
the
wiki
moving
a
lot
of
that
material
to
github,
also
up
logs
about
this
extensively.
So
if
you
want
history
and
material,
my
blog
at
some
of
the
most
sense
of
archive
about
that
for
yes
and
that's
the
end
of
the
station.
A
A
Okay,
great
questions
about
being
I'll
help
you
and
that's
guess,
for
please
clear.
The
f
he's
so
keep
those
tests
were
under
UV
de
BD,
because
II
stone
did
not
have
explicit
test
and
Chris
hook
from
the
foundation
who's.
The
Deaf
course
Secretary
has
been
working
with
the
tempest
group
and
keystone
sort,
Keystone
and
tempest
groups
to
fill
gaps
and
get
some
tempest
tested.
A
A
C
C
A
B
A
C
B
D
C
A
C
A
C
Yeah
like
God,
basically,
we
make
us
for
authentication
and
authorization
as
well
and
up
well
revert
very
well
on
it
as
an
admin
or
any
of
the
administrator,
rather
than
any
other
tenants.
So
I
just
wanted
to
understand
because
it
has
any
multiple
roles
to
play
because
of
which
T
strong.
We
are
not
running
origin
because
we
are
running
only
the
identity
service.
It's.
A
So
key
stone,
keys
transmission
was
entirely
unintended
in
the
fact
that
it
just
didn't
have
its
own
test
sleep.
He
didn't
have
dedicated
tests,
so
it
was.
This
was
not
and
is
not
intended
to
be.
A
signal
to
the
Keystone
is
a
replaceable
component.
One
of
the
reasons
why
we've
presented
it
and
in
the
past
with
PVD
is
because
we
want
to
make
sure
people
knew
it
would
be
included
and
become
a
required
peace.
A
So-
and
this
is
it's
worth
noting,
this
is
not
there-
there's
considerable
people
in
the
community
who
believe
the
deaf
or
should
move
to
an
API,
only
spec,
and
it's
important
for
me
to
represent
their
viewpoint
in
presentations,
and
there
are
considerable
people
in
community
who
believe
that
OpenStack
is
code
and
it's
absolutely
essential
that
OpenStack
is
always
0,
but
we
actually
have
some
some
actually
polarized
perspective
on
how
this
should
work.
Deathcore
represents
a
compromised
position
by
saying
some
of
the
code
is
required.
Some
of
it
is
substitutable
a
keystone.
A
Just
like
anything
else.
The
expectation
is
that
you
will
use
the
designated
Keystone
code
and
I
believe
we've
already
identified
designated
sections
for
Keystone
and
those
have
been
presented.
So
if
you,
if
you
are
interested,
if
you
are
a
strong
believer
and
I
know,
many
people
who
are
in
the
OpenStack
should
test
the
API
and
let
the
implementations
float.
That
will
be
the
subject
of
deathcore
in
the
coming
cycles.
A
So
after
we've
completed
this
work,
we
have
promised
people
that
we
would
actively
discussed
this
topic
and
so
I'm
being
very
explicit
because
I've
made
personal
commitments,
people
that
it
would
be
a
topic
of
discussion
in
future
in
future
times,
so
people
should
be
prepared
for
that
I.
Thank
passionate
people
are
very
passionate
about
positive.
A
I'm
excited
to
see
that,
because
I
think
that
our
goal
is
test
not
tempest
per
se,
and
so
the
broader
suite
of
tests
that
we
can
have
the
better.
We
do
need
to
make
sure
that
vendors
know
how
to
work,
run
the
tests,
and
we
have
mechanisms
to
accept
that,
though
we
are
going
to
hold
adding
test
that
aren't
tempest
test
until
after
2015
03.
My
expectation
would
be
that
those
tests
we're
going
to
have
test
besides
tempest
coming
in
immediately
after
the
2015
03
spec
is
approved,
and
chris
is
working
on.
A
The
schema
updates
to
accommodate
that.
So
one
of
things
will
change
in
after
2015
03
is
that
we
will
do
pretty
major
revision
of
the
of
this
JSON
schema
that
we
store
all
this
information
in
to
accommodate
multiple
test,
Suites
and
better
test
identification
and
there's
there's
a
list.
Actually,
the
chris
has
been
putting
together
of
objectives
for
the
schema
update.
D
D
You
if
you
actually
run
the
the
death
Corps
test,
results
and
report
those
results
back
to
the
foundation
back
to
me
in,
in
particular
we're
going
to
be
ramping
up
the
efforts
from
the
foundation
to
highlight
vendors
that
pass
the
deaf
core
tests.
And
so,
if
you
get
the
results
to
me
before
the
summit
and
before
you
know,
kind
of
our
preparation
plans
go
on
to
their
you'll,
be
highlighted
in
the
initial
marketing
efforts
surrounding
the
the
new
def
core
standards
that
were
recently
approved,
and
so
you
know
feel
free
to
reach
out
to
me.
A
So
that's
where
we're
they
were
starting
to
see
vendors
coming
through
I
don't
want
to.
I
know
I've
heard
that
at
least
one
vendors
made
it
I
don't
want
to
steal
anybody's
Thunder.
So
this
is
definitely
something
that
vendors
are
actively
picking
up
and
should
be
I'm
excited
to
see
the
the
response.
A
A
A
How
do
you
test
designated
code
designated
code
is,
is
a
self-governing
item,
so
our
goal
is
not
to
create
a
police
state.
It
actually
stay.
It
actually
says
that
in
that
designated
says
that
code
section
it's
a
it's
a
patchy
to
code,
and
so
it's
really
an
indication
of
what
we
expect
vendors
to
do
and
how
we
we
want
people
to
behave,
and
we've
spent
a
fair
bit
of
time
in
the
early
days
of
designated
codes.
A
B
A
A
Pipeline
code,
specials
are
very
clearly
delineated
in
designated
sections.
It's
it's
really
much
more
about
the
base
statement.
We
expect
openstack
vendors
to
use
the
upstream
OpenStack
code
in
certain
parts
and
be
very
specific
about
that.
So
it's
it's
really
not
we're
in
any
we're
in
no
way
trying
to
make
the
foundation
into
a
validation
and
inspection
body.
That's
that
encounter
to
our
objectives,
all
along.