►
From YouTube: DefCore Community Call 2014 09 10
Description
15 minute DefCore Review
45 minute Designated Sections Discussion
A
Hello,
everybody
and
welcome
to
the
timber
tense
meeting
to
review
deaf
cord
progress
so
far,
tonight's
focus
topic
as
designated
sections,
but
we're
going
to
start
with
some
review
of
the
history.
My
name
is
Rob
hirschfeld,
one
of
the
co-chairs
of
the
deaf
core
committee
and
our
job
is
to
define
the
commercial
use
of
openstack
brand.
A
A
Capabilities
are
effectively
API
statements
that
decompose
projects
into
capabilities
code,
which
is
the
topic
for
tonight,
so
there's
specific
components
of
the
code
that
we
expect
vendors
to
use
and
then
the
capabilities
are
validated
using
tests.
So
we
use
the
tempest
tests
as
our
check
step
in
the
past,
we've
called
that
faithful
implementation
test
suite
in
this
case
we're
really
calling
it
def
core
capabilities
tests.
A
Those
the
vendors
must
pass
those
tests
and
then
it
that
drives
an
interoperability
and
minimum
standards.
It's
all
about
commercial
products
and
trademarks.
A
lot
of
times
people
get
confused
and
think
that
we're
applying
the
core
statement
to
the
integrated
release,
the
integrated
release
and
the
projects
that
are
in
the
integrated
release
are
the
domain
of
the
TC,
the
Technical
Committee,
for
defining
what
projects
are
in
or
out.
A
But
if
access
to
cross
my
blog
there's
a
lot
of
material
that
we've
put
together,
I
use
my
blog
as
sort
of
our
test,
our
test
engine
for
deaf
core
and
a
lot
of
the
deaf
core
ideas,
we're
going
or
discussed
there.
And
so,
if
you,
if
you're
interested
in
really
seeing
a
lot
of
material,
I
think
I
think
I've
written
a
small
book
about
deaf
core
through
my
blog
and
I'd
recommend
going
through
searching
def
core
and
you
can.
You
can
certainly
read
about
process
flow
and
different
components
that
we've
had
for
that.
A
So
that's
def
court,
a
high
level.
The
brief
history
of
deaf
core
is
that
at
hong
kong
the
board
came
up
with
ten
principles
that
we're
guiding
how
we
would
define
core,
because
it
applies
to
commercial
use
of
the
openstack
trademark.
It
has
a
significant
commercial
financial
impact
to
a
lot
of
the
people
in
the
ecosystem,
and
so
we
have
to
be
very
deliberative
and
how
we
do
this.
A
The
principles
were
our
first
attempt
to
start
going
through
this
and
they
defined
that
we
were
talking
about
core
as
a
subset
of
the
overall
release,
not
the
whole
project
that
could
be
used
both
for
private
and
public
clouds.
So
there's
one
core
in
the
future.
We
may
have
sub
marks
or
specialized
marks,
but
right
now
we're
working
on
a
single
mark
for
core.
We
expect
that
there
will
be
the
vendors
will
use
open,
Stax
code,
it's
very
important
statement.
A
Openstack
is
a
code
project,
it's
not
an
API
spec,
so
we
expect
vendors
to
use
the
code
and
we
expect
within
that
vendors
will
be
able
to
substitute
parts
with
what
we
call
alternate
implementations.
They
can
use
that
don't
have
to
use
open
reference
implementation,
so
they
have
a
choice
for
that
tonight.
What
we're
doing
is
we're
actually
talking
about
how
they
know
which
parts
are
the
parts
they
have
to
use
in
which
parts
they
can
substitute
it's
the
place
we've
been
working
towards
before
this
is
all
about
this.
A
These
aren't
sections
which
is
about
tests
which
tests
are
required,
how
we
pick
which
tests
are
required,
and
things
like
that,
and
so,
if
you
look
at
that,
what
we
do
to
what
we
do,
that
we
as
we
look
at
the
body
of
tests,
are
available
in
each
release.
We
score
those
based
on
12
criteria.
This
graph.
This
graphic,
shows
these
12
criteria.
They
have
four
general
categories.
We
actually
score
all
of
the
tests.
Together
from
that
we
come
up
with
a
matrix.
A
This
was
our
first
pass,
we're
working
to
automate
this
more,
but
by
using
those
12
factors,
we
can
score
different
capability
groups,
so
tests
are
blunt,
jumped
it
or
block
together
into
capability
groups.
Capability
groups
are
scored.
That
tells
us
which
capabilities
are
required
for
openstack
implementation.
A
If
your
blood
pressure
is
going
up,
it's
very
important
to
understand
we're
doing
this
for
havana
first
in
an
advisory
capability,
so
this
will
be
enforced
in
the
Icehouse
release
and
we'll
actually
expect
vendors
to
pass
the
test
we've
identified,
as
must
pass
tests
based
on
which
capabilities
those
tests
are
in.
We
are
doing
it
against
Havana
in
an
advisory
way,
because
we
want
to
get
have
people
engaged
with
real
information
where
you
can
actually
say.
A
A
We
have
people
who
believe
very
strongly
that
Swift
should
be
included
as
a
required
capability,
and
we
have
an
almost
equal
number
of
the
community
who
thinks
swift
should
not
be
a
required
capability,
and
so
the
purpose
of
laying
out
the
list
like
this
is
for
people
to
be
able
to
understand
how
we
make
the
decisions
and
then
have
a
dialogue.
Now
that
we
actually
say
well,
it
looks
like
Swift
should
be
included
based
on
these
scores.
A
It's
been
bringing
people
out
into
the
community
now
that
they
actually
understand
what
we're
talking
about.
So
we've
gone
from
very
general
principles
to
a
criteria
system
to
actually
make
having
the
results,
and
we
want
people
to
engage
in
the
results
now
that
it's
much
clearer
to
say,
here's
why
Swift
is
in
or
here's
Weiss
lift
is
out,
and
the
same
is
true
with
all
these
another
one
that
attracts
attention
is
Keystone.
A
There
are
no.
In
Havana
there
were
no
tests
for
Keystone
version
2,
which
is
the
test
that
we
would
have
considered
for
core.
Consequently,
Keystone
doesn't
isn't
a
required
capability
in
Havana
based
on
these
scores,
so
just
weren't
any
tests.
There's
plenty
for
version
3,
but
we
does
that
wasn't
stable,
and
so
it
didn't
pass
our
other
tests,
so,
hopefully
I'm
sort
of
glossing
through
a
lot
of
material,
I'll
pause
for
questions.
In
a
couple
of
minutes,
people
can
see
how
we've
been
building
up
this
process,
how
we're
making
the
decisions?
A
Very
importantly,
what
the
impact
of
those
decisions
are
and
then,
if
you
want
to
question
it,
should
Swift
the
core
capability
or
not.
Instead
of
arguing
the
big
stand
in
the
corner
and
shout
I
think
it
is
I,
don't
think
it
is.
You
can
actually
say
you
know
what
I
think
that
it's
not
really
used
by
tools.
A
You
scored
that
it
is
used
by
tools,
and
we
should
adjust
that
we,
if
we
change
that
one
thing
it
would,
it
would
change
the
score
and
then
we
reconsider
whether
it
was
or
not,
and
so
it
becomes
a
much
more
targeted
conversation
and
ultimately,
more
data-driven,
which
is
how
we
want
to
make
these
decisions
doesn't
mean
people.
Don't
just
don't
think
that
it's
wrong.
A
B
A
The
the
next
thing
on
to
show
this
actually
would
need
its
own
meeting
to
review
and
and
if
we
need
to
we'll
take
questions
on
this
too,
we've
been
working
through
trying
to
walk
people
through
how
this
process
works.
This
meeting
is
actually
on
this
process.
Chart
is
part
of
this
community
input
bubble.
Here.
A
The
idea
is
very
simply
and
I
just
wrote
a
blog
post
about
about
this
whole
process
flow,
we're
creating
documents
that
have
capabilities
in
them
and
also
designated
sections
in
them,
and
we're
going
to
use
Garrett
as
a
review
process
so
that
we
can
collect
community
input
in
a
very
audited
way,
and
people
can
make
patches
and
changes
against
these
documents,
and
then
we
can
certify.
Yes,
this
is
the
approved
version
and
have
it
go
through
a
regular
garrett
process.
So
this
this
flow
shows
a
lot
of
different
things
going
on.
A
A
This
this
is
a
graphic
that
we
put
together
to
help
explain
the
interaction
between
the
API
capabilities
and
the
designated
sections
of
code.
So
the
integrated
release
is
a
is
composed
of
multiple
projects
of
those
projects.
Some
of
them
have
required
capabilities.
What
we
call
core
capabilities
and
some
do
not
not
all
of
the
capabilities
in
every
project
or
court.
We
made
the
decision
that
none
of
the
admin
api's
are
considered
court.
A
So
we
wanted
the
court,
which
is
a
requirement
if
you're
going
to
have
core
work
for
public
cloud
and
private
cloud
that
you
have
to
have
only
the
public
of
the
not
admin
api's
of
the
projects
that
have
core
capabilities
for
those
we
care
about
whether
or
not
they
have
designated
code,
and
the
idea
here
is
designated
code
is
code
which
is
common
for
all
deployments.
It
should
be
stable.
It
should
be
some
reference
reference
code
that
we
expect
people
to
do,
and
it
also
tells
the
vendors.
A
This
is
where
we
expect
you
to
play
upstream.
You
know
if
your
VMware,
you
don't
care
about
the
kvm
driver
and
how
the
kvm
driver
works
in
ANOVA.
It
you're.
Probably
not
going
to
include
that
in
your
your
distro,
you
might
just
ignore
it,
but
you
don't
have
to,
and
so
you
would
have
an
alternate
implementation
of
that
driver,
and
so
we
want
to
have
it
very
clear
within
the
projects
which
things
vendors
are
expected
to
implement
views
in
which
things
they
can
substitute.
A
That
goes
back
to
the
original
principles
from
Havana,
and
this
is
an
apache
to
project,
so
it
isn't
going
to
be
an
inspection
with
code
police
running
around
checking
every
vendor.
This
is
guidance
to
help
the
community
understand,
what's
included
when
somebody
buys
an
OpenStack
product
and
it
also
the
other
thing.
That's
significant.
A
There
are
number
of
people
in
the
community
who
don't
want
us
to
have
an
API
only
product
and
would
be
very
feel
very
strongly
that
a
somebody,
reimplemented
OpenStack
in
go
or
Java
or
or
lying
or
list
like
this
niggardly,
pick
your
language
with
a
completely
new
code
base.
Even
if
it
was
open
source,
they
still
feel
that
that
wouldn't
be
OpenStack.
That
would
be
somebody
using
the
OpenStack
api's
and
at
this
point
this
process
is
driven
for
an
API
plus
code
certification
of
core.
A
We
have
deliberately
pushed
the
conversation
about
an
API,
only
version
of
OpenStack
or
API
compatibility
version
of
OpenStack
down
down
the
stream.
It's
not
it's
not
on
the
table
for
discussion
in
these
meetings.
We,
obviously
we
talk
about
things
like
that
all
the
time,
but
it's
it's
not
something
we're
going
to
discuss
as
an
option
for
core
at
this
point.
A
I
say
that,
because
it's
there
are
times
when
we
do
get
into
discussions
where
people
want
to
add
a
you
know,
bring
that
in
as
an
option
and
we've
been
doing
this
process
sort
of
in
a
very
slow,
methodical
way,
and
there
are
certain
things
that
we've
we've
as
a
as
a
board
decided
to
postpone
because
they
were
too
cutting
too
contentious
or
we
couldn't.
We
didn't
feel
like
there
was
a
consensus
and
we're
really
working
on
a
consensus
driven
process
for
Cork.
With
that
I've
done.
A
A
A
And
so
one
of
the
challenges
that
we
have
with
any
of
these
operations
around
core
is
that
people
have
a
tendency
to
look
at
court
as
a
value
statement.
This
is
the
important
code.
This
would
be
unimportant
code
and
unfortunately,
it
people
will
do
that
and
I
understand
that
the
rationale
it
really
is
supposed
to
be.
This
is
the
stable,
mature
code
that
we
are
relying
on
and
in
separating
the
mature
code
from
the
innovative
changing
fluid
code.
A
It's
not
a
matter
of
importance.
The
innovation
is
incredibly
important
to
OpenStack.
Stability
is
incredibly
a
important
effect
because
we
build
on
it.
So
both
are
both
are
important,
and
so,
from
that
perspective,
when
we
say
your
baby
is
ugly
saying,
all
babies
are
ugly
all
right.
That's
the
that's
the
reference
and
we're
looking
for
the
adults
in
the
inlet
in
the
OpenStack
project.
A
If
you
both
the
things
that
people
can
depend
on
being,
there
released
released
a
release
that
have
shown
signs
of
stability,
and
so
when
we
pick
designated
code,
we
start
with
seven
items
that
came
out
of
the
TC,
and
there
are
pretty
straightforward
for
this
they're
technically
driven.
There
are
things
that
provide
the
standard,
API
or
common
functionality
or
cross-platform
logic
right.
Those
are
those
are
the
things
we
want
to
say.
A
This
is
the
core
requirement
for
making
the
project
same
way,
and
then
we
look
at
things
that
shouldn't
be
designated
by
vendor
specific
we're
talking
about
kbm
versus
vmware
as
an
example,
things
that
are
intended
to
be
replaceable.
We
talked
about
scheduler,
usually
as
an
example
for
that
things
that
extend
the
rest
api
so
that
the
api
extensions,
interestingly,
some
of
those
could
end
up
being
required
capabilities
if
they're,
very
popular,
but
there's
still
extensions
from
the
designations
perspective
and
code.
That's
being
deprecated
should
clearly
not
be
designated
and.
A
Are
all
technical
considerations
when,
when
def
core
looks
at
this,
we
added
three
additional
pieces
that
work
that
we
felt
were
important
because
the
board
isn't
in
a
position
to
make
technical
decisions,
we're
really
taking
advice
from
the
technical
community,
and
so
the
board
looks
at
these
additional
competes.
The
first
is
that
by
default,
things
are
not
designated
and
that
that
really
allows
us
to
take
this
very
innovative
project
with
a
lot
of
flux
in
it
and
not
have
to
think
that
it's
we
have
to
filter.
A
We
have
to
say
no
to
things
that
are
new.
What
we
really
want
to
do
is
bring
things
in
decor.
So
every
time
we
look
at
core
from
a
board
perspective,
we're
trying
to
have
a
small
core
that
grows
in
a
predictable
way,
rather
than
a
large
core
that
we
have
to
cut
things
out
of.
So
that's
that's
the
first
component.
The
next
one
is
consensus
based
designation.
A
The
board
has
to
make
a
decision
about
what
score
not
core
for
every
release
and
the
timely
manner.
It's
a
requirement
from
a
commercial
success
perspective
to
be
able
to
tell
then
there's.
Yes,
you
can
certify.
Do
you
know
within
a
reasonable
time
period
after
juneau,
because
it's
commercial,
it's
required
commercial
mark.
A
Therefore,
if
there's
going
to
be
a
prolonged
fight
about
something,
the
board's
position,
def
course
position
and
it's
moving
moving
to
board
approval
next
next
week
is
that
we
don't.
We
say
it's
not
designated.
There's
too
much
controversy
here
and
if
somebody
is
really
trolling
on
this.
Just
objecting
to
everything
will
spirit
that
out.
I
assume
that
you're
smart
enough
to
identify
that
and
then
finally,
that
its
guidance,
so
the
goal
here
is
not
once
again
to
create
code
police.
Our
goal
is
to
be
able
to
say
generally,
this
part
of
the
project
is
designated.
A
This
part
is
not
designated
so
saying
scheduler
the
Nova
scheduler
is
not
designated
is
considered
sufficient.
We
don't
have
to
point
to
the
code,
libraries
or
pieces
and
parts
like
that
that
are
more
articulate.
We're
assuming
intelligent
technical
people
can
use
this
guidance
to
make
reasonable
decisions.
A
Okay,
and
will
our
suspect,
we'll
come
back
back
to
these
definitions.
It's
important
to
understand
these
because
it
they
do
influence
some
of
some
of
how
this
decision
ends
up
being
made
and
then
I'll
remind
everybody
that
if
the
code
has
no
required
capabilities,
it
could
have
designated
sections
but
they're
really
not
enforceable.
So
if
you're
not
required
to
neutron,
has
no
desert
no
required
capabilities.
A
Therefore
we
could
designate
sections,
but
vendors
wouldn't
be
required
to
implement
them
because
they're
not
required
to
use
neutron.
In
this
case
we
haven't
yet
determined
designated
sections
for
Neutron
projects
and
a
lot
of
flux.
I'd
love
to
see
us
to
find
some,
but
once
again
they
wouldn't
be.
They
wouldn't
apply
Keith's,
not
a
core
capability.
So
there's
no
designated
sections
horizons,
not
a
core
capability.
So
there's
no
position,
Keystone
is
not
designate,
is
not
a
required
capability,
so
it
is
not
does
it.
A
There
are
alternative
in
stone
that
didn't
use
any
of
the
Keystone
code
that
complied
with
the
with
dapi.
So
the
consensus
in
deaf
Corps
was
that
there
was
no
designated
code
and
Keystone,
because
there
were
one
hundred
percent
alternate
implementations
for
Havana
that
this
might
might
and
should
be
changing.
As
we
progress
into
newer
releases,
I'll
pause
for
commerce
for
discussion.
A
A
A
And
I
would
say
this:
is
this?
Isn't
people's
only
bite
at
this
Apple?
If
you
have
concerns
about
this
and
you
don't
bring
it
up
on
the
caller
you're,
just
monitoring
your
listening
or
you
listen
to
the
recording
and
you
can't,
then
please
don't
hesitate
to
bring
it
up
to
the
Deaf
cord
list
or
email
me
directly.
A
Send
me
a
letter.
However,
you
need
to
get
in
touch
with
me.
You
or
anybody
on
the
Deaf
Court
committee.
We
do
want
to
have
the
discussions.
I
will
tell
you.
The
board
does
have
to
make
a
recommendation
and
the
recommendations
for
this
will
be
made
on
the
18th,
so
that
will
have
a
vent
or
advisory.
We
will,
of
course
repeat
the
process,
the
process
repeat
the
process
for
every
release,
so
if
the
ones
for
Havana
we
get
feedback
that
we
did
it
wrong,
you
have
chance.
D
E
A
A
But
we
are
Terry
and
I
are
engaged
in
coordinating
with
them.
They
have
an
adjacent
version
of
this
document
for
review
and
we're
still
trying
to
collect
feedback.
This
list
is
actually
many
months
old,
and
so
it
has
been
reviewed
invented
by
the
TC
and
you
can
we
actually.
The
lighthouse
set
6
has
some
discussion
around
those
points.
E
A
A
So
we
feel,
like
the
majority
of
the
Nova
project,
is
designated
code
and
we
would
expect
a
vendor
to
ship
it,
and
we
chose
to
have
exceptions
in
this
case
so
that
we
were
specifically
not
designating
code
/
for
Nova
and
those
does
a
mission,
those
non
designated
areas
or
the
scheduler,
the
filter,
scheduler
drivers
and
weights,
and
so
the
compute
driver,
REST,
API
extensions
and
Nova
networking
components
and
drivers
right,
which
is
one
of
those
deprecated,
fully
deprecated
components
within
the
infrastructure.
So.
A
A
That
actually
goes
through
and
looks
at
the
comments
and
has
more
description.
So
one
of
the
things
I've
done
is
I've
taken
this
list
and
I've
started
with
this
list
is
for
descriptions
and
comments,
but
there's
a
lot
of
missing
pieces,
and
so,
as
we
get
this,
this
section
done
released
to
release
what
I'm
expecting
is
that
we
will.
A
A
Cinder,
the
designated
sections
are
the
API
implementation
code,
so
within
cinder
there's
a
lot
of
drivers
and
different
pieces
for
the
drivers.
Those
are
all
vendor
specific.
There
is
a
reference
implementation
reference
implementations
are
not
designated
they're,
just
they're
replaceable,
so
the
primary
component
for
cinder
becomes
the
API
framework
and
infrastructure
around
the
API.
A
Like
this,
we
seem
to
be
building
a
lot
of
OpenStack
projects
to
have
API
frameworks
with
pluggable,
backends
and
I
would
expect
a
lot
of
projects
to
implement
something
like
this
there's
there
are
projects
like
Oslo.
That
would
have
a
much
more
integrated
piece,
but
there's
no
exposed
capabilities
for
that
project,
so
it
is
while
we
could
dictate
guess
it's
a
hundred
percent
designated
and
I'd
love
to
see
it
on
the
list.
A
A
A
It's
not
the
only
Swift
alternate
Swift
implementation,
but
in
those
cases
the
substitutions
have
replaced
all
of
swift
and
reimplemented
the
api's,
and
these.
These
are
products
that
are
actually
existing
in
market
and
have
been
in
market,
and
so
the
feeling
is
that,
while
Swift
api's
are
required
capability,
the
actual
implementation
of
swift
for
Havana
is
not
designated.
D
A
That
one
is
not
a
technical
argument.
The
primary
argument
for
that
is
that
there
are
different
people
who
had
alternate
implementations
and
do
not
believe
that
there
is
a
part
of
the
swift
code
in
Havana
that
they
could
use
as
a
common
framework
and
they've
had
to
substitute
the
whole
implementation.
A
No
I
understand
exactly
you're
saying
is
an
excellent
question
and
it's
I'll
give
you
two
answers.
One
is
it's.
That's
that's
off
topic
for
the
meeting
and
I
say
that
you
know
in
rock
you
and
I
know
each
other
really
well
I'm,
saying
that
just
because
we're
supposed
to
be
talking
about
designated
sections
and
so
part
of
what
we
had
to
do
is
compartmentalize
discussions
like
that
I.
A
That
said,
actually
think
it's
worth
discussing
exactly
that
question,
and
so
what
I
would?
What
I
would
do
is
I'd
asked
to
hold
that
if
somebody
wants
to
talk
about
the
swift
designate,
designated
sections
topic
first
and
then
come
back
to
the
is
swift
or
require
capability
later.
Is
that
all
right
works?
For
me
thanks.
F
A
Yeah
I
one
of
things
that
is
interesting
to
note
with
the
Swift
designated
sections,
is
that
the
same
people
who
have
said
Swift
designate
doesn't
have
designations
for
Havana
I've
looked
at
juno
and
felt
that
it
does
and
that
they
would
be
willing
to
accept
designated
sections
in
Juneau,
and
so
this
is
what
things
that's
very
interesting
to
me.
As
we
look
at
time
series,
it's
very
likely
that
we're
going
to
have
changes
released
to
release
release
so
statement
today
does
not
change.
D
Is
that
doesn't
make
sense
to
me
at
all
because
the
proxy
hasn't
materially
changed
between
Havana
and
Juneau?
So
if
that
was
a
serious
faces
for
designating
or
not
missin
aiding
a
particular
thing,
I'd
expect
to
see
some
more
specifics
around
that
considering
we're
talking
about
designated
sections
which
are
actually
surely
you
know
part
of
the
colors
on
a
technical
box
like
the
nation
nation
I.
That's
fair,.
D
E
D
A
D
A
I
think
these
are
reasonable
components.
You
know
sections
of
the
code
to
figure
out
whether
they
stare
designated
or
not.
At
this
point,
we
have
people
saying
that
they
are
not
using
any
of
those
to
re-implement
the
Swift
APRs
and
so
there's
there's
a
technical
disagreement
within
within
the
community
as
to
how
to
implement
those
AP
is.
D
Around
the
designated
sections
with
looks
labeled
middleware
there,
though,
basically
how
this
works
in
the
world
is
when
you
connect
to
it.
It
goes
through.
It
has
a
list
of
Python
modules,
basically,
and
it
goes
through
them
one
by
one
in
a
pipeline
format
and
that
basically
does
various
things
with
your
response
or
takes
action.
D
So,
for
example,
if
you
wanted
to
add
s3
support
to
your
Swift,
you
insert
ps3,
you
know
in
the
Middle
where
pipeline,
okay
and
that's
actually
really
fantastic
from
an
operator
or
perspectives,
and
something
that,
in
my
previous
role,
we
used.
Basically,
you
can
choose
whether
or
not
you're
going
to
offer
Klingons
and
like
the
ability
to
provide
static
with
indexes,
or
you
can
actually
completely
change,
how
the
authorization
or
interesting
question
and
that
kind
of
stuff.
Okay.
So
that's
a
pretty
pretty
strong.
You
know
modification
point,
I,
guess
yeah,
because
it
right.
A
A
D
D
E
A
The
the
challenge
that
we
have
from
a
board
perspective
is
I.
I
really
can't
have
the
board
trying
to
make
a
technical
distinction.
We
have
we
sort
of
have
to
throw
things
up
say.
Does
this
make
sense
to
people?
It's
a
community
generally
agree,
so
they
make
sense.
If
not,
we
still
have
to
make
a
decision.
D
B
E
B
A
A
That
was
one
of
our
decisions
to
make
Havana
advisory
was
for
exactly
this
reason,
because
our
experience
has
been
that
the
only
time
people
really
engage
really
productively
is
when
they
have
you
a
list
of
designated
sections,
and
they
could
say
what
does
that
mean?
Why
are
you
objecting
to
this
and
how
do
we?
How
do
we
address
it?
D
Though
I
think
is
a
native
timing,
I
think
my
preference
is
to
specify
the
technical
detail
a
little
bit
earlier
than
what
you
recommend
it.
I
think
what
your
political
is
necessary,
the
section
that
is
advisory
and
then
you
know,
do
the
technical
detail
in
empower
that
I'd
recommend
that
is
in
today's
day.
A
A
A
We
also
expose
the
politics
and
the
deadlines
do
end
up
driving
people
to
act
and
more
than
starting
in
February
when
the
deadlines
are
as
pressing
and
I'm
the
only
the
only
the
only
way
I've
found
that
we're
able
to
actually
drive
this
is
for
us
to
make
a
statement.
Take
a
position
on
this
and
then
have
people
say
I'll
wait.
I
actually
need
to
start
providing
this
information.
It
hasn't
been
in
for
lack
of
trying
to
aged
technol
and.
C
D
Basically,
we've
done
by
now
that
you
know
we're
excluding
something
based
on
it,
particularly
shady
set
of
ideas.
Take
swift,
for
example,
we're
excluding
it
basically
because
some
guys
did
something
kind
of
nonspecific
about
something
he
couldn't
use,
so
he
had
to
be
implemented
and
that
other
monomers
in
our
entire
justification
and
not
detonating
serious
with
correct
and
I,
don't
think
that's
acceptable.
So
instead
we
should
try.
For
example,
as
you
said
you
for
forcing.
D
D
A
A
A
In
the
board's
case,
we
just
we
have
to
choose
designated
by
default
or
not
designated
by
default,
and
we
felt
that
we
couldn't
take
a
position
to
force
vendors
to
use
a
section
if
there
was
an
agreement
that
it
was
a
use
that
that
they
could
implement
it,
and
so
we're
defaulting
to
not
I'm
happy
to
have
the
conversation
of
how
to
drive
it
forward.
You
know
when
you
only
say
this
forwards:
you're,
probably
referring
to
the
death
coil
committee.
Def
core
is
the
board's
Committee
on
this
process.
A
D
Yeah
so
I
disagree,
I've
got
to
say
I
personally
disagree
with
the
idea
of
not
designating
due
to
lack
of
consensus.
I
I
disagree
with
that
principle,
but
I
would
recommend
that
you
look
again
at
that
decision
about
whether
to
designate
my
default
or
loss,
because
at
the
moment
the
justification
is
very,
very
shaky
without
that
technical
information,
asia,
so
unwind.
Why.
A
D
A
D
A
F
A
It
is
part
of
the
the
process
of
what
we're
trying
to
do
going
forward.
I
can
tell
you
they
showed
up
at
the
appropriate
time
and
we
have
a
discussion
about
it
and
they
objected
based
on
that
and
at
some
point.
I
can
I
can
keep
this
open
and
have
back
and
force
on
it,
and
we
can
get
appropriate
information.
We
can
collect
more
and
more
information,
but
I
don't
understand
where
people
have
different
polar
different
opinions.
A
If
they've
taken
different
actions,
we
have
an
Apache
to
license
code
base
where
they
they
have
the
option
to
license
or
not.
We
can.
We
can
certainly
drive
more
data,
I'd
love
to
have
more
data,
I'd
love
that
people
lay
out
what
their,
what
their
ration
lr
I
think.
All
those
are
reasonable.
Those
that
we
have
had
meetings
where
that's
been
done
so.
A
A
D
A
A
D
A
D
And
that's
completely
fine,
but
it
should
be.
This
code
should
not
be
included,
you
know
no
designated
codes
and
it
should
be.
This
is
the
reason
why,
at
the
moment,
when
you're
producing
the
information
there
isn't
that
following
reason,
why
and
I
think
realistically
we're
only
talking
about
Keystone
and
swifty
I
think
everything
else
has
had
quite
good
agreement,
but
the
fact
is
that
all
this
wiki
says
is
no
designated
code
for
vanaf
swift,
your
lack
of
consensus,
and
you
know
alternative
inflammation
implementations.
D
A
A
Correct
and
rocky
this
is
we
have.
We
have
not
had
time
to
talk
about
your
issue,
which
is
also
something
that
has
been
brought
up,
based
on
people's
review
of
the
actual
information
and
I've.
Had
significant
number
of
people
come
to
me
and
say:
I,
don't
think
that
the
Swift
capabilities
are
actually
core.
We
don't
include.
D
A
And
that
the
Deaf
and
the
the
board,
which
has
actually
passed
capability
set,
should
reconsider
the
Swift
capabilities
as
to
whether
their
core
enough-
and
in
that
case
the
Keystone
designated
sections-
are
mood
because
Keystone
has
no
required
capabilities
with
drawings.
Lift
from
the
required
capabilities
list
would
also
make
this
question
moot.
D
A
D
A
It
is
definitely
one
of
the
topics
of
the
board
meeting
next
week
to
re-evaluate
whether
or
not
Swift
has
a
required
capability
and
I
think
the
conversation
we
just
had
only
underscores
the
idea
that
we
are
likely
not
ready
to
have
the
designated
sections
conversation
about
Swift
and
I.
Think
it's
very
reasonable
to
ask
for
more
detail
and
more
discussion
about
that.