►
From YouTube: Thursday Lunch Speaker Series
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Good
afternoon,
everybody
welcome
hope
you
got
some
lunch
or
have
some
plans
afterwards,
so
I'm
Dave
Ward
from
Cisco.
You
may
recognize
me
from
several
of
their
Mike
events,
but
I
just
want
to
say
my
very
short
host
welcome
at
the
aquarium
and
my
very
short
plenary
welcome.
I
now
get
to
have
a
full
allotment
of
time
and
you
were
a
captured
captive
audience.
So
I
now
get
to
talk
about
a
few
things.
A
So
what
I
want
to
talk
about
today
was
something
that
I've
talked
about
at
ITT
f91
3
and
had
been
doing
a
quite
a
bit
of
work
in
open
source
and
trying
to
create
a
relationship
between
standards,
bodies
and
open
source
communities
and
how
they
can
interplay
together,
and
so
that's
what
we'll
talk
about
today?
Where
are
we
three
years
later
on,
frankly,
on
both
sides
of
the
coin?
A
Maybe
I
need
to
be
closer.
This
just
worked.
Oh
there
we
go.
So
why
should
you
care
what
I
have
to
say?
Maybe
you
don't
doesn't
matter
it
doesn't
matter,
but
let's
just
have
a
conversation
about
this.
A
brief
narcissistic
moment.
Many
of
you
recognize
me
from
working
here
at
the
ITF,
where
I
was
routing
ad
and
did
a
bunch
of
chairs
and
drafts
and
stuff
like
that.
But
I
have
been
around
the
last
couple
years
and
the
last
couple
years
I.
A
My
team
has
been
working
here,
but
I've
been
working
in
open
source
and
for
what
it's
worth,
which
you
can
see
up.
There
are
a
number
of
boards
that
I'm
on
in
communities
and
foundations
that
I've
worked
on
I
work
on
directly
have
catalyzed
and
really
my
intention
from
an
industry
perspective
was
to
create
a
developer
community
around
networking,
as
well
as
to
reduce
some
of
the
confusion
that
was
out
there
about,
and
this
is
during
as
we're
still
in
the
SDN
arrow,
the
end
of
the
era
and
and
and
so
forth.
A
Now
telemetry
and
a
variety
of
other
things
that
have
evolved
here
and
get
people
coding
towards
this.
So,
just
like
at
the
IETF
open
source
and
Cisco
as
a
company,
we
can't
go
any
faster
than
our
customers
and
our
customers
were
trying
to
understand
what
Sdn
controllers,
NFV,
orchestration,
etc,
etcetera
data,
big
data
and
what
it
means
for
networking.
They
were
trying
to
understand
what
for
them
and
if
we,
as
an
industry,
can't
go
faster
than
our
customers.
Are
the
operators
can
absorb
that
technology?
A
We
need
to
do
we
needed
to
take
a
turn
or
I
thought
we
need
to
take
a
turn
to
give
them
the
tools,
education
technology,
to
learn
this
along
with
us
as
an
industry.
Need
this
to
say
myself
and
no
one
in
this
room
has
the
key
for
what
Sdn
is
should
be,
will
be
and
how
it
will
be
deployed.
It
is.
It
is
an
evolution
and
we've
seen
that
over
the
last
eight
years,
and
so
what
I
wanted
to
do
now
going
on
about
seven
six
years
ago,
was
also
reduced.
A
Protocols
that
we
had
standardized
here
at
the
IETF
that
weren't
being
used
and
we're
being
used
effectively
and
through
my
career
I've,
learned
that
just
because
I
have
a
TCP
connection,
I
don't
have
to
shove.
Every
single
feature,
I've
ever
thought
of,
as
well
as
the
industry's
ever
thought
of
down
that
single
TCP
connection
and
different
protocols
do
different
things
very
well
and
I
wanted
to
work
towards
having
the
industry
take
advantage
of
that
and
also
get
through
the
infrastructure
phase.
A
Interesting
I
may
be
doing
this
talk
from
up
here.
I'll
do
this
talk
from
here,
so
back
in
91
I
made
a
number
of
outrageous
claims
proved
only
through
emphatic
assertion
and
let's
see
how
some
of
those
came
out,
what
I
want
to
mention
just
upfront
what
in
sum,
what
happened?
There's
still
a
massive
potential
for
the
IETF
to
engage
with
open-source
communities.
Really,
it
hasn't
happened
to
the
extent
that
the
industry
needs
it
to
happen
and
I'll
discuss
some
of
those
issues.
Many
open-source
communities
have
formed.
A
There
are
now
a
plethora
of
different
communities,
many
of
them
home
dat,
the
Linux,
Foundation
and
there's
a
vibrant,
vibrant,
very
large
community,
around
developing
networking
technologies,
which
is
awesome
that
went
very
quickly.
Needless
to
say,
different
cuts
of
Stax
controllers,
virtual
foo
bars
it's
it's
fractured
out
there
in
there
and
there's
no
clear,
stated
trajectory
necessarily
and
certainly
no
standardized
trajectory
that's
coming
there,
and
then
you
can
also
read
the
rest
where
that
I
have
on
the
slide.
A
Many
of
those
open
source
communities
are
also
now
standardizing
or
believe
that
they're
standardizing
packet
formats
etc
within
their
community
and
not
necessarily
bringing
those
back
to
the
ITF
or
an
or
another
standards
body,
etc.
So
the
last
thing
I
want
to
call
off
on
this
slide,
and
it
was
from
a
comment
made
at
the
plenary
last
night
and
I'd
like
you
to
think
about
this.
We
many
of
us
know
who
are
35
your
friends
and
working
here
at
the
IETF.
A
We
built
our
careers
here
we
were
able
to
advance
our
careers
by
working
deeply
at
the
IETF.
Needless
to
say,
things
have
changed.
Many
folks
are
advancing
their
careers
and
deeply
engaging
in
their
career
path
by
engaging
an
open
source,
and
maybe
some
of
the
shifts
that
we're
seeing
of
where
people
are
going
R
because
the
advancement
of
their
careers
and
where
they
need
to
go
and
have
on
their
resume
that
they're,
interacting
with
open-source
communities
and
building
open
technologies,
and
many
of
that
is
there
and
so
something
to
contemplate
at
least
so.
A
Let's
just
talk
about
some
of
the
claims
I
made
in
91
will
find.
We
will
see
now,
three
years
later,
they
weren't
in
fact
that
outrageous,
so
the
IETF
can
take
a
leadership
role.
A
couple
things
that
have
emerged
is
that
the
api's
platforms
and
frameworks
will
be
the
future
standards
front
for
software
driven
networking.
Second,
the
same
standardization
application
for
those
higher-level
concepts
we
need
to
think
through
if
and
which
standards
body
may
take
on
some
of
this
pieces.
A
Of
course,
it's
very
interesting
if
you're
trying
to
standardize
an
API
and
you're
not
involved
in
the
production
of
the
code,
those
are
almost
mutually
exclusive,
and
so
something
to
think
about
and
we'll
get
to
that
in
a
bit.
Can
we
make
the
IHF
more
agile
and
perhaps
changes
in
the
liaison
process
and
how
the
IHF
was
going
to
work
with
other
st
o--'s
or
open
source
was
critical.
A
Call
to
create
more
code
in
ideas,
claims
around
rough
consensus
versus
parliamentary
procedure
as
many
open-source
communities
derive
consensus
in
a
different
way
and
we'll
talk
about
that
and
you
know
more
running
code
now.
So
what
is
still
true
is
that
standard
geeks
are
don't
necessarily
make
the
best
open
source
geeks,
and
it's
just
you
know.
It's
just
a
claim
from
our
argument
here
and
really.
A
Those
aren't
necessarily
mutually
exclusive,
but
we
haven't
figured
out
a
way
that
those
two
definitions
of
driving
consensus
can
come
together
and
and
how
they
can
how
they
can
communicate.
So
just
again,
something
to
think
about
next
91
should
have
this
collaborative
loop
where
people
are
coding
and
coming
back
to
the
ITF
and
updating
standards
and
standard
folks
are
going
out
and
scanning
and
analyzing
the
industry
and
finding
out
hey.
Look.
A
They
got
that
standard
slightly
wrong
or
we've
got
a
technology
that
they
could
use,
because
the
IETF
produces
modules
of
technology
and
open
source
are
trying
to
open
source
communities,
are
trying
to
provide
functional
solutions
to
specific
use
cases
in
problems
and
that
there's
there's
quite
a
bit
rich
there.
So
next,
when
thinking
through
91
and
the
call
to
embrace
embrace
good
open
source,
there
are
foundations
that
have
good,
neutral
third
party
management
and
how
to
be
able
to
interact
with
those
foundations
was
a
request.
A
But
what
I
want
to
call
to
the
orange
box
on
here,
and
much
of
that
is
taken
out
of
what
it
means
to
be
an
RFC
with
a
reference
to
open
source
I
design.
Open-Source
is
constantly
iterative
and
moving,
and
so
therefore,
as
we
think
about
trying
to
base
a
reference
or
base
standardized
technology
on
a
fundamentally
a
code
base
in
technology.
That's
moving.
These
are
not
necessarily
diametrically
opposed,
but
they're
different.
So
just
quickly
quick,
taxonomy,
again
I'm,
expecting
people
in
this
presentation
to
be
listening.
A
A
So
next
thing
I
wanted
to
mention
in
the
last
three
years
open
source
foundations
in
the
history
of
the
internet.
Over
the
last
10
years,
every
foundation
seemed
to
beget
another
foundation.
I
mean
it
was
biblical
the
how
how
fast
those
foundations
could
reproduce
everybody
with
the
technology
or
a
project
wanted
to
create
a
new
foundation
around
themselves
and
have
a
community
and
just
to
keep
this
simple.
A
It
meant
that
you
had
to
invest
in
it,
and
so,
in
the
last
several
years,
the
Linux
Foundation
has
taken
a
number
of
these
different
projects
and
now
created
an
umbrella
projects.
Now
the
point
here
isn't
just
there
overall
governance
goals,
it's
that
even
the
organizational
structure
of
communities
and
how
they
interplay
and
interact
is
fundamentally
more
dynamic
than
we
may
be
seeing
in
standards
bodies.
A
And
so
let's
talk
about
specifically
what's
happened
since
91
in
the
ITF
draft
was
recently
put
out
on
how
to
normatively
reference
an
open
source
community
from
that
draft
I've
worked,
I've
talked
with
those
authors
at
least,
and
there's
a
number
of
pitfalls.
To
avoid
one.
Is
that
you're
chasing
behind
the
code
trying
to
document
what
it
actually
did?
That
is
a
very
challenging
path
to
to
actually
get
there
and
realizing
that
open
source
projects
aren't.
A
Necessary
documentation
and
every
community
can
actually
choose
the
level
quality
and
structure
of
those
documents
as
they
like,
because
the
code
is
the
documentation.
Second,
the
the
sorry,
the
claim
from
the
ITF
that
there
must
be
multiple
operable
interoperable
instances,
isn't
necessarily
the
goal
of
that
community
they're
working
quickly,
iteratively
on
one
particular
architecture.
For
this
and
in
general,
to
make
my
point.
A
If
there's
major
architectural
flaws
or
if
there's
issues,
then
another
community
will
form
to
solve
those
those
flaws,
and
so
there's
there's
fundamentally
different
goals
of
inner
operation,
because
one
is
a
solve
a
problem
in
a
use
case
that
we
have
and
the
goals
potentially
of
that
normative
reference
may
not
be
met.
So
a
couple
things
that
I've
talked
about
with
the
author
here,
all
the
way
again
I
think
this
is
critical
work
it's
necessary,
but
not
sufficient
to
be
able
to
have
cross
SDO
and
open
source
communication
as
well
as
progression
together.
A
A
A
That's
my
point
and
then
there's
other
other
nuances
of
working
at
platforms
and
api's,
and
in
particular,
that
many
projects
or
communities
have
sub
projects
within
their
architectures
and
if
you
only
want
to
refer
to
or
have
a
reference
normative
reference
to,
one
particular
module
or
one
particular
piece
that
needs
to
be
worked
through.
I
think
it's
critical
to
be
able
to
normative
leave
reference,
open
source
and
code
etc.
But
some
more
work
needs
to
be
done
here
to
make
this
work.
A
Second
and
we're
gonna
go
into
a
couple
examples
right
now:
the
Eng
catalog
work,
which
many
of
you
know
something
about-
is
an
experimentation
from
the
IETF
side
to
create
a
live
set
of
models
for
networking
devices,
keeping
it
simple
that
actually
is
not
trying
to
produce
documents.
It's
trying
to
produce
live
models
that
that
can
work
together,
and
this
becomes
critical
as
an
experiment,
because,
frankly,
we
can
show
it
as
success
and
the
reason
why
it
was
a
success.
A
Frankly,
as
you
can
see
listed
in
numerically
one
through
six,
a
number
of
tools
were
built
around
this
for
education
for
referencing,
for
compilation
for
dependency
checking.
This
is
what
searching,
etc
the
application
of
metadata
that
we'll
talk
about
to
be
able
to,
describe
and
and
put
measure
metrics
and
variables
around
the
different
models
that
utility
of
tooling-
and
many
of
you
worked
on
at
the
hackathon-
became
critical,
so
that
metadata
from
a
code
point
of
view
becomes
one
definition
of
a
health
metric
as
depending
on
the
data
that's
put
in.
A
But
what
I
personally
find
most
interesting,
because
I
think
this
is
the
path
forward
for
sto
relationships
and
multi
sto
relationships
as
well
as
to
open
source
is.
There
is
a
dependency
diagram
instead
of
having
the
IETF
state
in
the
industry.
All
yang
models
done
here.
There
is
a
relationship
that
the
broadband
form,
the
MAF
and
a
wide
variety
of
other
stos,
as
well
as
open
source
projects.
A
Open
config
is
the
big
conversation
as
well
are
producing
these
models
for
their
specific
technologies
and
areas
of
the
industry
that
they're
trying
to
work
on,
and
this
dependency
graph
actually
pulls
them
together
into
one
unified
place
and
therefore,
with
the
metadata,
the
compiler
can
show
that
the
entire
system
can
work
so
that
this
is
gonna,
be
a
recurring
theme
from
here.
A
couple
of
other
pieces
that
came
out
was
looking
at
the
communities
at
the
Linux
Foundation,
the
overlap
between
IETF
technology
and
open-source.
A
So
this
is
taking
that
dependency
graph
up
one
level
and
what
becomes
interesting
about
this
in
conversations
with,
hopefully
within
the
IETF,
we're
catalyzing
conversations
towards
this
end.
This
shows
where
I
ATF
technology
is
being
used
and
therefore
influence
is
already
occurring
and
can't
occur
to
a
greater
degree,
and
it
shows
where
there's
an
on
overlap
and
the
ITF
can
say
we
better
pay
attention
here.
A
We
better
go
see
what's
going
on,
because
we
have
a
long
history
here
at
the
ITF
of
understanding
how
to
do
things
securely,
etc,
and
perhaps
some
of
these
communities
can
take
advantage
of
that
as
well
as
perhaps
we
can
make
sure
that
the
implementation
is
done
well
and
not
with
other
not
causing
other
issues.
Couple
lessons
from
this
immediately
once
I
said
that
the
data
models
were
alive.
The
goal
of
this
effort,
even
though
sponsored
by
the
IETF,
was
not
the
RFC
ID.
A
It
was
being
able
to
point
to
a
live
tree
of
dependent
models
that
together
being
worked
on
independent,
though
we
worked
on
independently,
create
the
new
way
to
operate
a
software,
software
driven
Network
or
a
model
driven
Network,
and
so
that
that's
been
a
fascinating
thing
to
learn
about
this,
and
you
can
see
that
over
300
modules
are
are
now
using
this.
The
next
one
was
when
we
went
through
the
education
program
or
when
the
leaders
of
this
project
did.
It
was
develop.
A
The
tools
for
your
customers
and
the
customers
are
not
necessarily
solely
the
ones
at
the
IETF.
It's
for
these
other
stos
and
open
source
communities
and
through
continued
tooling,
simplify
the
development
process.
So
this
is.
This
has
been
a
very
good
experiment,
but
taught,
as
we've
potentially
talked
to
this
week
and
on
email
lists
about
is
a
2.0.
A
2.0
I
want
to
give
you
another
quick
example:
it's
one
m2m
very
similar
if
you're
familiar
with
this,
it's
related
to
IOT
just
to
keep
it
simple
and
if
you're
do
work
in
IOT,
you
know
that
it
is
one
of
the
most
fractured
industries
ever
created
by
mankind
and
here's
a
bunch
of
logos
of
the
groups
that
that
claim
to
have
the
sole
answer
for
IOT.
That
was
a
joke
by
the
way.
A
Another
level
rolls
out
like
this,
so
I've
gotten
completely
drunk
on
my
kool-aid
that
the
way
to
understand
the
impact
of
a
technology
is
not
on
the
RFC
ID,
but
on
the
product
of
the
RFC
and
the
product
of
that
RFC
is
represented
by
a
multi
sto
multi,
open
source
community
dependency
graph,
which
in
fact
is
what
the
industry
ends
up
using
to
drive
what
they
need
to
solve
in
the
industry.
So
a
couple
of
other
things
that
we
couple
of
other
things
that
we
tried
following
91
yaari
Arco
was
the
IETF
chair.
A
At
the
time
we
decided
hey,
let's
bring.
Let's
just
try
something
simple:
it's
being
done
all
over
the
industry:
let's
just
bring
hackathons
to
the
IETF
and
thankfully
we
got
a
chance
in
continuing
work
with
Charles
EKKO
who
really
brought
this
together.
Here's
a
picture
of
all
of
you
hacking
just
last
weekend
and
it
and
I'll
show
you
in
a
second.
It
has
become
one
of
the
most
relevant
ways
to
grow,
not
only
IETF
participation
but,
of
course,
take
IETF
technology
and
create
open-source
communities
around
it.
A
What's
interesting,
though,
with
the
yellow
line
are
the
individuals
who
are
only
coming
to
the
hackathon
and
not
staying
for
the
meeting
interesting
to
consider
whether
or
not
we
can
do
quote
better
outreach
to
the
coders
and
the
developers
of
the
open-source
community
for
the
technology
by
simply
taking
advantage
of
the
folks
who
were
coming
to
the
beginning,
part
of
a
hackathon
just
a
just
a
quick
bit?
This
is
showing
and
blue
in
green
between
99
900.
A
The
platform
for
network
data
analytics
open,
daylight
and
phyto
for
the
forwarding
plane,
but
in
reality,
I
want
to
make
sure
that
this
isn't
a
complete
list
nor
exhaustive.
But
it's
a
really
really
long
list
of
IETF
technologies
that
are
actually
being
developed
in
communities
created
around
that
technology
here
at
the
ITF,
and
that
is
the
best
news
so
therefore
to
get
the
modules
of
technology
that
are
being
created
into
open
source
and
to
get
those
architectures
that
I
showed
you
built
out
of
this
technology.
A
This
is
again
another
path
forward
that
we
should
think
about.
So
let's
take
a
pause
for
a
second.
Why
again
do
we
do
we
care
about
this?
We
care
about
this
because
the
end
operators
and
deployers
of
networks,
end
of
this
of
this
technology
are
in
fact
investing,
and
this
is
seen
by
membership
in
those
those
open
source
communities
and
their
investments
in
those
open
source
communities
that
one
they
want
to
learn
it
too.
A
They
want
to
understand
it,
of
course,
and
three
they'll
even
want
to
be
able
to
modify
it
themselves
also,
but
they're
also
doing
it
for
a
purpose
of
simplification,
and
this
is
a
slide
from
Bell
Canada,
which
shows
here's
the
list
of
current
I/o
technologies
that
we
have
deployed
and
the
slide
isn't
even
big
enough
now.
I
have
to
admit.
This
also
represents
a
lot
of
things
that
I
worked
on
my
career,
so
a
tear
is
shed
because
the
the
list
in
the
middle
is,
in
fact
the
new
modern
technology
I.
A
You
have
two
technologies
that
they
want
to
go
to,
but
the
way
they're
consuming
those
technologies
is
via
those
open
source
projects
that
I
mentioned
in
the
bubble.
In-Between
it's
a
it's,
a
fascinating
just
transition
of
network
operation
to
the
inclusion
of
open
source
and
we're
they
looking
for
make
it
simpler.
We
want
to
be
involved.
We
want
to
help
code
ourselves.
We
need
to
understand
how
this
stuff
works.
So
a
couple
quotes
again
from
one
from
Centrelink.
First,
we
don't
we
want
to
do.
A
We
use
open
source
because
it's
fast
and
again,
we
want
to
be
involved
in
second
from
Bell
Canada.
We
want
to
be
able
to
not
only
potentially
progress
the
standards
but
progress,
the
functionality
to
solve
our
problems,
and
we
can
do
that
in
code.
So,
let's
just
do
a
quick,
I
promise,
a
quick
talk
about
what
other
SD
O's
have
done.
A
Besides
IETF
in
case
you
haven't
been
following
those
first,
the
MAF
has
fundamentally
changed
the
trajectory
of
what
they
work
on
based
upon
their
membership
and
we'll
just
talk
about
this
for
a
second
there's
about
two
hundred
and
ten
members
and
those
are
large
enterprises
and
telcos.
First,
they
needed
to
reinvent
themselves.
A
That
I
meant
that
I
showed
just
a
second
ago
that
had
a
notion
of
orchestration
and
then
model-driven
api's,
based
on
yang
to
those
devices
and
the
services
that
come
from
that.
We
also
brought
our
Charles
Echols
brought
said:
hey
man,
hackathons
are
working
great
in
other
standards
bodies
and
you
have
this
architecture.
You
want
to
build.
Why
don't
you
build
that
architecture
and
code
as
you're
also
trying
to
specify
this
at
the
same
time?
A
So
Charles
is
basically
a
one-man
army
out
there
trying
to
get
standards
bodies
to
realize
the
value
of
producing
the
code.
At
the
same
time.
Second-
and
this
is
also
fascinating
for
the
is
a
2.0
conversation-
the
MAF
invested
in
infrastructure,
compute
storage
and
networking
to
build,
deploy
and
certify
their
new
architecture
on
so
play
to
discuss
again
about
the
future.
The
ITF,
the
MAF
different
than
the
ITF,
is
a
very
bounded
architecture
and
therefore
a
bounded
target.
And
once
again,
you
take
a
look
at
the
tools
that
are
most
popular
in
that
standards
body.
A
Perhaps
a
shock,
perhaps
not
a
shock
very
similar
to
the
tools
that
represent
IETF
standards.
It's
standardized
technology
as
well,
but
there
is
always
the
case
that
you
know-
and
it's
definitely
been
the
case
that
there's
still
a
fight
out
there
for
sto,
relevancy
or
standards
body
relevancy
and
in
some
cases,
a
defensive
territory.
A
And
so
there
are
a
ton
of
stos
and
they're
cropping
up
all
across
the
industry,
related
to
different
vertical
industries
or
different
universe,
parts
of
the
infrastructure
like
IOT,
etc
and
don't
be
confused
by
people
sticking
a
flag
and
saying
this
is
our
turf
and
work
is
going
to
happen.
That's
obviously
not
the
case
and
also
don't
try
and
mop
up
behind
and
I'm
gonna
say
that
clearly
mop
up
behind
the
coders
and
and
write
specifications
over
what
was
done
in
the
code.
These
often
times
that
code
is
is
experimental.
A
So
when
choosing
the
partnership
with
the
open-source
community,
a
few
things
to
take
a
look
out
there,
there
are
a
ton,
if
not
more,
open-source
communities.
You
can
see
this
in
the
rise
of
the
use
of
github
etc.
As
mentioned
earlier,
open
source
similar
to
standards.
Bodies
of
course,
is
driven
by
potentially
larger
organizations
trying
to
create
strategic
market
and
technology
development
and
set
a
trajectory.
It
happens
in
standards.
It
happens
in
open-source,
that's
obvious,
but
let's
just
call
it
out.
A
A
So
in
a
little
bit
of
a
provocative
statement,
I
put
up
here
where
Green
is
good
and
weird
pink
is
bad
of
different
standards,
organizations
that
have
tried
to
work
with
the
open-source
model
and,
as
you
read
some
of
the
details,
you
can
see
potentially
or
at
least
what
I'm
calling
out
to
be
the
success
or
failure
criteria
of
those
different
organizations,
and
it's
not
that
CableLabs
is
doing
swimmingly.
It's
just
potentially
comparatively
to
the
others
they're
finding
some
success
because
CableLabs
is
not
doing
swimmingly
is
what
are
there.
A
So,
let's
just
talk
about
a
couple
things,
so
it's
frequently
been
acclaim
a
look.
Other
other
bodies
are
doing
certification.
If
we
have
an
IETF
certification
associated
with
our
technology,
will
expand
and
will
show
our
influence
over.
This
there's
been
failure
situations
as
well
as
well
as
successes.
So,
let's
talk
about
those
one
again,
poor
specification
in
this
case
in
the
Java
community,
the
the
specification
and
reputation
for
that
specification
became
so
bad
that
certification
became
meaningless.
A
Second,
the
Etsy
and
if
V
architecture
and
opie
NFV
what's
interesting,
is
OPN
of
these
trying
to
run
a
certification
play
and
in
states
that
they
have
this
alliance
with
Etsy,
but
doesn't
test
against
that
Etsy
architecture,
kind
of
interesting.
How
that
all
works
out
so
again
be
careful.
The
one
that's
primarily
claimed
to
be
a
great
success
is
3gpp.
Where
that
certification
allowed
multiple
interoperable
products
to
be
built,
we
will
see
if
this
works
for
5g
whatever
5g.
Is
it
apparent?
It's
apparently
everything,
but
nonetheless
telephone
now.
A
A
Give
me
a
bunch
of
use
case
drafts,
give
me
an
architecture
draft,
and
when
you
get
all
that
done,
we
can
go
work
on
the
actual
technology.
This
is
a
great
place
to
go
mining
for
those
concrete's
use
cases
and
communities
that
are
working
towards
them.
So
the
last
one
I
want
to
mention
back
on
m2m
is
the
open
connectivity
foundation
which
a
very
new
organization,
but
here's
my
point.
They
have
pulled
out
all
the
stops:
certification,
testing,
open
source
standards,
device
models,
etc.
A
Even
though,
of
course,
our
eot
is
quite
large
but
mild
tangent
at
this
point,
which
is
that
how
to
how
to
pick
an
open-source
partner,
no
matter
what
you
hear
in
marketing
or
whatever
the
case
might
be,
and
even
in
this
conversation,
because
it's
open
source,
it
doesn't
mean
it's
magic,
nobody's
riding
unicorns
over
rainbows,
just
because
it
happens
to
be
open
source.
Remember
it's
just
code,
which
means
it's:
the
output
of
people's
extremely
hard
work
to
solve
a
problem
and
there's
law.
A
I
want
to
then
put
this
into
some
kind
of
map
for
reference
going
in
the
upwards
direction
is
commercialization
versus
individual
representation,
and
going
from
left
to
right
is
the
notion
of
free,
complete,
open
use
to
a
closed
environment,
taking
a
look
at
potentially
some
of
that
open
source
work.
This
is
just
one
person's
way
of
putting
things
into
a
diagram
and
onto
a
map
of
the
commercialization
and
the
influence
of
specific
enterprises
and
vendors
towards
the
contributions
and
directions
of
these
groups.
A
A
If
you
don't
adopt
open
source,
you
just
in
to
make
my
argument,
things
become
niched
and
very,
very
specific,
and
that's
still.
Ok,
but
again
it's
the
scope
of
influence
in
the
industry
and
trajectory
is
different
in
this
case.
So
just
the
here's,
the
partner,
here's
the
narrative
associated
with
this
section
really
is
that
success
is
when
there's
gonna
be
friendly
common
goals,
sorry
friendly
communities,
open
cultures,
common
goals
and
IP
alignment.
A
But
you
need
to
really
pay
attention
to
the
contributor
license
agreement,
because
that's
that's
where
some
of
the
the
real
pieces
and
relationship
with
the
foundations
who
are
governing
potentially
or
at
least
render
business
operations
of
those
communities
are
potentially
again
only
potentially
adding
some
overhead.
Now,
there's
a
few
pitfalls
here
again,
because
open
source
is
expecting
any
but
usable
by
anybody
and
and
sent,
and
at
no
charge,
and
though
Randle
licensing
that
we
have
in
some
standards.
A
Bodies
is
fundamentally
different
than
that
and,
as
you
can
see
see
in
some
of
these
other
pieces,
this
is
a
real
conversation
to
have
and
of
it
it's
at
one
scene
of
the
movie,
not
at
the
first
scene,
but
at
a
couple
scenes
into
the
movie.
Where
are
the
way
that
we're
thinking
about
the
preservation
of
intellectual
property
rights,
aligned
across
standards
and
open
source?
It
always
comes
down
to
lawyers
I'm,
not
a
lawyer,
but
nonetheless,
these
issues
are
real
and
we've
had
to,
of
course,
work
through
them.
A
So
what
I
wanted
to
move
to
the
next
section
and
and
kind
of
get
to
get
to
some
recommendations?
Maybe
I'll
talk
about
in
three
years
is
standards
just
creating
documents
evolved
into
someone,
who's,
building
functional
code
trying
to
solve
problems.
But,
in
my
opinion,
the
industry
leader.
The
future
is
one
that
is
understanding
that
there
are
multiple
communities
that
need
to
be
influenced.
A
So
there's
some
choices
for
the
IETF
along
these
lines
from
do
absolutely
nothing
and
potentially
be
focused
on
very
specific
technology
niches
work
in
the
middle
and
have
some
communication
going
back
and
forth
and
and
continue
the
open-door
policy
of
the
IETF,
which
is
hey.
If
you
want
to
standardize
something
come
to
us,
realize
that
one
of
the
most
important
roles
in
an
open-source
community
is
in
fact,
community
outreach,
which
is
hey
we're
working
on
this.
Do
you
want
to
work
on
this
together,
I'm
summarizing?
A
What
the
role
is,
but
that's
effectively
what
the
description
is
and
then
for
vigorous
relevance.
Consider
changing
the
process
again
live
repositories
of
like
in
the
yang
catalog,
as
I
mentioned
earlier,
and
work
realizing
that
it's
a
multi,
sto
and
multi
open-source
world.
So
really
the
meta
point
of
that
I
can't
look
at
the
world
through
the
keyhole
of
one
particular
piece
of
technology
we
have
to
it.
A
You
have
to
accept
as
a
technologist
that
what
you're
creating
has
a
very
specific
role
in
a
larger
ecosystem,
and
at
least
what
gets
me
very
excited
about
being
an
engineer
is
getting
my
technology
out
there
and
being
used
and
being
used
in
multiple
new
and
different
ways
or
the
larger
community
that
are
going
to
extend
it
and
use
it
in
ways
that
I.
Never
thought
of
the
next
piece
here
is
enable
that
tooling
support.
A
So
I
have
mentioned
a
couple
of
times
that
the
creation
of
this
tooling,
the
ITF,
has
no
way
to
accept
this.
We
have
no
I,
have
no
way
to
potentially
hand
over
some
things
that
could
be
compilers
dependency,
mappers
blah-dee-blah,
but
that
does
appear
to
me
to
be
a
fantastic
way
to
understand
that
relationship
and
that
tooling,
is
really
setting
the
industry.
A
Trajectory
for
how
many
standards,
bodies,
communities
and
organizations
will
work
together
and
understand
the
relationship
so
taking
a
look
at
some
open-source
project,
Genesis
I
want
to
harken
back
to
three
years
that
in
the
early
days
of
Sdn
and
NFV,
there
were
many
boss.
There
was
many
conversations.
A
I
even
gave
a
couple
of
talks
on
this
that
there
are
things
we'd
like
to
to
standardize
here
and
need
to
standardize
here
whether
it's
protocols,
state
machines,
events
packet
formats
and
then
all
the
way
up
to
api's
and
platforms
potentially
and
this
organization
and
frankly,
no
other
standards
or
organization
really
took
up
that
charge.
That's
okay!
A
So
the
call
here
really
is
you
do
need
to
seek
out
projects.
I'm
gonna
give
you
one
example
at
the
bottom
of
spiffy
and
inspire
that
are
fundamentally
modifying
technologies
defined
as
standards
here
at
the
IETF
in
their
open
source
community
and
continue
to
evolve
their
code
and
continuing
to
evolve
their
definition
of
a
new
standard
in
specification.
A
A
The
the
point
here
is:
is
the
the
middle
sub
bullet,
which
is
that
out
that
creation
of
the
platform
of
platforms
of
these
dependencies,
the
dependency
maps,
also
allow
you
to
understand
where
the
open-source
communities
are
going
in
into
it,
also
which
technologies
could
help
a
particular
open
source,
community,
etc,
and
so,
as
has
been
done,
we
don't
necessarily
at
the
IETF
at
the
notion
of
relevancy
metrics
health
metrics
associated
with
a
particular
standard.
We've
talked
about
what
makes
a
successful
standard,
without
necessarily
applying
those
metrics
across
the
board
to
all
standards.
A
Efforts
here,
but
I
want
to
remind
you
again,
there's
no
academic
or
theoretical
basis
of
what
is
the
definition
or
what
are
the
variables
of
a
healthy
open-source
technology
and
a
healthy
open-source
community.
And
if
there's
gonna
be
a
relationship
between
standards
bodies
and
open
source.
Those
two
things
need
to
be
understood
potentially
independently,
so
as
as
I'm.
A
How
to
institutionalize
hackathons
is
really
just
a
starting
point,
but
it
allows
the
conversation
which
can
also
occur
in
parallel,
that
the
RFC
ID
should
not
be
the
only
metric
for
the
IETF,
and
that's
really
the
claim
here
that
the
product
of
the
RFP
RFC's
is
the
return
on
investment
and
the
value
associated
with
the
modular
technology
being
created
here.
And
so,
as
you
can
also
see
the
notion
of
iterating
standards
and
certainly
live
revision
control
systems
containing
in
this
case.
The
yang
models
is.
A
That's
done
a
lot
of
the
private
funding
for
some
of
these
tools
and
some
of
these
other
pieces
I'm
really
looking
for
a
way
to
partner
with
the
IETF
or
partner,
with
I
sock
and
also
partner
with
open
source
communities
to
bring
this
tooling
and
create
a
community
around
this,
not
saying
that
necessarily
the
money
is
going
to
dry
up,
but
it's
not
positive
for
the
longevity
of
this
particular
idea
towards
a
trajectory
if
the
ITF
wants
to
take
it
on
to
simply
have
it
in
private
hands.
That's
my
only
point
there.
Let's
we.
A
This
is
a
way
that
the
ITF
can
directly
work
in
open
source
because
their
processes
are
also
driven.
This
way
so
I've
come
to
the
end
of
my
slides
and
willing
to
take
any
questions.
I
made
again,
a
number
of
outrageous
and
contentious
statements
here
proved
merely
through
emphatic
assertion
and
so
by
all
means
any
questions
or
comments
that
you
may
have
I'd
be
willing
to
discuss
with
you.
B
Know
I'm
Michael,
Abram
son.
You
had
IPR
there
on
one
slide.
Where
do
you
think
we
are
in
three
to
five
years
when
it
comes
to
IPR
and
open
source
and
SDO
is
because
everything
is
getting
patent
and
like
the
people
are
paid
for
the
patent,
and
it's
just
patent
writing
machine
out
there
for
everybody.
What
do
you
think
we
are
in
three
to
five
years
so.
A
I'm,
not
a
lawyer,
god
only
knows
what
lawyers
are
gonna
figure
out.
I
know
they'll
figure
out
how
to
take
our
money,
but
other
than
that
I
actually
probably
see
something
towards
more
the
open
licensing
that
that
we
see
out
of
apache,
Eclipse
or
BSD,
or
something
along
those
lines
versus
Rand
because
and
that
we
do
it
standards.
Just
to
summarize
my
point
is
you
know
you
can
use
this.
If
you
don't
sue
me
and
I
won't
sue
you
and
any
time
I
feel
like
taking
that
away.
A
C
Tom
Mizrahi
Marvel,
you
mentioned
the
hardware
open
source
and
obviously
it's
not
evolving
as
fast
as
open
source
software.
Obviously,
vendors
hardware
and
silicon
vendors
are
not
as
interested
to
go
into
that
very
quickly.
So
I
wonder:
what's
your
perspective
about
what
we're
going
to
see
three
years
from
now?
A
A
D
A
A
feature
and
it's
a
feature
because
a
lot
of
the
implementations
have
different
design
patterns,
as
well
as
different
architectural
goals.
Different
functional
goals
can
scale
and
or
perform
in
different
mechanisms,
and
that's
the
purpose
of
having
different
design
patterns
and
protectors
and
software.
None
of
it
may
have
to
be
standard
and
in
fact,
what
it
lets
say.
The
eventing
api's
platforms,
as
well
as
protocols
are
fully
standardized,
but
what's
in
between
is
dramatically
different
and
they
appear
to
be
working
towards
the
same
problem.
I
encourage
it
I
think
it's
a
feature
not
about
thanks.
E
And
bran
gondwana
I'm
more
from
the
applications
world,
rather
than
the
lower
level
things
and
in
our
world.
Certainly
ITF
standards
come
through
asks,
a
bunch
of
pros
and
possibly
some
a
B
and
F
and
implementation
quality
is
very
dependent
on
how
well
somebody
read
the
standards
in
the
IMAP
world
in
particular.
There's
a
lot
of
very
bad
implementations
out
there,
because
it's
a
long,
complex
standard
and
people
aren't
reading
it
very
well.
I
would
say
that
testing
is
actually
more
important
than
the
pros
in
some
ways.
E
We
should
be
having
a
way
to
check
your
implementation
against
the
standard
which
isn't
read
the
whole
standard
and
see
if
you
got
everything,
because
that
doesn't
scale
and
where
you
said
you
need
to
automate
for
it
to
work,
you
need
to
automate
testing
that
your
codes
correct
to
implement
a
standard
reliably.
So.
A
I
agree
with
you
and
and
what's
interesting,
is
that
there's
at
least
been
one
open
source
community
fti?
Oh,
that
actually
was
one
of
the
first
to
create
a
functional
performance
and
scaling
test
framework
associated
with
the
open
source
they
were
creating,
which
was
matched
up
against
the
proper
protocol.
Behavior,
so
I
agree
that
it's
just
it's
a
it's
not
necessarily
a
norm
now
I
want
to
tease
back
from
just
talking
about
one
community
and
what
they
do.
A
But
as
I
as
I
showed
in
a
couple
of
my
examples
of
doing
testing
and
certification
based
upon
complex
challenging
standards,
the
standards
weren't
good
enough.
The
code
wasn't
good
enough.
This
certification
didn't
matter
because
none
of
the
often
secrets
either
previous
to
for
all-
and
so
it's
not
a
guarantee
that
even
high
quality
testing
is
going
to
evolve
properly.
E
Comparison
point
I
would
give
hit
down
again.
Is
acid
testing
for
web
browsers
once
the
acid
test
came
out
and
just
gave
you
a
score
out
of
100?
How
good
is
your
browser?
Everyone
wanted
to
have
a
better
score,
because
users
could
look
at
this
and
say
well,
your
browser
and
against
23%
mine
gets
25%
better
and.
A
The
MAF
actually
on
the
infrastructure
side,
the
MAF
actually
has
that
with
certification
and
potentially
some
caveats,
but
I
appreciate
that
a
scoring
mechanism,
but
that
is
beyond
necessary.
That's
an
industry
scoring
mechanism
that
it
is
necessarily
a
standards
body
scoring
mechanism
yeah.
In
that
case,
thank
you.
The
man
himself,
Charles
suckle,
yeah.
F
But
what
you're
talking
about
here
made
me
think
that
we
need
to
go
probably
beyond
that
and
for
things
to
really
get
deployed
to
produce
code
that
isn't
just
a
proof
of
concept,
but
is
actually
a
usable
library,
something
that's
that's
solid
and
that
people
can
build
on
top
of
something
that
has
good
api's.
That
type
of
thing
is
that
something
that
we
should
tackle
within
the
ITF,
or
do
you
think,
there's
other?
We
should
go
outside
to
make
that
happen
and
produce
those
types
of
libraries.
So.
A
When
you're
talking
about
trying
to
create
something
that
solves
a
functional
problem
and
can
be
potentially
used
in
production
or
product,
that
is
actually
defining
the
creation
of
an
open-source
community,
whether
that
can
be
done
inside
the
IETF
and
can
be
governed
funded,
supported
as
well
as
a
community.
A
developer
community
inside
the
ITF
or
related
to
the
ITF
can
be
created
yet
to
be
determined.
But
if
that's
a
strategic
to
directory
that
the
ITF
wants
to
go
on,
they
potentially
could
meet
that.
G
Okay,
my
name
is
Richard
Saul's
and
I've
been
involved
in
a
lot
of
the
similar
kind
of
junctions
on
a
different
scale.
Smaller
scale
I
think
one
thing:
there's
a
challenge
in
this
stuff
is
that
the
foundations
or
the
level
of
infrastructure
support
you
need
differs
greatly
by
projects.
On
the
one
hand
you
have
OpenStack
and
on
the
other
hand,
you
know
you
have
the
tiny
guy
in
his
garage
with
the
ntp
foundation.
I
think
there's
an
opportunity
for
the
IETF
to
help
the
stuff
and
also
tap
into
some
kind
of
revenue
stream.
A
Think
that's
a
great
conversation
for
consuming.
It
is
a
2.0
and
and
we're
and
getting
to
a
point
where
we
can
not
just
discuss
the
new
operational
model
of
the
IETF
and
IROC
relationship,
as
that
may
be,
but
the
actual
goals
of
the
organization
that
you're
Ector
gonna
be
on.
So
thank
you,
okay.
So
thanks
everybody
I
appreciate
the
time
today
hope
it
was
interesting
for
you
and
catalyzes
some
thought
and
conversation.
Thank
you
very
much.