►
From YouTube: IETF99-OSPF-20170718-1330
Description
OSPF meeting session at IETF99
2017/07/18 1330
https://datatracker.ietf.org/meeting/99/proceedings/
C
B
B
B
G
H
B
J
L
J
D
K
K
D
G
L
H
J
We
have
work,
you
wrote
last
call
on
two
things.
One
of
the
things
is:
we've
been
slowing
down
work
because
there
may
be
some
other
graphs
that
are
ready,
but
we've
been
discussing
these
and
I.
Don't
given
the
low
volume
anyway,
I
didn't
want
to
try
and
force
everything
through
at
one
time,
so
I
think
we
can
do
that.
So
we
have
the
segment
routing.
J
The
extensions
I
didn't
update
the
slide,
but
Peter
just
updated
it
based
on
today,
before
the
meeting
with
comments
from
the
ops
review
from
sue
Harris
and
just
one
other
comment
to
read
better
in
the
in
the
logic
for
inner
area,
propagation
of
segment,
routing
sits
and
the
tunnel
encapsulation.
We
I,
don't
know.
If
you
saw
my
note
on
the
list.
We
had
this
all
discussion
about
common
registries
and
the
problem
was
with
BGP.
It
was.
J
J
Link
overload
I
think
we
have
consensus
boots
on
this.
We've
had
some
discussions
on
this
and
it's
it's
going
to
use
just
it's
just
gonna,
be
an
area.
Sculpt,
I,
think
area,
scope,
I,
think
what
people
are
more
comfortable
with
area
scope.
Now
anybody,
because
normally,
if
you're
in
a
service
provider
network
where
they
would
use,
link
overload,
you're,
probably
gonna,
have
the
link
attribute
LSA
anyway
for
the
adjacency,
see
it
or
something
else.
So
you
might
as
well
I
mean
I,
think
I
think
having
a
single,
simpler
solution
is
better
each
bit.
J
J
Prevent
transit
traffic
between
a
node
also
also
I
added
something
somebody
that
we
that,
in
this
update
3107
somebody
had
commented
to
me
that
3107
didn't
handle
the
case
of
the
type
to
metric
and
a
sternal
LS
ace
that
you
would
still
use
the
type
to
metric
because
it's
considered
higher.
So
if
you're
a
self
originating
any
type
to
metrics.
You
should
also
put
that
to
Max
metric
and
I
got
an
update
today
on
extended
LS
A's.
J
F
F
J
Right
right
right
that
Stewart
Stewart
straps
yeah-
yes,
yes,
always
be
a
yang
model.
There's
an
update
today
and
this
we
haven't
really
done
in
too
much
with
this
simple
extension,
but
across
te.
This
is:
where
are
you
you
allow
just
to
specify
te
and
one
of
the
protocols
o
SP
to
f2
or
OSPF
III,
and
you
can
put
endpoints
for
the
tunnels
of
either
address
pipe.
J
In
her
face
LS,
we
still
need
that
it
was
accepted.
We
still
need
allocation
of
the
LSS
code,
point
s
re
yang
model
that
will
be
covered
today.
It's
been
broken
out
for
no
SPF
yang
model
in
case,
because
just
about
everything
in
the
well,
not
just
about
everything
in
the
OSPF
model
is
a
pretty
mature
feature.
Well,
this
has
been
evolving,
at
least
over
the
last
couple:
IETF
this
SR
stuff,
both
the
base
SR
model
for
yang
and
function
itself
and
screed
label
I'm
waiting
for
them
to
update
the
draft.
J
We
had
discussions
in
Chicago
on
this
and
we'd
agreed
on
the
definition
of
the
entry
label.
We
had
all
the
original
offer.
We
at
least
we
have
one
of
the
original
offers
of
entry
label.
Creedy
was
in
there
and
Bruno
and
Stefan
and
wim,
and
we
agreed
on
what
the
definition
of
the
depth
and
everything
and
all
the
parameters
so
I'm
just
waiting
for
a
update
on
that
draft.
Based
on
that
side,
meeting
and
flowspec
I
don't
know
this
mate.
J
J
J
Yeah
yeah
yeah,
that
could
be
it
well
yeah
this
one
this
one,
no
actually
the
is,
is
working
group
rejected
this
because
they
didn't
think
the
use
case
was
strong
enough,
and
this
was
this
was
for
distributed.
Das
Prevention
in
campus
networks,
and
so
I've
been
talking
to
the
I,
actually
haven't
offer
this
one,
but
it
because
I
helped
out
with
the
you
know
the
encodings
and
everything
but
I
think
we'll
just
let
it
die.
J
J
That
Tony
took
care
of
all
the
the
nets
and
I
had
questions
on
it
that
Tony,
P
and
Eric
took
care
of
so
I
I'd
like
to
encourage
other
people
to
review
it,
though
I
think
it's
pretty
much
ready
an
NC
camp
we've
given
once
the
C
camp
guys
got
to
three
levels
of
sub
TL
B's
with
all
the
WDM
stuff
and
the
optical
transfer.
We
quit
trying
to
keep
up
with
it.
F
M
M
So
this
draft
defines
the
Bayesian
model.
Here
is
the
summary
of
changes.
Since
last
IETF,
we
modified
the
model
to
be
consistent
with
an
MVA
format
that
was
suggested
by
IETF,
so
we
knew
there
was
some
changes
that
going
to
happen,
so
it
made
some
preparations
in
less
such
as
using
groupings
and
then
one-way
changing
to
this
time.
Ta
format.
The
effort
for
us
was
not
that
big.
So
it
didn't
take
us
long
to
do
this
change.
Just
you
know.
M
If
people
ask
what's
the
effort
to
change
this
big
OSPF
model,
we
also
modify
the
model
to
be
consistent
with
the
young
module
template
I
suggested
by
our
c60
87
of
hand.
Xe,
that's
mainly
editorial
changes,
and
so
something
new
in
this
model
is
we
remove
the
SPF
lock
when
I
did
SPF
lock
and
the
air
I
say
lock?
That
was
part
of
the
effort
eyes
on
language
is
ice
model.
M
We
remove
the
inheritance
so
because
the
feedback
we
got
so
far
is
it's
not
very,
it's
not
implemented
by
many
vendors
and
make
the
model
or
complicated.
So
we
decided
to
remove
it.
We
also
made
some
small
other
changes.
Such
as
we
for
the
OSPF
we
to
air
sa
ID
will
change
to
use
Delta
called
instead
of
IP
address
and
also
some
other
small
changes
and
all
those
small
changes.
You
can
look
at
them
kind
of
like
back
fake
sis.
For
this
model
we
are
trying
our
best
to
reveal
the
model.
M
M
So
the
current
status
and
next
steps,
this
model
is
feature
complete
and
after
changing
to
the
lamp
da
format,
I
think
the
model
has
reached
a
stable
state
and
we
do
have
some
dependencies
on
other
models.
For
example,
the
ATF
are
loading
tabs
that
we
use
in
the
we
import
in
the
model,
I
use
them.
That
way
is
in
working
group
last
car.
The
RFC
is
0
to
2
on
the
shouting
config
model
that
one
need
to
be
refactored
to
be
consistent
with
the
MDA
format.
M
Right
now,
the
only
thing
left
you
know,
OSPF
model
that
still
augments.
The
shouting
state
is
the
one
that
OSPF
augments
the
shot
attributes
like
the
adult
hobbies
in
inter
area
intra
area
that
have
so
dawa
has
right.
Now
is
the
indulging
state
and
nothing
else
is
in
it's
already
too
consistent
with
the
nmda
format.
M
Right
now
there
is
no
redistribution
defined
in
the
model
because
of
the
real
policy
model
that
has
expired
in
as
a
year
ago.
Pft
is
your
way
out.
Jeff
is
now
here,
so
we
are
going
to
have
a
VFD
meeting
list.
We
are
going
to
have
a
meeting
with
PFD
young
design
team
to
discuss
the
protocol
specific
configuration
parameters
that
they
well.
We
have
on
this
issue
how
come
backer
for
several
times
already,
so,
hopefully
they
after
this
cut
discussion,
we
can
settle
down
yeah.
M
We
we
used
to
have
a
separate
PFD
module,
define
B
protocol.
Specific
parameters
will
remove
it
now
o
see
what
happens
so
next
step.
We
need
a
young
doctor
review.
We
need
to
start
at
the
adulterer
review,
considering
the
site
of
this
model.
Maybe
we
we
need
modern,
one,
young
daughters,
to
start
a
review
process
because
it
may
take
some
time
and
then
we
will
ask
how
this
model.
M
M
M
J
J
D
J
Okay,
the
the
best
recent
development
is
that
we
have
two
productized
implementations
of
OSPF
extended
LSAs
for
OC,
Fe,
3
segments,
routing
and
I've
added.
The
two
offers
are
two
of
the
actual
implementers.
We
have
one
in
the
room:
direct
calls
from
Nokia
in
Antwerp,
AHA
and
Peru
from
belem
from
Huawei
in
Bangla
door.
J
J
I've
added
I've
added
a
skeleton
inflammation
to
those
bf
woof
key
implementation
survey
page
and
we're
gonna
experiment
with
this
use
this
for
to
put
the
results
of
that
out
to
that
from
the
OSPF
wiki
I
remove
the
boilerplate
and
put
some
things
in
so
we'll
have
room
for
more
stuff
and
I'll,
publish
it
on
the
wiki
and
point
to
it
from
Wednesday.
Once
that
it,
the
survey
is
going
to
ask
if
they
support
all
nine
types.
J
Really
the
only
new
piece
of
function
was-
and
this
was
this
was
carried
over
from
prefect
link
attributes
in
OSPF
v2
is
the
N
bit
and
I'll.
Ask
if
there's
full
semesters,
there's
full
support
or
partial
support.
What
we
call
the
sparse
mode
to
support
the
new
features,
both
at
the
area
and
incidence
level,
and
then
I'll
ask
if
the
applications
I
think
the
only
out
I'm.
J
Pretty
sure,
though,
only
both
both
vendors
did
this
to
support
segment,
routing
and
also
request
to
routing
or
Ave
will
no
we're
both
we're
both
offers,
I'll
request
it
anyway
from
them
ask
them
to
review
it,
and
one
thing
we're
gonna
have
to
so.
We
can
start
now
that
now
that
we
know
this,
this
is
proceeding
progressing.
J
Is
we
have
a
gap
draft
and
we
have
one
RFC
for
sure
that
needs
to
have
a
little
piece
in
it
that
references
this
and
updates
that
that's
the
two-port
part
metric
metric
and
maybe
I,
don't
know,
depending
on
how
fast
we
do
link
overload
might
put
I'll
get.
The
link
overload
will
advance
that
it
is
OSPF
b2
and
then
just
have
a
small
little
piece
in
this
same
draft
that
it
does
that
and
that's
it.
I
know
I
know
I
I'm
also
gonna
ask
about
interoperability
test
testing,
but
the
logistics
of
it.
J
J
N
K
K
G
J
E
C
Right
so
she's
a
very
quick
presentation
on
the
LLS
interface
ID
exchange.
So
what
it
is.
This
is
a
very
simple
extension.
What
we
want
to
do
is
we
want
to
use
the
OSPF
LS,
which
is
part
of
the
hello
to
exchange
the
interface
ID.
Instead
of
you
know,
using
any
other
mechanism,
there
isn't
mechanism
defined,
which
uses
the
local
scope,
the
epochal
si,
which
we
don't
make
redundant,
or
we
don't
very
people
can't
use,
but
we
believe
this
is
much
simple
and
easier
to
do
so.
C
The
same
mechanism
is
being
used,
you
know,
SP
v3
is
being
used
in
ice
is
so
we
are
just
trying
to
make
us
baby
to
do
the
same
thing,
so
this
stuff
became
the
working
group
document
is
really
published
with
a
different
name.
We
added
the
backward
compatibility
section
or
basically
we
say
if
you
use
post
mechanism
prefer
the
LLS.
You
can
still
continue
to
use
the
T
epochal
I
say
to
you
know,
communicate
the
interface
ID.
C
If
you
want
to
there
shouldn't,
really
be
any
backward
compatibility
issues,
because
the
value
should
be
the
same,
and
that
can
be
time
where
you
know
the
ID
changes,
which
should
not
normally
happen,
but
can
possibly
happen
where
these
two
values
may
for
a
very
short
interval,
be
different,
but
again
doesn't
really
cause
us
any
problem.
As
soon
as
you
look
at
one
of
the
values,
you
should
be
fine.
C
L
K
Early
atlas,
so
this
draft
was
when
the
first
request
first
came
in
right.
The
draft
had
just
been
adopted
and
I
haven't
seen
much
discussion
on
the
mailing
list
at
all
about
it.
If
it's
really
well
understood
and
stable
and
there's
agreement
that
folks
need
a
code
point
I'm
happy
to
have
that.
But
I
do
need
to
see
some
discussion
on
the
mailing
list
from
folks
in
that
regard.
I
just
hasn't
gotten
the
quality
of
conversation.
K
Yet
to
make
me
say:
oh
sure,
it's
a
zero
zero
working
group
draft,
let's
go
for
it,
I
mean
that's
all
you
just
please
read
it.
Please
provide
some
feedback
if
you
have
any
concerns
about
it
or
if
they're
pieces,
if
you
think
it's
stable
enough,
if
what,
if
you
read
it
and
you've
wrecked
you
and
your
response
is
yeah,
this
makes
great
sense.
K
K
Hear
you
and
I
appreciate
and
of
course,
work
that
comes
with
that
that
comes
with
running
code
already
is
always
very
valuable
because
it
tends
to
be
less
theoretical,
but
some
of
the
other
work
and
tends
to
have
fewer
gashes
from
things
not
being
thought
through
fully.
So
that's
really
useful,
but
it
is
still
a
pre
standard
implementation
and
the
question
is
whether
there's
gaps
in
words
written
down.
J
Before
one
so
we'll
start
discussion
on
that
and
then
maybe
we'll
have
like
they
do
an
IDR
after
some
discussion
and
an
allocation
call
like
that,
your
honor.
Now
there
is
now
now
I'm
much
less
concerned
about
this
space
than
I
am
say:
BG
pls,
where
there's
code
points
coming
from
all
these
different
graphs
and
and
we
have
collision
opportunities
galore
with
that
one.
But
that's
not
our
working
group
but
I'm
still
concerned
with
it,
because
we
have
some
implementation
that
could
have
these.
C
Okay,
so
there
has
been
already
an
interesting
discussion
yesterday
on
the
eye
size
working
group
about
this
trap.
This
is
the
OSB
version
of
it,
so
it
has
been
presented
so
many
times.
I
believe
strongly
believe
everybody
understands
what's
the
problem
and
we
even
have
the
existing
problem.
People
acknowledge
that.
So
that's
good
there's
been
good
amount
of
discussion
which
happened
on
the
ITF
meetings
and
on
the
working
of
Elias,
both
OSPF
Anaya,
sighs,
I.
C
Guess
we
have
a
problem
solve,
we
can't
say
it's
not
relevant
at
least
I
believe
so
so
same
problem
is
in
our
eyes.
We
won't
really
want
to
make
the
solution
to
be
the
same
in
both
protocols,
not
necessarily
the
encoding
part,
because
there
may
be
some
differences
due
to
the
differences
in
the
protocol
itself,
but
we
believe
the
solution
should
be
the
same,
and
obviously
there
is
a
draft
should
be
0-5
actually
so
what
we
change
from
the
last
time,
so
we
used
to
have
only
a
single
application
bit
mask
now.
C
We
split
that
and
we
advertise
the
standard
application
mask
and
the
user-defined
application
must,
because
there
has
been
some
people
saying
you
don't
want
only
the
standardized
application
we
want
to
have
the
flexibility
map
any
applications.
We
have
to
a
certain
value
and
then
advertise
the
various
values
of
the
attributes.
C
So
we
added
that
we
added
the
deployment
consideration
about
how
to
use
this
if
I
want
to
use
a
single
advertisements
for
all
the
applications
and
what
are
the
consequences
if
you
introduce
another
application
for
which
you
want
a
different
value
and
also
we
clarified
that
and
I.
Think
that's
very
important
for
everybody
who
is
looking
at
these
drafts
is
that
advertising
a
link
attribute
has
nothing
to
do
with
the
enablement
of
the
application
on
the
link.
We
strongly
believe
we
have
to
make
that
distinction,
so
we
have
clarified
that
in
the
draft.
C
So
there
has
been
a
working
group
acceptance
poll
which
has
been
issued
and
we
have
fair
amount
of
people
saying
they
support
the
document.
I
haven't
seen
anyone
saying
no,
even
I
can
sing
some
people
might
think
so,
but
they
haven't
expressed
so
so
I
don't
know
what
the
next
step
is
going
to
be
given
what
happened
yesterday
on
the
I
sides
working
group,
but
I
mean
we
have
bows
on
the
ice
eyes
and
always
be
a
very
amount
of
people
saying
they
do
support
this
job.
D
I
O
We
do
have
working
group
adoption
calls,
you
know
in
both
working
groups
and
they
publicly
expressed.
Opinions
have
been
overwhelmingly
in
favor,
but
what
seemed
to
happen
yesterday
in
the
assess
working
group
was
this
was
discounted
and
there
was
a
push
from
the
working
group
chairs
to
actually
have
an
interim
meeting
to
discuss
any
issues
associated
with
this
and
my
question
to
you.
K
K
Well,
because
there
are
people
on
me
deco,
so
but
I
also
want
to
look
at
you
right.
So
we
don't
do
voting.
You
know
this
and
we
could
say
yes,
there
was
overwhelming
consensus
and
I
freely
admit
and
happily
that
there
were
more
support
than
from
one
particular
affiliation,
but
there
was
definitely
a
piling
on
from
one
particular
affiliation,
which
makes
me
not
a
of
people
who
were
actively
involved
and
have
legitimate
and
good
technical
opinions.
K
The
working
group
chair
gets
to
decide
when
they
think
they
were
a
person
who's
doing.
The
consensus
call
does
get
to
decide
when
to
do
it.
Last
IETF
I
asked
for
a
virtual
interim
between
that
last
one
and
this
one
I've
asked
for
the
use
cases
to
be
better
written
down,
because
I
think
what
a
lot
of
the
working
group
and
folks
on
the
mailing
list
have
been
hearing
is
arguing
over
bits
instead
of
Hugh's
excuses,
obviously
I'm
happy
to
chat
with
you
as
well.
K
So
there's
two
pieces,
one
is:
can
any,
can
everyone
live
with
this
and
if
you
can't
live
with
it,
what
are
the
technical
problems?
What
are
the
issues
and
then
how
can
we
resolve
the
issues?
It's
fine
to
have
rough
consensus
with
the
rough
consensus
I
mean
you
know
this.
You
can
participate
in
the
IETF
for
an
eon.
K
Sorry,
but
the
key
point
here
is
you
don't
you
haven't
if
you
hear
two
significant
technical
objections
and
we
don't
have
some
concept
about
how
to
address
that,
and
it
might
be
that
the
working
group
has
consensus
of
yes,
we
heard
that
we
don't
care
so
I
am
NOT
concerned
now
will
I
be
concerned.
If
we
don't
have
a
decision
and
it
resolved
before
next
IETF
yeah
I'll
be
screaming
at
people.
I
don't
want
to
scream
so.
O
I'm
not
talking
a
numbers
game,
okay
and
we,
you
know,
we
all
build
on
rough
consensus,
we're
not
taking
a
majority,
we
don't
have
an
electoral
college,
etc,
etc.
I'm,
just
saying
if
you
look
at
the
history
of
the
working
groups,
if
you
have
any
draft-
and
it
has
numbers
such
as
we
see
in
public
today-
I
do
not
know
any
case
where
the
draft
was
not
adopted.
O
I
cannot
think
of
one
and
so
I'm,
asking
from
a
process
standpoint
and
I'm
particularly
concerned
because
of
the
direction
that
the
the
ice
is
working
group
chairs
took
okay,
the
the
largest
set
of
discussions.
I
mean
you
know
Chris
and
I.
Everybody
knows
kind
of
you
know
where
we
stand
and-
and
you
know
we
don't
agree-
that's
fair.
O
K
Oh
here,
I
hear
you
and
we're
going
to
handle
that
in
this
way,
but
it
has
to
be
discussed,
and
then
there
has
to
be
more
I
can
tell
you
about
how
what
we
had
to
do
with
enemy
o3.
Okay,
for
envy.
Oh
sorry-
and
you
know
there
was
great
consensus
to
adopt
absolutely
every
single
day
to
plan
under
the
universe.
K
I
sorry
I
shouldn't
say
that
there
were
only
three
okay
and
it
was
the
same
type
of
thing,
but
and
there
was
a
consensus
to
adopt
each
of
them,
but
nobody
could
live
with
particular
one
and
it
kept
being
so.
Yes,
these
issues
come
up.
Usually
they
haven't
come
up
and
I
as
I
asked
or
SPF,
because,
frankly,
we've
got
a
really
well
behaved
and
cooperative
working
group
and
I
certainly
prefer
that
style
to
having
to
go,
have
strong
discussions.
K
In
a
consensus
judgment,
it's
necessary
to
pay
attention
to
what
is
said,
and
so
are
there
significant
technical
jobs?
The
objections
have
we,
as
a
working
group,
talked
about
them
and
agree
on
how
to
handle
them,
and
then,
when
people
when
you're,
judging
consensus,
how
informed
do
the
plus
ones
look?
Are
they
plus
ones
or
are
they
actually
meaningful
input
beyond
yeah?
My
friend
asked
me
to
and
I
don't
think
that's
happening
here
by
the
way,
because
I
know
who's,
the
people
are
saying,
but
it's
not
enough
input
to
say.
K
Oh
this
person
really
cares
about
it,
because
it's
solving
this
problem.
Obviously
you
all
are
really
interesting
it
because
it's
solving
your
problems,
it
solving
customer
promise
for
you
and
I
understand
that
I
about
this
dragging
on.
But
if
you're
asking
from
a
process
standpoint
I,
don't
think
that
anything
wrong
has
happened
yet
and
I'm
definitely
keeping
a
close
eye
on
it.
One.
O
More
point
and
I'll
get
off.
This
I
was
in
the
opposite
position
fairly
recently
on
the
encapsulation
draft
and
I
sighs
I
did
not
and
still
do
not
think
that
it
was
worth
doing
and
I
voiced.
My
objection.
I
was
alone
in
that
objection,
and
the
working
group
chair
is
quite
rightly
followed
the
consensus
of
the
working
group.
The
draft
has
proceeded
I,
don't
see
the
difference
here.
J
J
These
would
be
these
could
be
ASPRS
or
ABR's
and
I
remember.
It
was
like
that
way
way
back
at
IBM
and
I
just
changed
it
for
someone.
Someone
said
that
and
I
just
changed
it
and
then,
when
I
went
to
read
back
I
just
ignored
it.
You
know
I
made
it
I
said,
of
course,
you'd
want
ecmp
between
multiple
ASPRS
everything.
If
all
the
other
rules-
and
you
know
you
aren't
gonna
loop-
if
all
the
other
rules
are
equal.
So
what
I'm
proposing
to
do
is
make
this
optional,
be
an
errata
and
I.
J
Don't
know
if
other
implementations
have
done
this
too
I
guess
I,
guess
some
among
our
implementations
at
Cisco.
Some
have
done
it
in
some
of
not
because
of
the
you
know
for
conformance
testing
right.
They
they've
stuck
directly
to
it
so
I
just
like
to
do
this,
be
a
rat
or
rather
than
trying
to
do
a
yeah
and
make
it
up
and
and
if
I
were
redoing
it
I
would
remove
it
completely,
but
since
I'm
doing
it
during
the
rat,
errata
I
I'll,
do
it
optionally
and
put
in
the
description
that
it
it's.
J
P
More
so
Chris
powers
so
from
or
you're
saying,
I
think
you're
saying
there's
no.
This
would
there's
no
possibility
of
this
causing
routing
loops.
It's
just
a
assured,
as
opposed
to
a
must
that
people
are
doing
as
shirt
or
not
doing
it
all.
Yes,
so
there's
no
chance
of
routing
loops
from
from
any
change
of
this.
No
okay,
I
just
want
to
yeah.
J
Computer
Matt,
you
look
if
you
look
at
this,
is
this:
is
rule
II,
there's
rules
a
through
D
that
have
all
the
different
things
about
inter
area
paths
and
things
like
you
know.
You
know
whether
you
have
a
path
over
the
but
you
for
a
it
is
for
both
AAS,
external
and
NSA.
Si
and
I.
Don't
see
why
you,
if
you,
if
all
those
other
rules,
are
satisfied
right,
this
would
ever
be
a
problem.
P
D
P
If
we're
gonna
fix
it,
let's
see
like,
are
we
actually
fixing
something
that
you
know?
Ninety
percent
are
actually
doing
what's
said
here
or
not.
I
I
have
at
this
point,
I
had
no
idea
what
what
existing
implementations
do,
and
you
mentioned
that,
like
two
implementations
at
your
employer,
are
actually.
J
P
N
J
Pull
that
myself
actually
actually
actually
I
have
a
big
problem.
That
I
say:
I'm
gonna
do
more
about
as
much
stuff
as
two
people
or
three
people
could
do
and
I
don't
end
up
doing
it
all
so
I
won't
say:
I'm
gonna,
pull
you
pull
the
to
github
and
look
at
it
anyway.
Okay,
so
we'll
continue
the
discussion
on
the
list.
Yeah.