►
Description
Broadcasted live on Twitch -- Watch live at https://www.twitch.tv/nrelabs
A
A
And
you
know
you've
been
at
this
for
a
while,
like
as
long
as
I've
known
you.
This
is.
This
has
been
like
your
thing.
You
know
wireless
way
better
than
pretty
much
anybody
that
I
know
I.
You
know
I
only
know
a
few
Wireless
folks,
cuz
I'm,
like
them
I'm
less
on
that
side
of
things.
But,
like
you
know
it's
there,
you
know
whenever
I
have
wireless
questions,
it's
always
like
you,
Jake
Schneider.
You
know,
I
went
to
a
few
events
with
him.
A
A
Nice
well
so
what
I
mean
this
is
a
question
born
primarily
out
of
ignorance
because
I,
you
know,
one
of
the
things
that
I
like
to
do
is
is
every
once
in
a
while
figure
out
like
what's
the
current,
every
every
every
discipline
is
going
through
some
sort
of
like
up
ending.
You
know
some
sort
of
transformation
that
everybody
likes
to
talk
about,
whether
it's
like
marketing,
fluff
or
not.
What's
the
current
like,
what's
the
current
talk
of
the
town
in
the
wireless
industry,
what's
the
current
thing
that
people
are
looking
at
is
like?
A
B
B
Unfortunately,
the
the
programmability
and
the
things
that
that
you
would
be
interested
in
are
still
very
much
in
the
background.
For
some
reason,
this
industries
is
really
hard
to
to
shift
into
that
mindset
of
programming
automation.
Things
like
that,
even
though
I've
been
saying
it
for
years
since
the
explosion
of
Sdn
and
programmability
wireless
networking,
the
engineers
that
do
it
should
have
adapted
very
easily.
Sdn
is
a
controller
based
system
that
you
know
centralizes
and
and
separates
the
control
and
data
planes,
and
that's
what
wireless
has
been
doing
for
20
years.
B
It
shouldn't
be
a
hard
concept
for
us
programmability.
We
have
radio
automation,
you
know
all
of
that
stuff.
It's
it's
been
a
hard,
a
hard
thing
to
crack
to
get
engineers
on
board,
even
though,
if
you
break
it
down,
that's
what
they're
already
doing
so,
yeah
myself
and
quite
a
few
others
have
been
trying
to
bring
back
to
the
forefront,
but
then
with
ax
coming
and
possibly
new
spectrum.
Coming
it
just
kind
of
gets
pushed
to
the
background,
sir.
A
Yeah
and
one
of
the
things
that
I
like
to
talk
about
when
we,
when
we
do
talk
about
automation,
is
break
things
down
in
terms
of
like
okay.
What
what
are
your
common
workflows?
What
are
the
things
you
spend
most
your
time
doing,
I
was
at
Interop
recently
and
I
raise
this
question
because
a
lot
of
times
when
we
talk
about
automation
in
the
you
know,
network
engineering,
community,
broadly
Network
automation.
A
We
like
to
talk
about
configuration
management,
I
think
primarily
because
it's
kind
of
easy
to
wrap
your
head
around
as
a
thing
you
can
automate,
but
in
my
experience
it
doesn't
represent,
it
doesn't
represent
even
even
a
large
fraction
of
the
time
that
an
engineer
will
will
actually
use
their
time
to
do
in
a
given
week.
Primarily
ITIL
I
think
is
to
blame
for
that,
where
we,
like
shove,
all
of
our
changes
into
the
weekend,
but
also
there's
just
a
lot
more
on
our
plate
than
just
making
changes.
A
I'm
curious
to
get
your
perspective
on
that,
like
what
are,
if
you
could,
like
you
know,
verbally
build
the
pie
chart
of
like
what
kind
of
things
that
a
typical
wireless
engineer
spends
their
time
doing
or
maybe
not
even
from
a
time
perspective,
maybe
just
from
a
thing
that
keeps
them
up
at
night
like
what
are
the
things
that
are,
that
the
most
pressing
workflows
that
it
that
maybe
could
be
conducive
to
automation.
So.
B
B
You
know
it's
not
we're
not
dealing
with
switches
where
we
know
a
cable
is
going
to
carry
the
signal
properly.
You
know
we
have
a
shared
environment.
That's
transient
in
many
cases,
especially
large
venues
where,
where
the
health
of
the
network
is,
is
paramount
and
monitoring
that
reacting
to
it,
making
sure
that
everything
is
where
you
need
it
to
be,
and
then
finding
optimizations.
That's
the
day-to-day
of
an
engineer,
a
lot
of
troubleshooting,
a
lot
of
packet,
analysis,
protocol
level,
stuff
and
then
the
medium
level
stuff.
So
we
go
even
further.
B
You
know
you
don't
see
a
data
center
engineer
out
there
tapping
into
the
wire
and
see
that
out.
You
know
the
electrons
are
flowing
properly,
so
that
adds
a
whole
separate
level
to
us
as
wireless
engineers,
that
that
makes
it
a
little
bit
more
difficult
when
you
have
shared
frequencies
with
all
these
other
protocols
and
some
proprietary
microwave
yeah
yeah,
it
makes
it
very
difficult.
B
So
those
are
the
things
that
that
a
lot
of
people
spend
most
of
their
time
on
Sean
so
and
in
a
majority
of
the
time,
it's
the
client
devices
that
are
our
issues
so
trying
to
figure
out
based
on
what
we
see
from
the
network.
What
the
client
is
doing
wrong
and
correlating
that
information
is,
is
the
biggest
the
hurdles
that
we
face,
and
that's
that's
personally,
where
I
would
say:
I
spend
about
forty
to
fifty
percent
of
my
day,
I'm
just
going
through
that
kind
of
sure,
yeah.
A
I
mean
how,
in
your
mind
like,
where
do
you
think
automation
can
help
with
that?
Is
it
sort
of
like
a
like
a
data,
retrieval
kind
of
thing
we're
like
if
you
could,
if
you
could
like
automate,
the
collection
of
you
know
context
like
one
of
the
biggest
time
sucks
during
a
troubleshooting
exercise,
especially
because
often
at
least
on
the
like
core
networking
side
of
things,
you're
usually
talking
about
some
sort
of
an
outage.
A
Maybe
on
the
wireless
side,
there
are
shades
of
grey
there,
where
you
could
have
like
some
just
bad
performance
or
an
outage
there
there's
some
there's
some
leeway
there
I
think,
but
generally
speaking,
like
one
of
the
things
that
I
that
I've
had
success
with
with
people
is
automating
data
retrieval
and-
and
you
know
putting
it
all
in
one
place
so
that
you
can
see
sort
of
what
the
current
state
of
things
is
before
you
have
to
like.
Go
in
and
get
your
you
know,
get
your
arms
dirty.
B
That's
that's
absolutely
part
of
it,
so
the
the
telemetry,
the
health
of
the
network,
is
keeping
that
information,
because
a
lot
of
times
a
user
will
come
to
me
and
say
yesterday,
I
was
having
an
issue
at
a
brown
four
o'clock.
There's
no
way
to
go
back
and
look
at
any
of
that
without
taking
that
telemetry,
a
lot
of
manufacturers
will
have
their
own
proprietary
systems,
but
they
won't
allow
you
to
get
as
deep
into
it
without
a
lot
of
custom
configuration
if
I'm
doing
a
lot
of
custom
configuration.
B
Why
not
go
plant
a
stack
or
something
like
that
to
to
ingest
that
data,
the
other
part
of
it
is
looking
for
anomalies.
The
human
eye
can
only
see
so
much
sure
we
can't
correlate
a
lot
of
information
accurately
so
so
seeing
those
outliers
and
kind
of
call
them
out.
You
end
up
with
a
lot
of
false
positives
until
you
tune
your
system
to
your
network,
but
getting
it
that
way
really
helps
because
you
can
almost
act
proactively
on
a
lot
of
these
issues,
because
you
see
kind
of
the
cascading
effect.
B
802
11
is
a
protocol
designed
to
work
until
it
can't
work
anymore.
So
we
will
degrade
and
degrade
and
degrade
until
it
just
shuts
off
yeah.
So
if
we
can
catch
it
before
it
starts
that
that
cascading
degradation
of
performance
and
react
to
it.
That's
that's
a
big
part
of
maintaining
a
healthy,
Network
yeah.
You.
A
B
I
am
I
am
by
no
means
an
expert
in
this
area.
The
I
am,
you
know
relatively
new
to
it.
Only
within
the
past
year
have
I
started
spending
on
my
own,
but
using
Telegraph
influx
DB,
Griffin,
ax
or
any
other
back-end
systems
that
are
out
there.
I
know
Prometheus
is
out
there.
I
have
not
touched
that
yet
yeah,
but
for
a
basic
view
of
my
network,
I'm
able
to
use
Telegraph
to
throw
it
all
in
and
I
can
grab
the
vendor
specific
SNMP
MIBs
I
can
use
api's
I
can
I
can
gather
that
information.
B
A
Take
Telegraph,
for
instance,
I
mean
it's.
It's
been
a
little
bit
since
I've
looked
at
it,
but
my
memory,
if
my
memory
serves
Telegraph,
actually
has
specific
OTT
you
mentioned
SNMP,
specifically
like
it,
has
actually
network
network
specific
telemetry
options
to
ingest
things
like
that.
Just
ready
to
go
like
you,
don't
have
to
reinvent
the
wheel
there.
It's
it's
the
it's
there
for
you
to
use
yeah.
B
And
unfortunately,
in
the
wireless
space
we
have
a
lot
of
custom
proprietary,
nibs,
so
plugging
those
in
to
Telegraph
is
quite
easy.
I
wouldn't
say
it's
a
day,
one
kind
of
thing,
but
I
bet
he
does
look
around
github
of
other
people's
configurations.
You
can
generally
find
what
you
need
to
customize
Telegraph
enough
to
gather
everything
you
need
and
throw
it
into
a
database
yeah.
A
And
Damion
Garros,
who
I
don't
think
we've
had
on
the
stream
yet,
but
we
need
to
very
soon.
I
also
talked
with
him
at
Interop
about
this,
and
he
he
actually
gave
a
talk.
It
was
a
really
good
talk,
I'd,
say
unfortunately,
interrupts
talks,
aren't
recorded,
I,
think
the
network
to
code
folks
might
have
recorded
it
and
they
may
publish
it
soon,
not
sure
about
that.
B
A
B
Yeah
and
and
like
you
said
time,
series
is
it's
just
so
incredibly
important
for
for
wireless
specifically,
because
correlating
everything
that's
happening
at
one
time,
whether
it's
channel
utilization
retries
on
the
the
transmit
or
receive
spectrum
health.
Putting
that
all
into
one
interface,
you
know
you
need
to
log
that
information
in
a
time
series
fashion
so
do.
A
You
have
to
deal
with
like
I
I.
Imagine
that
I
imagine
that
within
a
specific,
like
domain
say
like
a
campus
or
set
of
campuses.
It's
it's
pretty
easy
to.
You
know
have
all
of
that,
be
basically
under
one
sort
of
administrative
domain.
From
like
a
controller
perspective
or
or
maybe
one
of
the
cloud
hosted
options,
do
you
have?
Is
there
a
big
like
multi
vendor?
Is
there
a
big
push
to
Wireless
multi-vendor
deployments
like?
Is
that
a
thing
that
you
have
to
deal
with
a
lot
of
times?
No.
B
So
wireless
wireless
is
one
of
the
least
interoperable
systems
you
will
ever
find.
I
had
a
feeling,
yes,
we're
based
on
the
ADA
211
standard,
but
every
vendor
mixes
in
their
own.
You
cannot
traditionally
can
have
multiple
wireless
networks
working
together.
You
know
you're,
not
even
I
like
to
take
the
approach
of
best
tool
for
the
job.
So
from
my
point
to
point,
links
between
buildings,
I
may
choose
one
vendor
for
wireless
access
for
clients,
I'm
going
to
choose
another.
Those
systems
are
never
going
to
talk
to
each
other
yeah.
It's.
B
A
B
There
are
even
standards
in
802,
11,
portions
of
ADA
211
that
are
designed
for
interoperability
from
meshing
and
now
we're
starting
to
see
management
side
kind
of
vendor
agnostic
through
open
config.
The
wireless
network
industry
is
finally
starting
to
adopt
open
config,
so
there's
there's
a
three
liters.
B
Most
of
them
are
cloud-based
because
it's
just
easier
for
for
the
backend
to
be
built
that
way,
but
there
are
a
few
campus
solutions
that
that
do
have
open
config
built-in
and
the
thing
I
love
about
that
is
I
can
I
was
talking
to
someone
who
runs
a
very
large
network
that
that
has
a
config
and
I've
been
trying
to
push
it
in
my
organization,
yeah
he's
tier
1,
tier
2
teams,
doing
basic
troubleshooting
and
customer
support.
They
don't
care
what
the
end
access
point.
Is
they
don't
care?
What
operating
system
it's
running?
B
A
I
imagine
a
lot
of
those
models
had
to
be
written
from
scratch,
because
I
mean
you
know
there
where
it
comes
from,
like
administering
like
the
campus
switches
and
and
how
they're
configured
to
support
the
wireless
infrastructure.
I.
Imagine
a
lot
of
those
models
already
existed,
at
least
in
part,
but
the
wireless
specific
side
does
this
extend
to
the
actual
controllers
themselves
and
configuring
the
wireless
networks
themselves,
because
I
imagine.
B
Yeah,
so
a
lot
of
the
the
open
config
organization
group
has
has
created
a
lot
of
the
models
for
for
something
they
that
every
wireless
network
has
you
have
radio
zero?
You
have
radio
one.
What
channel
is
it
on?
What's
its
channel
width?
What's
this
transmit
power?
You
know
all
that
stuff,
so
they
built
these
these
models
and
now
they're
allowing
areas
prepared.
Everyone
has
their
own
radio
management
system,
it's
proprietary.
B
So
how
do
you
control
that
and
sets
thresholds
so
they're
they're,
opening
up
different
areas
and
that'll
be
the
vendors
choice
of
where
to
stick
it?
But
you
know
if,
if
you
can
build
90%
of
your
config
using
the
open
standards
and
then
just
fill
in
the
gaps
using
those
those
custom
areas,
it
helps
a
lot.
So
so
we
are
seeing
that
and
we
are
talking
directly
to
controllers
in
some
cases.
A
Want
to
pour
one
out
for
all
the
vendors
that
can
no
longer
provide
value
by
inserting
an
underscore
in
their
interface
names,
instead
of
just
leaving
it
as
a
standard
name.
You
know
it's
like
III
I'm,
an
innovative
I'm,
a
visionary
and
so
I'm
gonna
call
Radio
one
radio
underscore
one
yeah
cuz!
That's
what
I
do
yeah
it's
good.
B
A
A
That's
that's
good
to
see
yeah
I
didn't
know
about
that
and
I.
You
know
open
configs
been
around
for
a
little
bit.
It's
it's
not
surprising
to
me
that
it's
finding
adjacent
areas
to
get
into
cuz
it
does
you
know
it's
not!
It's
not
really
meant
to
solve
all
the
problems,
but
at
least
it
it
keeps
the
simple
stuff
from
being
brought
up
for
debate
time
and
time
again.
A
B
A
B
That's
that's
our
biggest
hurdle
right
now,
getting
people
comfortable
with
it
and
a
lot
of
the
times.
What
I
hear
is
I
want
to
learn,
but
I
have
no
idea
where
it
start,
and
that
is
a
big
problem,
because
every
vendor
makes
a
slightly
different.
You
can't
I
can't
take
a
tool
that
I've
built
for
my
network
and
just
publish
it
and
make
it
available
and
have
it
work
for
a
dozen
other
people
that
want
to
use
it.
There's
a
lot
of
customization
that
you
throw
in
to
any
solution
for
wireless
and
in.
A
A
One
of
the
first
network
was
one
of
the
first
rest.
Api,
as
I
ever
saw,
was
on
the
on
the
cisco
nexus
9000
line.
When
ACI
came
out,
they
had
they
had
one
I
think
a
OS,
EAP
I
happened,
probably
a
few
years
before
that
I
just
I
didn't
know
about
it.
I
hadn't
touched
a
wrist
at
that
point
and
then,
of
course,
net
confident
had
existed
well
before
that.
My
I
guess
the
first
question
I
have
on
that
is,
it
is,
are
we
in
the
wireless
world
is
it?
A
B
A
B
Specifically,
what
we
see
is
we
have
a
lot
that
have
no
ik.
We
have
some
that
have
very
very
limited
api's
that
are
mostly
configuration
and
deployment,
so
they're
designed
for
your
VARs
and
your
MSPs
for
large-scale
deployment
right
and
then
we
have
the
API
first
companies,
which
are
very
few
and
far
between
where
you
know
they
have
their
cloud
dashboard,
but
that
are
developing.
The
API
and
you'll
have
features
in
the
API
before
you
have
them
in
the
dashboard,
because
that's
not
what
they're
necessarily
worried
about
sure.
B
Then,
on
the
campus
side,
you
know
the
enterprise
stuff
that
sits
on
pram.
We
have
a
wide
range
of
ways
to
configure.
Some
of
them
are
proprietary
protocols
and
systems
especially
found
the
telemetry
side
and
then
a
REST
API.
You
know
they
come
out
with
some
fantastic
REST
API
and
you
end
up
finding
out
it's
just
the
commander
ever
sure
yeah.
It.
B
A
Actually
that
leads
me
into
a
kind
of
a
attend,
a
slight
tangent,
but
but
related.
How
is
how
was
how
has
Linux
affected
the
wireless
industry?
Is
there?
Are
there
alternatives
to
maybe
like
common
enterprise,
wireless
controllers
that
you
can
run
in
open
source
just
on
Linux
or
any
number
of
things
like
that?
Or
is
it?
Is
it
even
not
to
that
point?
If.
B
B
You
know
any
of
the
the
Chinese
wholesale
sites.
You
can
buy
access
points
that
run
busybox
or
all
any
number
of
Linux
flavors,
and
that's
what
you
see
in
a
lot
of
the
SNB
kind
of
small
enterprise
space.
So
if
you
wanted
to
it
the
capabilities
there,
I
don't
know
anyone
that
has
gone
down
that
route
yeah.
A
B
A
B
Actually
is
a
company
that
that
kind
of
touches
on
that
SMB
to
small
enterprise,
that
they
had
a
fantastic
management
platform
and
they
made
they
made
ok
access
points.
Most
of
them
were
off
the
shelf,
like
I
said,
and
they
kind
of
stopped
selling
access
points.
Now
it's
bring
your
own
Wow,
so
that
kind
of
does
go
into
what
you
said.
But
it's
not
a
it's,
not
an.
B
A
B
I
mean
we
only
have
a
head
full
of
chipset
manufacturers,
a
handful
of
chipsets
at
any,
given
time
that
are
coming
out
to
support
a
different
standard,
so
so
yeah.
Well,
if
someone
makes
a
decent
white
label
access
point
and
I,
imagine
it's
the
same
in
the
switching
world
and
you
have
the
desire
to
run
your
own
OS
and
customize.
It
yourself
or
even
have
some
other
third
party.
That
does
management
on
that
platform.
Yeah
and
the
hardware
does
what
you
need
it
to
it's,
a
perfectly
fine
solution.
As
long
as
you
can
ease
yeah.
A
I
mean
that
is
a
thing
I
think
in
the
switching
world,
I,
don't
I,
think
I
think
the
conversation
there's
a
little
backwards,
because
most
people
in
the
networking
world
approach
that
with
a
well.
What
well
you
know
why
do
I
need
to
run
Linux
on
my
switch
and
I?
Think
the
the
the
the
big
use
case
that
I've
found
success
with,
and
this
is
kind
of
sad
but
one
of
the
one
of
the
things
that
I
that
I've
noticed
when
people
do
sort
of
glom
onto
that
idea.
A
It's
because
they
they
can't
get
compute
capacity
to
run
their
tools,
and
so
they
want
an
open
switch
where
they
can
install
their
own
software
on
top
of
and
run
their
tools
there,
and
you
know
I,
guess
whatever
works
for
you,
like
that's
fine
yeah.
Do
you
want
my
credit
card?
Man
like
here?
Have
some
80s
stuff
ya.
B
Know
we
I've
kind
of
joked,
half
half
jokes
about
it,
but
I
think
edge
computing,
especially
in
the
networking
world.
A
lot
of
the
a
lot
of
the
systems
were
rolling
up
data
and
correlating
information.
I
would
love
to
see
that
move
down
to
the
access
policies.
Our
access
points
are
getting
so
incredibly
powerful,
they're
still
just
in
the
same
old
thing:
yeah
yeah,
you
know
we
we
have.
We
have
multiprocessor
multi-core
systems
with
you
know
multiple
gigs
of
ram.
A
A
They
just
aren't
virtual.
Like
that
blows
my
mind,
that's
so
cool
and
you
know
I
think
you're
totally
right,
I
think
we're
just
scratching
the
surface
I'm
like
what
we
can
do
from
that
I
think
we
as
engineers,
natch
and
I.
Don't
think
this
is
unnatural.
I
think
we
naturally
sort
of
my
were
attracted
to
the
the
the
the
the
doing
the
you
know
doing
the
thing
like
the
the
actual
like
making
a
change,
I'm
gonna
engineer,
so
I'm
gonna
build
this
and
it's
gonna
be.
A
A
B
Phenomenal
and
that's
where
a
lot
of
the
proprietary
solutions
mean
you
mentioned
the
the
virtual
bluetooth
that
is,
that
is
done
not
so
much
at
the
software
layer.
Yes,
there's
a
lot
of
software
powering
that,
but
the
way
that
that
was
kind
of
revolutionized,
that
area
is
more
in
the
antennas.
If
the
physics
of
the
RF
layer
being
able
to
direct
the
information
and
using
different
techniques
for
for
location
services,
you
know
everyone
knows
triangulation,
but
networking
wireless
networks
don't
actually
use
triangulation.
B
We
use
something
called
trilateration
and
now
we're
using
something
called
angle
of
arrival
time
difference
in
arrival.
So
with
all
these
antenna,
arrays
there's
some
crazy
stuff
going
on
and
the
amount
of
information
it
produces
allows
us
to
to
do
some
really
interesting
things
and
sometimes
scary
things,
sure
yeah.
B
A
This
is
the
thing
like
we.
We
always
run
into
the
run
into
the
question
of
like
well
infrastructure,
especially
network
engineers,
because
we
are
so
low
on
the
totem
pole.
You
know
OSI
stack
wise,
we
you
know
we,
you
know
we're
always
thought
of
as
infrastructure
whenever
we're
always
a
cost
center.
B
A
One
else
has
the
data
that
we
have,
so
we
can
either
choose
to
figure
out
how
to
present
it
or
not,
and
that's
fine.
If
we
don't,
because
you
know
we
still
are
needed,
we're
still
infrastructure,
but
I.
Think
the
point
that
you
and
I
are
both
trying
to
make
is
that
we
could
be
so
much
more.
If
we
just
you
know,
access
not
a
little
bit.
I
have.
B
Worked
on
many
projects
in
my
previous
life
as
far
where
the
the
IT
department
wasn't
involved
in
the
decision-making
process,
it
was
the
marketing
team
or,
if
you
know
the
legal
team
bringing
in
and
saying
what
can
this
technology
do
for
us
and
then
it
being
pushed
down
on
the
IT
department
yeah,
so
so
yeah
they
I.
There
is
a
lot
that
can
be
done
and
I
think
it
all
starts
with
with
basic
telemetry,
and
that's
that's
where
that's
where
wireless
engineers
need
to
get
to
and
not
everyone
needs
to
get
there.
Yeah.
A
A
B
A
I
apologized
for
that
I
I
had
the
name
of
my
tongue.
I
can't
remember
they
talked
about
anyway.
They
talked
about
dude.
Do
you
need
to
be
a
programmer
and
the
overall
man,
consensus
and
I
agree
with
this
is?
Is
no
you
need
to
learn
enough
based
on
the
use
case
like
if
you
are
building
tools
like
either
just
for
yourself
or
your
team,
then
yeah
you
shouldn't.
A
You
should
know
enough
to
be
able
to
do
that,
but
in
terms
of
like
building
and
maintaining
software
like
systems
for
like
organization
wide
use
like
no,
you
need
a
software
developer
to
do
that
whose
job
it
is
who
specializes
in
building
software,
because
we
all
have
specialties
right
and
and
I
think
anybody
that
suggests
that
you
need
to
maintain
two
specialties.
It
has
probably
neither
of
those
specialties,
so
I
think
the
point
here
is
is
like
look.
There
are
people
that
exist
whose
job
it
is
like
like,
for
instance,
eat.
A
You
just
take
one
of
these
wireless
companies.
There
are
people
there
are
these
companies
who
hire
teams
of
PhDs
to
build
the
software
and
the
hardware
to
make
all
of
this
possible
you're,
never
gonna,
reinvent
that
wheel,
and
nor
should
you
even
try.
So
let
that
let
that
exist
where
I
think
where
we
can
spend
our
time
and
energy
more
wisely,
is
figuring
out
how
to
stitch
those
things
together,
sort
of
like
intra-domain
automation,
meaning
I
automate.
A
The
way
that
this
particular
system
works
like
that's,
not
really
what
we
need
to
be
doing,
let
the
let
the
let
the
entity
that
specializes
in
that
or
the
person
that
specializes
in
that
might
be
just
a
single
tool.
Do
that
and
then
we
can
as
network
engineers,
we
focus
a
lot
more
on
the
inter
domain.
We
stitch
things
together.
We
do
things
like
a
event
triggering
so
like
when
this
event
happens.
I
know
that
this
other
action
needs
to
take
place.
A
B
A
B
A
So
one
one
one
closing
question:
yeah:
look:
what
what
can
we
do
better
I
think
in
terms
of
helping
helping
the
wireless
industry
get
started
with
automation?
What
kind
of
what
kind
of
topics
do
you
think
would
be
would
be
most
useful
as
a
starting
point
that
we
can
capitalize
on
and
help
folks
get
started
with
I
think.
B
A
lot
of
a
lot
of
wireless
engineers
are
struggling
with
operational
information
CSV.
You
know,
Excel
documents,
manipulating
files,
gathering
information
from
different
systems,
just
how
to
take
that
information
store
it
and
present
it
in
a
usable
way,
and
a
lot
of
that
translates
from
from
the
network
side
to
the
wireless
just
fine,
it's
just.
How
do
we
you
mentioned
Telegraph
has
a
lot
built
in
for
network
engineers.
How
do
we
extend
that
and
teach
the
wireless
engineers
to
build
upon
that
system
to
get
the
information
they
need?
B
So
I
think
that's
where
a
lot
of
it
lies.
Like
I
said
everyone
starts
with
I,
don't
know
what
to
do.
First,
I,
don't
know
where
to
get
started
and
and
presenting
you
know,
even
if
it's
just
a
basic
networking
task
presenting
it
in
the
context
of
a
wireless
network
is,
is
a
pretty
meaningful
way
to
get.
Someone
started
yeah.
A
B
A
B
I
mentioned
earlier,
50%
of
my
day
is
troubleshooting.
The
other
50%
is
taking
data
from
all
these
different
systems.
Outputting,
it's
a
word
copy
and
pasting
out
of
it.
You
know
automating
those
flows,
because
wireless
systems
aren't
made
for
for
developers
it's
made
for
guys
who
just
want
to
document
spit
out
sure.
A
B
A
A
B
A
A
Thanks
Ryan
and
for
those
on
the
stream
I
want
to
mention
one
announcement.
We
are
more
than
actually
more
than
more
than
likely
we're
definitely
going
to
move
to
a
model
where
we
stream
every
other
week.
We've
been
streaming
weekly
thus
far
and
right
now
the
schedules
are
are
ok,
but
in
the
past
it's
been
kind
of
difficult
to
do
it
every
week.
So
we're
gonna
move
to
a
semi,
weekly
cadence,
so
every
other
week
we'll
be
announcing
all
of
us
on
Twitter.
So
in
case
you're
in
case
you
missed
this.