►
From YouTube: IETF108-LSVR-20200730-1300
Description
LSVR meeting session at IETF108
2020/07/30 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
Another
you
know
another
one
to
actually
directly
speak.
So
if
you
know
you
could
be
so
kind
to
just,
you
know
hit
the
one
with
the
raising
hand,
so
you
get
actually
added
into
the
queue
the
other
one
will
send
audio
directly,
which
will
you
know
goof
up
the
audio
stream
a
little
bit.
A
Of
those
things,
okay,
I'm
gonna,
you
can
disconnect
the
hook.
Yeah,
voila,
okay,
so
welcome
everybody.
So
we
have
50
minutes
time
to
go
over
the
link
state
vector.
You
know
working
group
here,
let's
try.
So
we
have
a
busy
agenda
and
I'm
going
to
be
trying
to
keep
ourselves.
You
know
to
the
plant
agenda.
What
we
have
here.
Let
me
see
if
we
can
found
the
slides.
A
A
A
A
So
first
we're
gonna
be
looking
to
your
agenda,
see
if
everything
is
okay
for
everybody
as
such.
Next
we're
gonna
see
a
quick
update
on
the
two.
You
know
key
working
group
drafts
here
on
the
applicability
and
on
the
bgp
spf
itself,
and
then
we
will
get
an
update
also
on
the
implementation
of
our
lsvr.
You
know
technology
here
which
will
be
presented.
You
know
by
kore
and
that
will
be
followed
by
updates
on
you
know
the
set
of
drafts
regarding
the
l3dl
technology
itself,
so
we
actually
have
some
good.
A
You
know
announcements
and
advancements
there
also
and
randy
will
be
giving
a
short
update
on
those
as
such.
Also
now
before
we
jump
into
the
different
updates
of
the
different
working
group
documents
and
other
documents,
let's
have
a
look
into
where
we
are
so
we
haven't
really
met
for
quite
a
long
time.
Now
that
doesn't
mean
nothing.
Actually,
you
know
has
progressed
that
nothing
actually,
you
know,
has
not
been
progressing
within
the
working
group
itself.
A
So
we
closed,
we
did
like
two
working
group
loss
calls
on
two
documents.
We
closed
them
and
those
documents
were
pushed
towards
the
iesg
for
further.
You
know
handling
as
such.
I
spoke
before
this
call
with
the
area
director
and
they
are
actually
on
his
plate
to
process
as
quickly
as
time
allows
because
he's
relatively
busy
with
a
few
other.
You
know
documents
also.
A
A
good
set
of
feedback
came
from
the
working
group
last
call
and
it
is
being
reworked
by
randy
and
the
team,
and
I
suspect,
he's
gonna
give
an
update
on
where
we
are
right
now.
You
know
later
on.
You
know
in
the
work
group
session
here.
In
addition,
we
did
do
a
working
group.
A
Adoption
call
on
two
other
documents
with
respect
to
the
signing
of
the
ldl3dl
technology
and
about
the
upper
layer
protocol
configuration
and
if
you
develop
like
any
type
of
new
technology,
then
security
is
a
you
know,
a
very
integral
component
out
of
it.
You
cannot
really
develop
like
a
new
protocol
or
technology
without
thinking
about
those.
So
this
will
be
very
crucial.
You
know
to
progress
the
l3dl
you
know
base
pack
itself
also
because
I
considered
them
as
one
you
know.
A
A
A
The
young
document
itself
is
still
mission
in
action,
but
from
what
I
saw
in
the
idr
working
group
is
that
the
bgp
yang
is
now
going
through
the
last
steps
of
the
process,
and
I
suspect,
because
bgp
spf
is
very
closely
related
to
that
that
the
young
model,
for
you
know
bgp
spf,
is
going
to
be
progressing.
You
know
kind
of
along
line
with
that,
but
I'm
pretty
sure
that
qr
will
give
a
little
bit
more
updates
on
that.
A
From
that
perspective,
now
looking
into
the
fact
that
we
have
some
key
milestones
nearly
delivered,
we
need
to
look
into
what
we're
going
to
be
doing
with
our
working
group
in
the
future
and
some
of
the
new
things
you
know
we
may
be
looking
into
because
some
of
the
liftreal
documents,
for
example,
are
you
know
on
the
edge
of
what
we
are
chartered
for?
A
So
you
know
it
does
take
you
know
so
at
the
ietf
109
between
now
and
then
we
will
start
some
discussions
on
the
working
group
email
list
on
how
to
do
the
resharper
and
what
we
should
be.
You
know
refocusing
upon
so
that
from
the
lsvr
working
group,
status,
update
and
any
questions
or
any
further
comments,
because
if
not,
then
I
plan
to
progress
with
the
first
presentation.
A
C
E
Voila,
it's
working.
I
just
wanted
to
have
a
quick
comment
on
the
yang
model
draft
that
has
been
worked
upon.
E
Basically,
the
base
bgp
ls
draft
for
the
yang
model
has
been
missing,
so
we
are
trying
to
come
up
with
a
common
model
draft
that
can
be
applicable
to
bgpls
as
well
as
yang
as
well
as
lsvr,
and
I
think
the
first
version
of
the
draft
should
be
up
and
running
fairly
and
we
submitted
to
itf
fairly
soon.
E
Sure
so
I'm
gonna
give
a
quick
update
on
applicability
and
the
pgp
spf
drop.
This
is
this:
is
the
update
on
the
applicability
draft
next
slide?
Please.
E
So
version
five
was
submitted
on
the
24th
march.
We
have
an
update
to
the
version
five,
which
is
going
to
be
version
six
soon.
The
draft
was
submitted
to
iesg.
That
was
the
version
5
of
the
draft.
We
received
a
few
comments
from
boris
incorporated
all
the
comments
in
version
6
and
boris
has
been
pretty
active
on
the
email
thread,
giving
us
the
feedback.
Our
next
slide.
Please.
E
Following
are
the
updates
which
are
going
to
be
posted
in
version
6,
we've
added
more
text
to
site
examples
in
section
611
of
the
draft
section,
6
2
is
again
augmented
to
give
an
example
that
talks
about
constraint,
peering
model
between
spine
and
leaves
there
is
added
text
now
to
what
it
means
to
have
a
prefix
aggregation
and
augmented
section
653
to
cover
all
sorts
of
devices.
E
In
addition
to
the
controller
text
that
we
had
had
in
the
version
five
of
the
draft.
So
those
were
the
changes,
we're
going
to
submit
version
6
soon
and
hopefully
we
can
wrap
it
around
some
any.
B
E
Super
so
now
I'm
going
to
give
an
update,
quick
update
on
lsvr
bgp
spf
extensions,
the
base
drop
that
we've
been
talking
about
next
slide.
Please.
E
Right
so
version
nine
again,
the
last
call
has
been
successfully
done
version
nine
was
submitted
in
may,
which
was
pretty
recent.
We
now
have
multiple
implementations
since
the
last
ietf.
E
We
now
have
an
added
implementation
from
fr,
which
is
an
open
source
implementation.
The
early
review
of
routing
directorate
was
done.
All
the
comments
were
addressed
way
earlier.
However,
the
status
for
for
the
routing
directorate
comments
being
addressed
needs
to
be
updated.
I
am
assuming
someone
will
help
me
out
with
that.
Knowing
all
the
comments
were
taken
care
of.
A
Yes,
so
from
from
the
document
shepard
perspective,
so
I
put
this
particular
fact
actually
in
the
shepherd
document,
also
so
it's
in
there.
So
it's
taken
care
of.
E
Super
thank
you,
and
I
think
I
only
have
one
slide
on
this
yep
and
we've
gotten
a
lot
of
feedback
from
chaitanya
from
atm,
and
as
a
result
of
that,
we
have
added
him.
As
a
contributor.
Like
I
said
earlier,
the
yang
model
work
is
in
progress.
It's
going
to
be
a
common
draft
for
bgpls
and
bgp
spf,
knowing
that
the
prefix
encoding
and
the
attribute
encodings
are
exactly
the
same.
The
bgps
teardrop
has
added,
which
would
be
presented
in
the
same
draft.
E
I
am
now
going
to
talk
about
the
implementation
draft,
for
we
have,
like,
I
said
two
implementations
available
next
slide.
Please
we
have
an
implementation
in
arc
os
fully
available
as
an
underlay
it.
It
now
works
as
an
underlay
for
all
the
ols
office,
namely
interestingly
one
evpn,
and
we
have
a
implementation
for
fr.
Frs
routing
stack,
you
can
see
the
authors
who
implemented
all
the
implementers
who
have
implemented
this
implementations,
our
respective
implementations
in
in
in
different
osas
next
slide,
please.
E
So
this
slide
talks
about
what
kind
of
peering
models
are
supported
within
the
two
implementations.
There
is
enough
flexibility
in
terms
of
supporting
peering
models.
Both
ebgp
and
ibgp.
Hearing
sessions
have
been
supported
and
been
cross,
verified
interoperability
looks
just
fine.
E
The
peering
models
are
were
tested
as
a
single
hop
bearing
as
well
as
directly
connected
on
the
connected
nodes,
also
keeping
route
reflectors
in
mind,
pretty
straightforward,
no
changes
here.
The
way
it
was
tested
was
the
new
software
should
come
up
pretty
easily
and
start
exchanging
the
bgp
messages
as
it
comes
up
all
tested
and
verified
next
slide.
Please.
E
Then
we
started
on
testing.
What
does
the
messaging
actually
looks
like
on
a
send
received
site?
Can
you
send
a
write,
update,
pass
the
update
on
the
receive
site?
E
Can
you
create
an
update
and
verify
the
update
that
you're
about
to
send
holds
up
the
interoperability
on
both
update
generation
side,
as
well
as
update,
processing
or
receiving
of
the
updates
on
the
new
safety
over
and
about
other
bgp
messages,
including
the
heartbeat
messages
and
notification
messages
were
tested
fully
interoperable
even
for
the
notifications
that
we
ended
up,
creating
by
inducing
errors
were
tested
and
made
sure
that
they
were
interoperable
as
well.
E
So
from
the
messaging
perspective
and
update
generation
perspective,
an
updated
receiving
perspective,
everything
had
been
tested
and
full
and
and
full
interoperability
is
ensured
between
two
implementations
next
slide,
please
that
by
the
way,
generation
and
processing
of
the
updates
also
covered
the
attribute
processing
of
the
updates
as
well.
And
finally,
the
modifications
that
were
tested
were
comparing
the
route
selection
process,
which
is
very
local
to
the
implementation.
E
E
The
fr
implementation
implements
a
route
reflector
functionality
and,
as
a
result
of
that,
as
it
was
a
out-of-band
route
reflector,
the
spf
calculation
was
kept
in
there
and
it
was
simply
announcing
routes
that
it
was
receiving
in
some
sense,
reflecting
in
this
case
what
it
was
receiving
and
arcos
was
running
on
switches
and
routers,
and
it
was
simply
executing
spf
and
was
tested
to
make
sure
that
the
interoperability
is
in
place.
So
in
in
this
particular
section,
fr
skipped
any
update
in
any
spf
calculations.
E
F
F
F
Basically,
what
it
asks
for
is
saying.
Yes,
we
have
an
rqs
implementation
version
whatever
and
maybe
with
a
link
or
a
pointer
to
the
implementation
report,
which
is
why,
assuming
the
same
content
as
what
you
just
presented
right.
D
A
A
F
Right
so
there's
a
two
part
right,
the
one
which
is
what
I
think
I'm
asking
for
which
I
want
as
much
visibility
to
the
fact
that
there
are
implementations.
So
it's
great
that
the
shepard
report
says
that
again,
just
a
couple
paragraphs
in
in
the
main
drafts
would
be
great
as
well,
so
that
no
one
actually
misses
that.
You
know
no
one
from
the
asu
looking
at
the
implementations
or
anything
and
then
the
other
thing
which
I'm
not
sure.
F
A
A
A
F
So
basically,
what
that
rc
talks
about
is
an
implementation
status
section
which
doesn't
have
all
the
details
of.
I
tested
this
packet
and
I
tested
another
packet
and
things
like
that.
But
it
is
basically
a
paragraph
that
says
yes:
arcus
has
an
implementation,
it's
in
this
version
of
the
code
and
here's
a
contact
person,
so
just
to
raise
more
visibility
to
the
fact
that
there
are
implementations.
F
So
it's
not
you
know
an
in-depth
implementation
report
or
or
interoperability
or
anything
like
that.
It's
just
a
generation
of
visibility
so
that
people
know
that
there
are
implementations
out
there.
F
Take
a
look
at
it's
just,
I
said
you
know
a
couple
of
paragraphs,
nothing
too
in-depth,
but
it
provides
you
know.
Other
people
are
going
to
be
reviewing
this
because,
as
you
said,
this
is
a
new
thing.
Yeah,
there's
ability
to
the
fact
that
there
are
implementations
out
there
and
that
we're
not
just
you
know,
pushing
papers
around.
E
E
There's
one
if,
if
isis
is
still
going
to,
is
ac
still
wanting
to
make
a
command.
E
One
quick
comment
I
have
for
chairs,
as
well
as
the
participants
is
as
part
of
doing
an
interop.
We
have
also
done
some
performance
and
convergence
tests
and
we
have
interesting
results
across
different
protocols.
We
didn't
bring
it
forward,
knowing
a
that.
It
would
be
a
little
bit
of
an
implementation,
specific
details
and
we
didn't
know
how
best
to
compare
and
contrast
against
different
protocols,
but
we
have
some
interesting
analysis
and-
and
if
folks
are
interested,
we
could
we
could
always
chat
offline
about
that
as
well.
E
But
since
there
is
no
standard
way
of
comparing
even
between
different
protocols
that
implements
dijkstra
it's
sort
of
hard
to
compare
and
contrast,
even
within
a
same
flavor
of
implementation.
As
to
how
the
protocol
stand,
you
know,
stands
and
compares
against
different
other
protocols.
So
I
wanted
to
just
bring
that
out
there
we
will
of
obviously
not
be
covering
in
the
implementation
draft,
but
we
have
also
done
that
additional
level
of
analysis.
C
A
G
All
right,
this
is
jacob
from
oracle
cloud
infrastructure
cure.
I
wonder
if
I
can
get
in
touch
with
you
offline
about
some
some
testing
on
the
implementation
that
you've
got
running.
G
All
right
I'll
reach
out
to
you
offline,
then
sure
thank
you.
B
It
is
I
just
I
just
manually
forced
myself
in
this
time.
Can
you
hear
me
now?
Yes,
okay,
what
I
was
saying,
I
think
we
were
talking
at
the
same
time.
I
said
I
said
I've
done
something
like
this
for
the
ospf
b3
extended
lsas,
I
put
a
little
implementation
section.
We
also
had
a
separate
draft
now.
I
know
the
alvaro
and
others
have
pushed
back
on.
The
implementation
reports
is
published
drafts,
but
I
think,
since
this
is
like
you
said,
is
this
a
new
technology?
B
I
think,
and
if
we're
willing
to
do
the
work
as
a
working
group,
I
think
we
should
publish
that
as
informational
as
well.
We
can
take
this
up
offline
with
the
with
alvaro
and
after
outside
the
meeting,
but
I
would
I
would
be
interested
I'd
also
be
interested
in
the
performance
data
that
care
alluded
to.
H
Can
you
can
you
hear
me?
Yes,
yeah
hi,
this
is
anurag
from
siena.
I
was
looking
at
at
the
draft
and
there
was
there
were
a
couple
of
sec
sections
in
there
about
dampening
of
spf
calculation
based
on
existing
rfp
is
that
is
that
is
that
to
allow,
for,
you
can
say
better
scalability.
E
From
an
implementation,
standpoint
and
ac
can
add
more
to
that,
but
from
implementation
standpoint
we
wanted
to
paste
spf
calculations
just
in
case
if
we
were
receiving
a
lot
of
updates
coming
in
and
how
do
you
sort
off
just
dampen
it
enough
to
to
to
get
enough
churn
in
before
we
start
calculating
spf,
and
the
text
was
in
context
of
that.
H
E
H
Just
in
continuation
of
the
draft,
the
there
are
three
phases
of
decision
process
as
part
of
the
spf
and
installation
which
is
being
described.
I
was
just
curious
now
because
this
is
my
first
time
looking
at
at
this.
H
This
is
like
we
are
going
towards
a
stateful
implementation,
we'll
have
to
keep
database
for
for
the
link
states,
and
everything
is
that
true.
As
for
the
implementation
of
this
draft
going
forward,
because
for
dike
for
running
the
extra.
E
E
Different
implementations
are
allowed
to
do
it
in
a
different
way.
They
have
a
flexibility
to
do
it,
but
essentially
the
three
default
phases
that
were
there
inside
bgp
were
pretty
much
replaced
with
spf
computation
and
installing
routes
in
the
raid.
Now,
how
you
go
about
doing
that,
pretty
much
is
going
to
be
very
implementation
specific,
but
it's
going
to
be
somewhat
stateful
for
sure
stateful.
H
Thank
you
care,
and
just
one
last
one
in
in
this
context.
Now
we
are
looking
at
the
local
rip
or
we
are
looking
at
starting
to
splitting
the
phases
in
adjacency
in
and
and
local
reverses,
adjacency
out.
E
F
E
A
separate
edge,
rib
in
and
maybe
edge
rib
out
with
the
local
rib
or
you
can
squeeze
that
down.
If
you
are
looking
to
save
some
memory
and
keep
a
state
common,
a
very
implementation,
specific
detail,
but
but
the
draft
allows,
more
importantly,
a
flexibility
to
implementers
to
implement
in
whatever
way
they
would
like.
Yeah.
E
The
draft
will
probably
not
make
any
recommendation
and
be
in
line
to
what
the
base
rfc
is
in
sense
that
the
bayes
rfc
gives
you
the
base.
Bgp
rfc
4271
tells
you
about
this
three
different
databases,
but
actually
doesn't
make
any
implementation
or
recommendation
and,
as
you
probably
very
well
know,
different
vendors
have
implemented
it
in
a
manner
that
has
all
different.
All
three
different
databases
kept
separate,
or
some
of
them
have
clubbed
into
a
single
database.
E
B
B
Now
you
can
go
any
anywhere
to
something
pretty
conservative
and
in
the
routing
working
group
we
actually
have
a
draft
that
recommends
a
backup,
a
back
off
algorithm,
it's
rfc
8405
for
the
minutes
now,
so
you
can
go
anything
to
something
very
conservative
where
you
only
you
know,
do
an
spf
every
few
seconds
to
completely
disabling
it
and
doing
your
spf.
Whenever
you
have
one
pending
and
in
your
internal
scheduling,
you
don't
have
any
higher
higher
priority
work
to
do
so.
B
You
you're,
eventually,
you
know
if
you
got
a
especially
with
something
you
know
modern
processors,
and
you
know
if
you,
if
you
know
how
to
do
it
right,
you
can
do
this
spfs
for
a
pretty
big
domain,
especially
something
simple.
Like
we've
done
with
bgp
spf,
where
you
don't
have
any,
you
only
have
point-to-point
links,
you
can
do
it
in.
You
know
single-digit
milliseconds,
for
a
pretty
big
underlay.
E
I
will
yes,
I
will
end
the
presentation
by
saying
that
we
have
a
separate
implementation
draft
submitted.
We
will
work
with
chairs
to
see.
Do
we
want
to
keep
that
graph
around,
or
do
we
want
to
convert
that
into
79
42
text,
which
is
a
wiki
test,
a
text
I
don't
know,
but
we
will
work
with
the
chairs
and
and
get
and
and
and
get
the
necessary
feedback
so
that
we
can.
We
can
do
one
way
or
another
yeah.
A
Much
okay,
then
it's
the.
D
Let's
remember
the
primary
goal
here
is
discovery
of
layer,
3,
ip
topology
and
liveness
to
support
lsvr's
spf
next,
just
a
silly
picture,
you've
seen
too
many
times.
Let's
remember
the
dark:
rectangle
is
layer,
two
okay
and
we're
trading
ether
pdus
between
devices
and
pushing
northbound
to
egp
spf,
so
it
can
take
the
interlink
state
and
turn
it
into
a
more
global
topology.
Next,
please,
this
is
not
a
routing
protocol.
D
So
on
the
north
side
of
this
slide,
we
see
a
a
transmission
protocol,
okay,
that
assembles
ethernet
frames
into
pdus
and
then
at
the
bottom
we
have
pdus
by
pdu
type,
payload
length,
etc,
etc,
and
we're
going
to
the
meat
of
the
protocols
and
the
pdus.
But
there
is
this
transport
thing,
so
you
can
use
ethernet
frames
and
using
transport
at
layer.
2
get
large
pdus
because
of
this
new
transport.
D
Next
slide,
please,
we
begged
the
transport
directorate
to
do
an
early
review
and
your
god
did
a
great
review
in
fact
multiple
times,
and
it
was
really
quite
good
and
so
that
took
version
four
of
the
draft
to
version
five
next
slide.
Please,
of
course
you've
read
the
draft,
but
if
you
had,
why
did
you
not
report
the
bugs
that
rob
reported
to
me
yesterday?
D
D
We
have
two
implementations,
one
in
python
3,
which
is
not
an
implementation
of
lsdl.
It's
of
its
predecessor
lsoe.
It
is
open
source
in
python,
3.,
there's
an
l3dl
implementation
in
golang
within
arccus.
It
is
not
open
source
and
that's
the
end
of
the
l3dl
prezo.
If
anybody
has
questions,
please
feel
free
to
interrupt
me
at
any
time.
D
Next
slide,
please,
as
gunter
said,
you're
not
going
to
get
this
thing
past
the
ietf
without
security.
So
we
have
some
simple
security
on
available
on
this
of
two
flavors
next
slide.
Please
in
the
open
pdu
we
added
auth
type,
what
kind
of
security
it
is
and
the
length
of
the
key
and
then
because
it's
a
pdu,
we
sign
it
with
the
signature
type,
the
signature
length
and
the
signature,
it's
really
stupid
stuff,
but
provides
a
fair
bit
next
key.
Please
next
slide,
please
sorry!
D
D
D
D
What
you
can
do
instead
is
have
a
pki,
okay,
a
key
infrastructure,
so
that
the
sender
generates
the
public-private
key
care
pair,
but
then
goes
to
some
public
server
that
private
key
server.
That,
for
instance,
is
in
the
data
center
and
handles
all
keying
registrations
and
it
enrolls
the
public
key.
D
D
D
D
D
That's
your
choice.
You
could
probably
even
subdivide
it
by
pods
or
something
but
now
you're
getting
kinky,
okay
and
it's
going
to
be
operationally
annoying
next
slide.
Please,
since
nobody
reads
anything
before
wg
last
call,
I
think
we
requested
it,
but
it's
not
actually
in
last
call-
or
at
least
data
tracker
doesn't
know
about
it.
C
Yeah
yeah,
we
look
here.
Okay,
when
you
guys
are
ready.
D
I
Time
for
me
to
talk,
I
guess
so.
This
is
john's
cutter,
hi
randy,
so
I
confess
this
is
my
first
exposure
to
this
particular
draft.
I
did
just
give
it
one
thing
that
I
bump
into
every
time
anything
involving
keying
and
security
comes
up.
Is
somebody
in
the
security
directorate
asks?
What's
your
mandatory
to
implement
algorithm?
D
D
By
being
able
to
discover
the
pbgp
attributes
of
a
neighbor
next
slide,
please
so
we
now
have
a
this
draft
describes
a
pdu
which
again
is
exchanged
at
layer
2
as
part
of
l3dl,
which
says:
hey,
there's
an
upper
layer
protocol,
typically,
a
routing
protocol
like
bgp,
which
has
the
following
attributes
and
there's
an
arbitrary
number
of
attributes
with
an
attribute
list.
The
ulpc
type
says
hey:
this
is
bgp,
for
instance,
and
that's
what
we
really
care
about
next
slide.
Please.
D
The
point
is
to
provide
the
absolute
minimal
set
of
configuration
parameters
for
the
open
to
succeed
next
slide,
please
because
we
don't
want
to
replace
or
conflict
with
the
rather
extensive
data
exchanged
during
open.
If
you
have
next
slide
two
sources
of
truth,
it's
a
recipe
for
complexity
and
pain.
So
therefore
we
exchange
the
minimal
next
slide.
The
minimal
data
to
just
get
the
open
going.
So
all
the
rest
of
the
gorp
can
be
exchanged.
D
What
do
you
need
to
get
bgp
going
next
slide?
Please
three
things
your
neighbors,
you
have
to
exchange
your
asn's,
you
need
what
address
you're
going
to
have
for
peering
and
the
bgp
authentication
data,
for
instance
the
md5
hash.
If
you're
going
to
use
it,
I
had
to
describe
on
list
that
the
bgp
peering
address
may
or
may
not
be
the
direct
address
on
the
link
it
can
be
loopbacks
and
how
you
detect
that
or
signal
it
was
a
matter
of
some
discussion
and
possibly
it
should
be
incorporated.
D
D
A
A
C
There's
a
jacobs
in
the.
G
D
Gladly
work
with
somebody
updating
it,
the
senior
software
engineer
who
wrote
it
it's
a
little
over
occupied
at
the
moment
within
arcus,
so
I
understand
he's
here.
He
can
speak
for
himself,
but
he's
choosing
not
to
so.
I
think
we
can
take
that
as
a
signal.
G
Okay
and
and
point
of
clarification
you
mentioned
with
a
trust
model
that
if
we
use
a
pki
based
approach,
the
ca
that
is
used
can
be
public
or
private.
So
long
as
the
device
actually
trusts
the
ca
itself
correct
right.
It's
going
to
be
doing
this
yeah.
It
doesn't
need
to
be
public.
D
D
If
you
have
burned
the
ta's
public
certificate
in
the
receiving
device,
because
the
receiving
device
then
has
the
ta
certificate
and
can
just
use
it
to
verify
the
encapsulated
private
public
key
of
the
sender,
so
you
don't
even
have
to
be
able
to
reach
the
pki.
If
you've
got
the
pkis
public
certificate
burned
in
the
receiving
device,
if
you
don't,
then
the
receiving
device
is
going
to
have
to
go,
find
the
pki,
ca
and
say:
hey.