►
From YouTube: IETF111-OPSAWG-20210730-2300
Description
OPSAWG meeting session at IETF111
2021/07/30 2300
https://datatracker.ietf.org/meeting/111/proceedings/
B
C
A
C
A
Okay,
well
we'll
see
if
this
so
now.
A
We
should
oh
we're
one
minute
over.
So
let's,
let's
how's
that
look.
A
All
right
see
how
this
works
great.
Well,
if
you
don't
mind
I'll
I'll,
kick
us
off.
Welcome
to
what
is
probably
your
last
ietf
111
meeting
good
morning
good
evening
good
afternoon,
maybe
to
each
and
every
one
of
you
and
thanks
to
anyone
in
the
europe
or
further
eastern
time
zones
who
are
here
at
weird
hours.
A
This
is
a
ietf
proceeding
and
as
such,
it
is
subject
to
the
notewell,
which
I'm
sure
many
of
you
have
read
or
have
heard
if
you've
attended
other
meetings
this
week.
But
you
can
see
it
up
here
in
that
what
you
say
your
contributions
here,
you
are
under
and
subject
to
the
ietf
process
and
policies
and,
as
was
noted
on
the
first
slide,
this
session
is
also
being
recorded.
A
So
I
am
joe
clark
one
of
your
three
co-chairs-
I'm
joined
as
always
by
tian,
ren
and
hank
on
the
call
again
at
various
times
we
have
a
jabber
room.
In
fact,
many
of
you
or
some
of
you
are
participating
in
it
right
now
here
in
meet
echo
or
whatever
client
you're
using
while
we're
I
have
it,
I
can
actually
see
it.
A
So
one
of
the
chairs
can
act
as
the
scribe
and
as
for
minutes,
we're
using
cody
md
for
the
minutes,
and
I
pre-pinged
rob
wilton
and
elliott
lear
if
they've
been
so
gracious
to
do
this
in
the
past.
For
us
to
take
minutes
to
be
our
scribe
and
they
both
said
they
would
continue
to
do
so.
I
hope
that's
still
the
case.
A
I
know
elliot
you're
going
to
be
speaking
and
rob
said
he
would
jump
in
and
then
I
can
help
out
on
the
ops
area,
and
I
already
see
in
my
other
screen,
someone
is
typing
in
code
emd,
so
rob
and
elliot.
Are
you
still
okay
to
do
the
to
do
the.
A
A
Excellent,
thank
you
very
much,
so
the
slides
will
be
shared
here
and
they
are
available
at
that
url
and
hopefully
everyone
jumped
off
into
the
meat
echo
room,
because
that's
why
you're
here
listening
to
me
now
I'll,
do
some
of
this
and
then
hand
it
off
to
my
co-chairs
to
jump
in
if
any
other
context
they
want
to
add.
You
may
have
recently
seen
that
rfc
9092
was
published
on
finding
and
using
geofeed
data.
A
A
A
However,
even
though
they're
in
a
working
group
or
sorry,
a
ietf
last
call
status,
we're
holding
them
pending
work
on
the
l2
network,
module
which
is
going
to
be
presented
here,
so
we're
we're,
hoping
that
that
work
goes
through
and
most
recently,
I
think
tom
petch
submitted
a
a
good
review
on
l3
nm
to
the
list
I'll
breeze
over
the
next
ones,
and
maybe
tan
ren
and
hank.
You
can
add
more
context.
We
did,
I
will
say,
on
the
mpls
sr
label
type.
A
That
was
one
where
we
said.
We
wanted
to
move
that
ahead
more
quickly
and-
and
so
we
we
did
there.
So
if
anyone
hank
tin
wren,
if
you
want
to
jump
in
actually
I
see
rob
just
joined
the
queue.
Maybe
you
want
to
speak
up
as
well
rob
on
something
I
said
about
the
l
star,
nm
modules.
F
Actually,
it
was
just
on
the
ntf
module,
the
upside
of
your
ntf
apologies.
It's
taking
a
long
time
to
get
through
you.
I
have
started
the
review
there.
I've
not
completed
it.
I
won't
go
to
directly
after
this
meeting
because
I've
been
holiday
for
a
couple
of
weeks,
but
then
it
is
top
of
my
cue
to
then
process.
So
apologies
for
the
delay.
G
A
Okay,
we're
going
to
hear
from
benoit
on
the
two
service
assurance
drafts
today.
As
I
mentioned,
we'll
hear
from
the
l2
and
m
and
the
vpn
service
module
is
also
a
performance
module,
I
should
say,
is
also
on
tap
and
we
have,
I
think,
all
of
these
mud
and
s-bomb
drafts
as
well.
We'll
hear
from
today
was
someone
else
entering
the
queue
rob.
F
Actually,
I
just
wanted
to
update
on
three
name
and
the
vpn
common
modules.
Those
actually
have
gone
to
itf
last
call,
I
think
I
discussed
the
with
the
authors
and
then
presumably
we
will
hold
you
going
to
the
ice
gene
for
the
old
to
enemy.
Is
that
what
you
said
before
yeah.
A
A
So
we
did
see
a
liaison
statement
come
through
on
quantum
key
distribution.
It
read
mostly
as
an
inform.
I
won't
read
the
slide
here,
but
you
can
see
that
there
have
been
some
recommendations
on
it
published
and
there's
going
to
be
continuing
work.
So
out
of
their
session
there's
going
to
there
was
some
additional
documents
adopted
some
in
progress
work.
A
Some
proposed
work
that
they're
going
to
continue
to
work
on,
and
so
you
can
see
that
they're
continuing
to
evaluate
the
quantum
key
distribution
methodologies
here
and
I
see
elliott
joining
the
queue
elliott.
E
Hi
everybody
thanks
joe
apologies
for
not
turning
the
camera
on
it's
just
one
in
the
morning
here
and
you
won't
like
what
you
look
at.
The
question
I
have
was
was
did
sg13
specifically
ship
this
to
the
ops
area
working
group,
because
I'm
not
sure
what
we
have
to
do
with
this.
A
Yeah,
I
I
thought
the
same
thing
and
yes,
they
did.
I
I
was
thinking
more
and
in
fact,
the
tank
tianan
and
I
discussed
maybe
opsec
ops
area
as
a
broader
potential
area,
but
but,
as
far
as
I
could
tell,
it
was
specifically
sent
to
ops,
awg
and
now
we've
got
two
in
the
queue
scott
hi,
it's
scott.
Can
you
hear
me
all
right?
We
can't.
A
We
can
hear
you
clearly:
okay,
well
I'll,
get
a
little
closer
yeah
study
group
13
sent
this
directly
to
ops
area.
I
am
working
with
warren
and
anyone
else
that
cares
to
craft
a
response
back
to
the
study
group
13.
It
also.
A
We
also
need
to
add,
in
some
words
from
the
irtf
as
well,
so,
if
anyone's
interested
in
looking
at
that
response,
just
contact
me
as
the
liaison
guy,
that's
between
the
ietf
and
the
itut.
E
I'm
gathering
that
this
is
because
of
the
control
and
management
aspects,
but
in
case
scott
in
case
you
didn't
quite
catch
this.
There
was
a
discussion.
I
think
roman
kicked
it
off
in
the
security
area
about
what
to
do
about
quantum
crypto
from
a
an
overall
security
standpoint.
So
there's
definitely
a
process.
That's
kicking
off
in
the
security
area
about
this,
and
if
it's
not
already
in
your
response,
you
might
want
to
talk
to
roman
about
this,
because
it
is
something
that
I
think
he
views
is
quite.
A
Important,
thank
you.
Chandran
did
you
want
to
say
something.
G
Yes,
I
see
this
is
if
this
is
a
new
work
and
if
there's
no
home
for
for
this
work,
I
think
your
absolute
rg
also
could
be
a
good
home
for
this,
and
we
can,
in
cuba
incubates
this
incubates.
This
work
in
icf.
A
If
we
yeah,
if
we
can
find
a
number
of
interested
people
in
the
cops
area
working
group
yeah,
I
it
sounds
like
there
might
be
some
good
point.
A
I
think
let
me
see
yep,
so
that
is
the
that
is
the
the
administrivia
overview.
This
is
our
agenda.
I
know
we're
kind
of
running
long
on
the
administrivia.
So
is
there
any
agenda
bashing?
Hopefully,
you've
all
seen
the
the
agenda
when,
when
tianaran
sent
it
out
a
little
while
ago,
we've
got
benoit,
kicking
things
off
with
sane
and
then
we're
going
into
the
l2
and
m
bose.
A
A
All
right,
benoit:
are
you
ready
to
kick
us
off.
A
Right,
let
me
bring
up
your
slides
yang
model
nope,
it's
not
you!
That's
not!
You
service
assurance
for
intent,
based
network.
How
about
that.
I
I
So
let
me
present
this
so,
as
you
mentioned
joe,
those
two
became
working
documents,
so
the
version
zero
zero
was
untouched
compared
to
the
private,
the
the
non-working
version,
and
so
I'm
going
to
stress
the
differences
between
0,
0
and
0
1,
so
3
4,
slides
of
background
and
then
the
diffs.
So
if
you
want
to
do
the
next
slide,
these
are
slides
that
you've
seen,
but
since
they
are
becoming
work
of
documents,
let
me
just
set
the
background
again.
I
So
what
we're
trying
to
solve
is
that
whenever
a
service
degrades,
you
want
to
understand
quickly
what
the
fault
is
and
what
the
symptoms
are
in
order
to
find
the
root
cause
right
and
we
don't
speak
about
admin
down
because
that's
a
very
easy
one,
but
the
more
complex
one.
And
then
we
want
to
understand
that
whenever
one
component
degrades
or
fails
what
service
are
impacted.
I
So
for
this
we
want
to
decompose
the
priming
two
smaller
components
that
we
call
subservices
and
we
want
to
have
an
assurance
graph
and
if
you
go
to
the
next
slide,
this
is
a
picture.
We've
been
sharing
in
the
past,
where
you
see
typically
a
tunnel
or
whatever
type
of
service,
and
we're
going
to
infer
the
health
of
that
service
based
on
the
components
that
are
depending
on
it.
So
typically
for
this
tunnel.
Well,
we
need
to
have
connectivity.
We
need
to
have
the
correct
interface.
I
The
interface
would
be
healthy,
the
igp
must
be
healthy,
etc,
etc.
So
we're
going
to
generate
an
actions
graph
with
dependencies
and
we're
going
to
infer
so
from
the
bottom
to
the
top,
the
health
of
the
service
so
think
about
it
like
combine
with
the
end-to-end
probing.
That
would
give
us
the
real
close
to
the
end
user
experience
and
will
tell
us
whether
there's
a
problem.
I
Now,
if
you,
if
you
combine
this
with
end-to-end,
which
is
considered
not
as
a
black
box
and
whenever
you
have
this
assurance
graph,
you
can
try
to
deduce
where
the
problem
might
be.
So
this
is
the
goal
and
on
the
next
slide,
what
we're
summarizing
in
this
in
these
two
documents,
first
of
all,
the
architecture.
I
If
we
identify
the
specific
subservice
is
impacting
the
total
services
all
right.
So
the
two
arrows
there
are
the
yang
modules
that
we
want
to
standardize
and
we
don't
plan
to
standardize
the
building
blocks
which
are
an
orchestrator
or
decent
orchestrator
or
the
agent
or
the
collector.
I
I
If
you
have
read
the
draft,
you
will
see
that
you
could
augment
the
yang
modules
for
specific
services
and
even
vendor-specific
subservice,
and
on
top
of
that,
you're
about
to
connect
graph
from
different
domains,
whether
it's
wire
line
or
5g
or
vim,
by
just
linking
those
those
graphs.
You
can
extend
this
just
beyond
networking.
I
All
right,
so,
let's
go
in
the
next
slide
and
let's
review
the
changes
that
were
introduced
in
this
version
zero
one.
So
we
receive
quite
some
quite
good
feedback
from
matt
to
review
all
the
editorial
aspect,
the
consistency,
the
the
terminology
and
all
these
literal
improvements
were
incorporated,
but
also
the
connection
with
the
existing
itf
work.
I
You
know
the
the
four
rfc,
I'm
rfc,
sorry,
I'm
showing
on
the
on
the
the
screen
there
with
the
sdn
service
function,
chaining
service
model
explain
in
a
framework
for
automating
service
and
network
management
with
yang.
I
So
as
mentioned
also,
we
we
stress
early
in
the
document
that
yes,
this
is
an
architecture,
but
the
real
meat
is
in
a
young
module,
which
is
a
companion
document.
I
I
I
I
E
E
I
want
to
say
you
look
a
lot
better
than
I
do
at
this
hour.
So
congratulations
on
that.
The
question
I
have
for
you
goes
back
to
whether
you're
showing
a
tree
or
a
dag,
and
my
only
question
is:
is
it
possible
that
there
are
in
fact,
in
some
cases,
should
you
allow
for
the
model
to
actually
identify
circular
dependencies.
E
I
mean
you,
you
would
hope
right,
but
I'll
give
you.
I
could
imagine,
for
instance,
that
maybe
in
in
in
some
circumstances,
particularly
in
complex
environments
involving,
say,
dns
or
something
like
that,
the
the
tool
could
actually
be
used,
in
fact
to
spot
those
and
and
what
might
need
to
be
done
to
avoid
them.
E
So
all
I'm
saying
is
from
a
conceptual
view,
right
yeah,
it's
it
ideally
you'd
like
a
dag,
but
what
what
you
might
think
about
is
that
this
might
actually
the
model
actually
might
be
useful
to
say:
hey,
wait
a
minute,
you
know!
Look
there,
you,
you
have
a
circular
dependency.
I
I
What
we,
what
we
have
there
is
actually
some
sub
services
with
some
parameters
right,
you
see
a
tunnel
interface
or
physical
interface,
so
it's
the
subservice
interface
type,
but
with
different
parameter
values.
So
you
know,
in
that
case
we
have
the
same
subservice
type
but
different
parameters.
So
this
is
not
really
a
cyclic,
but
a
point
taken
that
if
we
have
a
way
to
see
circular
dependencies,
that
would
be
good.
Now
I've
been
scratching
my
head
on
an
example
but
yeah.
E
If
you
go
a
little
bit
higher
up
in
the
stack,
so
your
model
is
currently
mostly
driven
to
you
know,
sort
of
a
l1,
l2
l,
you
know
and
then
a
little
bit
of
l3,
maybe,
but
if
you,
if
the
model
incorporates
anything
above
that,
like
a
you,
know,
application
services,
database,
services,
container
functions
or
anything
else
like
that,
I
could
very
easily
see
the
spaghetti,
showing
a
circular
dependency
from
time
to
time,
particularly
if
you're,
if
say
you
know,
network
infrastructure
service
uses
a
database
service
that
in
turn
starts
calling
dns
functions
for
whatever
reason
as
an
example
right.
E
I
Okay,
point
taken,
but
actually
going
into
the
application
layer
is
something
which
is
welcome
right
because
services
services
service
right.
What
is
your
service?
It's
the
application.
This
is
like
a
flow.
This
is
networking,
so
I
really
want
to
extend
this
this
graph
in
multiple
directions
so
point
taken:
let's
brainstorm
together,
if
there
is
a
way
to
detect
circular
dependencies
and
if
this
framework
could
be
useful
to
do
so
make
sense.
I
A
You
might
still
have
some
audio
issues
if
you
want
to
put
them
in
the
chat
we
can.
We
can
read
them
out
in
the
meantime
benoit,
where
it's
slide,
where
I
think
you're
on
10.
I
That's
right,
yes,
so
what
I
want
to
show
here
is
basically
two
different
services.
One
thing:
the
device,
one
one
interface,
the
device
being
the
red
one
at
the
bottom,
with
one
parameter.
If
you
want
to
get
the
health
of
the
device,
there
is
one
parameter,
and
this
is
a
device
id
now.
If
you
want
to
create
yet
another
one,
the
interface
at
the
top.
I
I
I
Right,
so,
if
we
take
back
this
example
from
the
architecture,
we
actually
shown
a
draft
all
the
young
modules,
all
the
sub
service
type
that
are
needed.
You
know
coming
from
interface
device
and
ipconnectivity
and
instances,
so
you
could
see
the
full
set
of
yang
module
and
if
you
go
on
the
next
slide,
what
we've
been
doing
for
that
is
that
we
added
a
full
example
of
the
yang
instance
for
that
that
complete
example,
which
is
and
then
validated
by
json
by
yang
sorry
and
similarly,
because
we're
adding
new
yang
modules.
I
And
on
the
next
slide
right,
since
actually
we
created
one
young
module,
which
is
the
main
one
and,
as
you
have
seen,
we
create
multiple
subservice
types,
so
multiple
yang
module
and
we
we
provided
guidelines
on
those
extensions.
What
should
you
choose
as
much
you'll
name,
what
your
namespace
module,
prefix,
specific
identities
and
parameters?
I
It's
a
little
bit
of
text
on
that
from
that
front
and
on
the
next
slide
right
is
my
last
slide.
The
open
issue
that
we
have
is
one,
which
is
that
we
want
to
reuse
the
terminology
coming
from
nmrg,
where
there
are
two
documents.
One
is
about
the
ibm
concept,
definition
ibm
in
intent,
classification.
It
would
be
great
to
be
aligned
and
then
now
it's
time
for
for
feedback
for
question
and
accuracy.
I
see
that
you
still
have
audio
issues.
I
Okay,
let
me
read
the
question:
tunnels
can
recurse
over
tunnels
protocols
over
protocols
so
that
that
may
contain
loops.
That
has
to
be
verified.
Semantically.
So
iliot's
point
is
reasonable.
Now
a
tunnel
over
a
tunnel.
Well,
that's
what
I
was
trying
to
say
that
maybe
the
parameters
are
different
right.
So
if
you
got
the
same
source
and
and
destination
then
maybe
there
are
different
instances.
I
F
I
F
Should
I
go
go
for
a
run,
just
a
quick
question
ben
while
I'm
sorry
I
haven't
read
the
latest
version
of
this.
I
have
read
previous
versions
with
the
parameters
and
the
ability
to
augment
the
model
and
extend
that.
Would
you
imagine
extending
specific
parameters
for
specific
subservices
or
are
the
parameters
kept
very
generic.
F
So
I
was,
I
was
trying
to
work
out
with
this
model,
whether
it
just
abstractly
a
habit
check,
defines
parameters
like
a
string
and
a
value
or
whether
you
expect
specific
parameters
for
particular
specific
sub
services
defined
in
the
yang
model,
which
would
then
require
custom
code
for
handling.
I
didn't
know
which
direction
you
go
in
those.
I
I
So
ideally
we
want
to
get
something
that
exists
already
in
a
in
a
young
module
if
we
want
to
have
a
device
id
same
thing.
If
you
want
to
have
like
I
don't
know,
one
parameter
is:
let
me
make
up
something
like
ospf
area
id
right,
so
we
want
to
reuse
something
that
exists
as
opposed
to
just
have
our
own
string,
our
own
tlv,
right
that
we
have
to
decode,
specifically
within
that
frame.
This
framework.
A
And
well,
I've
got
a
question
so
so
your
open
issues,
feedback
and
questions
you,
you
you're,
I
think
you
presented
at
the
mr
nmrg,
and
so
your
intent
so
to
speak,
is
to
fold
in
some
of
the
alignment
work
from
there
into
your
draft
and
what
there
didn't
seem
to
be
other
issues
other
than
maybe
elliot's
point
about
the
dag
versus
the
the
the
tree
and
and
the
cichlid
graph
so
is.
Is
that
is.
Are
you
looking
just
now
for
additional
feedback?
Are
you
gonna?
Look
at
that
work
with
elliott?
I
So
good
feed,
better
feedback
or
more
sorry,
more
feedback
would
be
welcome.
I
would
like
to
discuss
with
with
elliot
and
kiriti
as
you've
seen
from
the
young
sun
validation,
we're
we're
going
to
do
we're
trying
to
do
a
prototype,
so
we're
also
running
from
that.
I
So
we
want
to
say
it's
complete,
but
it's
time
to
get
more
views
and
maybe
code
behind
it.
A
Thanks,
as
has
been
pointed
out,
we
are
running
a
little
bit
behind,
so
I
don't
think
there's
anyone
else
in
queue.
So
if
there
are
other
questions
or
ten
ren
did
something
you
want
to
say.
J
A
I'll
I'll
do
a
review
of
this
speaking
as
a
contributor
and
thank
you
and
we'll
move
on.
Thank.
I
A
A
H
Yeah
perfect,
because
my
internet
connection-
here
I
am
at
the
moment
now-
is
not
so
not
so
great
okay,
so
now,
let's
go
with
the
elton
module
which
is
like
the
complements
the
trilogy,
so
we
already
have
the
the
vpn
and
the
l3
and
m203
services.
So
here
this
is
the
for
the
layer,
two
vpn
services,
so
here
just
to
a
couple
of
useful
pointers.
So
here
you
have
the
repository
where
we
host
the
issues
of
all
the
all
the
the
network
models.
H
H
So
we
receive
a
lot
of
feedback
in
this
for
completing
this,
this
version
of
the
of
the
model.
So
it's
all
documented,
so
we
tried
to
cover
all
the
outstanding
issues,
so
it
was
a
mainly
most
of
them
were
related
to
vpn.
I
mean
it
was
the
the
type
of
vpn
the
layer
to
vpn
that
took
us
more
more
time.
H
H
So
the
idea
that
we
have
is
to
have
young
modules
with
identities,
matching
those
er
dosayana
and
the
sayana
values,
and
that
as
new
types
come
on,
where
there
are
the
transformation
time,
so
where
types
they
come
on
and
they
are
included
in
the
rest
of
ayana
that
the
new
identities
are
created.
So
this
way
extending
the
or
the
future
maintenance
of
this
model
is
easier
because
we
decouple
it,
so
we
don't
need
to
to
create
those
identities
inside
the
l2
module.
H
Also,
we
had
some
some
last
comments
that
we
fixed
in
the
in
the
last
weeks.
We
have
the
the
vpn
common
review
that
had
some
impact
here
in
the
in
deltonium,
so
we
are
updated
at
two
and
there
was
one
also.
There
was
one
last
comment
by
by
moti
that
we
have
been
discussing
in
the
last
weeks
about
the
where
to
position
the
internet
segments
we'll
talk
about
that
later.
So
please
go
to
the
next
slide,
so
we
can
go
through
the
summary
of
the
of
the
main
changes.
H
So
as
mentioned,
the
vpn
support
is
the
the
main,
the
main
addition
to
the
to
the
draft.
So
now
we
support
the
main
rfcs
of
evpn
soviet
pmp-ls
evpns
with
pvp
a
bit
of
a
wire
service
and
the
applicability
of
vpn
pls.
So
that
does
not
mean
that
in
the
evpn
is
getting
a
lot
of
new
additions.
So,
as
we'll
see
later,
we
will
be
ready
in
the
or
the
model
is
ready
to
incorporate
in
the
future
new
new
procedures
that
should
be
applied
or
configured
to
the
to
the
vpn
service.
H
But
now
we
focus
on
those
that
are
more
stable
and
mature.
Also,
we
added
the
capability
of
the
rt,
auto
derivation,
so
here
in
the
in
the
evpn
case,
you
can
not
only
directly
assign
an
active
value,
but
there
are
also
possibilities
that
the
the
active
values
are
auto
derivative,
either
by
the
controller
or
by
the
even
then,
the
network
device
itself.
So
we
have
that
that
possibility.
So
you
can,
you
can
leave
the
auto
derivation.
H
Also,
we
added
the
the
support
for
the
different
translate
operation
for
the
different
push
pop
center
of
the
of
the
label,
and
this
translation
is
also
included
as
part
of
the
encapsulation.
Okay.
So
go
to
the
next
slide.
Please,
and
then,
as
I
mentioned
earlier,
one
of
the
latest
comments
and
was
where
to
position
the
internet,
so
was
the
ethernet
segment.
They
are
the
links
that
connect
the
a
customer
side
to
one
or
more
in
providers,
so
this
entity
itself
it
initially
what
we
had.
It
is
under
the
vpn
network
access.
H
So
we
have
said:
okay,
this
vpn
network
access
points
to
this
ethernet
assignment
and
in
other
vpn
networks.
If
you
point
to
the
same
one,
so
it
means
the
other
multi-home
and
we
were
happy
with
that,
but
people
were
insisting
and
that
invest
people
had
it
as
a
separate
entity
and
that
the
internet
assignments
were
worth
having
its
own
space.
So
now
we
are
moved
at
it
at
the
top
level,
so
we
have
the
ethernet
segments
there,
so
they
can
be
reduced
and
they
can
be
assigned
by
different
services.
H
So
also,
as
mentioned
earlier,
we
are
supporting
different
different
flavors
of
evpn,
so
we
have
created
a
identities
for
these
evpns
and
regarding
the
question
of
killity
that
I
see
it
in
the
chat
about
are
these
yes
and
that
that
option
was
already
available
in
the
vpn
common
draft?
Okay,
so
here
the
part
was
specifically
about
the,
I
think
is
artists,
and
I
think
they
are.
H
H
So
here
it
was
all
the
restructuring
to
to
make
it
more
more
clear,
so
separate.
For
example,
just
the
the
encapsulation
was
was
clarified
because
it
was,
it
was
mixing
a
little
bit
of
things.
Now
we
have
the
just
a
pointer
to
the
to
the
mirror,
so
the
biller
comes
from
the
concepts
of
the
l2
assembly,
where
the
the
physical
connection
from
the
customer.
Here
we
just
had
a
pointer
here
and
then
you
get
all
the
details
go
to
the
draft,
but
it's
a
redone
of
this
container.
So
next
slide.
Please.
H
Also,
we
we
added
a
a
set
of
global
parameters
profiles,
so
they
are
reducible
in
the
same
service
instance.
Okay,
so
we
define
it
at
the
service
level
and
then
you
can
reduce
them
in
in
different
in
different
nodes
and
in
different
vpn
networks.
So
so
here
in
cases
with
a
large
configurations
where
you
need
to
repeat
many
things,
we
think
it's
very,
very
useful.
This
global
profile
so
next
slide.
H
So
we
added
also
some
some
examples
in
the
in
the
draft,
so
so
the
readers
and
the
implementors
can
see
how
the
the
graph
is
used.
Okay,
so
also
please
feedback
on
the
examples
is
welcome
and
if
you
want
more
examples
and
more
type
of
example,
we
will
be
happy
to
add
more
of
those
go
to
the
next
slide.
H
So
we
have
solved
the
depending
issues
in
the
in
in
the
github
and
now
we
have
received
a
recently
a
review
from
from
joe
thank
you
very
much
joe
for
that,
so
we'll
work
on
that
as
soon
as
possible.
Just
please
allow
us
some
time
because
we
are
in
the
holiday
season.
We
have
most
of
the
kia
offers
out
so
we'll
take
a
little
a
little
bit
or
so
to
solve
that.
But
we
think
with
that.
H
Once
all
we
are
ready
to
go
for
the
working
group
last
last
call
and
just
to
know
that
the
the
model
is
prepared
to
support
new
functionalities
if
they
evolve
in
the
in
the
idf.
So
there
are
some
some
drugs,
for
example,
for
the
multi-homing
and
that
these
functionalities
can
be
incorporated
in
the
services
they
can.
So
with
this
I
finish
and
open
for.
A
Questions
doesn't
look
like
anyone
in
the
queue
yeah
the
the
holidays.
I
I
fully
expected,
I
think
I
said
we
said
to
med,
that
we'll
do
an
extended
last
call
on
your
models
prepare
to
support
new
functionalities.
Are
you
expecting
that
work
to
fold
into
the
the
model
the
module
before
it
is
fully
ratified?
Are
you
expecting
it
to
be
extensible
after
the
fact
for
these
new
services
or
new
functionalities.
H
I
think
the
second
one
I
don't
whenever,
when
we
close
the
model,
we'll
close
with
much
your
procedures.
Okay,
so
if
there
are
any
procedures
that
they're
still
in
debate-
or
there
are
some
things
that
I
think
it's
better
to
add
them
at
a
later
stage
and
have
the
model
ready,
I
mean
to
to
capture
these
new
procedures
as
they
come.
H
A
Hello
you're
a
little
soft.
If
you
could
speak
up
or
get
closer
to
the
mic,
that
would
be
helpful.
Okay,.
K
And
this
is
paul
hello.
Everyone
I'm
here
to
represent
all
the
the
authors
to
present
this
network
and
vpn
service
performance
morning.
Monitoring
model.
K
Here
I
I
will
give
a
brief
background
on
this
draft.
This
draft
was
adopted
in
last
ietf
meeting
and
this
model.
This
draft
is
trying
to
complement
the
layer,
2
and
then
or
layer
3
in
them.
Like
just
oscar
presented,
you
can
see,
as
you
can
see,
that
in
the
figure
network
service
model,
mostly
for
the
service
configuration
and
this
network
and
vpn
service
monitor
performance
monitoring
model
is
supposed
to
do
the
service
monitoring.
K
K
You
can
see
that
these
issues
has
been
tracked,
along
with
other
their
models
and
and
the
issues
about
this
revision,
mostly
related
with
like
how
to
we
should
add
in
some
layer,
two
vpn
mac
entry
counters
and
also
add
a
like
a
a
pm
resource
to
indicate
what's
a
prodigal
for
those
performance,
monetary
metrics,
and
we
also
have
the
comment
that
we
should
reuse
the
most
definition
of
the
vpn
common.
K
Please,
for
the
young
model
updates,
as
I
just
mentioned,
we
add
a
new
container
for
a
mach
number
to
to
also
include
to
support
later
to
weeping
magic
entry
counters,
like
not
only
just
like
the
previous
revision,
just
support
the
layer,
3
vpn
root
counters,
but
this
time
we
add
mac
table
counters,
also
and
and
on
the
right
we
add
the
you
can
see
that
we
add
a
new
leaf
pm
source
to
show
the
link
performance
data.
K
Coming
from
like
something
like
like
the
layer
20m
defined
in
layer2nn.
K
So
this
is
for
the
young
model
updates,
because
the
most
young
structure
hasn't
changed
much.
These
two
are
the
new
nodes
we
added
to
this
model
and
next
fight.
Please,
oh,
oh
that's
of
the
last
one
and
I
think
right
now
we
don't
have
the
open
issues
here
and
because
they're
the
design
team
right
now
focused
on
their
to
nam
and
their.
There
are
a
lot
of
heavy
discussions,
so
we
will.
K
We
are
planning
to
to
do
more
improvements
after
the
the
two
and
then
the
working
group
last
call,
and
we
we
also
selected
more
comments
and
reviews
from
working
group.
That's
all
thank.
A
You
yeah
well,
I
I
had
a
question
on
on
this.
I
I'll
I'll
read.
Admittedly,
I
haven't
read
the
latest
version,
so
the
way
you
describe
p.m,
source
and
the
way
I
see
it
here
as
a
as
a
string,
I'm
kind
of
curious
is
is:
is
that
the
right
way
to
model
that
or
is
there
some
way
of
of
kind
of
referencing,
that
back
to
something
or
using
like
an
identity
or
or
something
more
normalized
yeah?
I
guess.
K
I
actually
checked
the
with
the
the
three
in
them
and
also
their
two
in
them
drops
and
to
see,
and
also
vpn
common
drop
to
see
whether
there
is
some
like
identity
to,
but
it
seems
that
we
cannot
list
all
of
those
and
they
they
could
have
many
other
sources
like
sometimes
the
this
the
source,
maybe
is
not
directly
from
om
protocols
like
sometimes
the
the
just
from.
K
I
think
in
my
memory
I
I
think
I
looked
through
all
those
drops
and
I
can't
find
a
list
of
oem
protocol
defined
and
they
just
list
one,
and
so
there
is
no
one
place
to
refer
to.
So
I
think
this
is
an
open
issue.
I
will
work
on
on
the
next.
F
K
On
later
on,
I
think
it's
a
good
question
and
I
because
right
now
it
seems
a
string
and
and
people
will
feel
confused
when.
A
Thanks
for
explanation
and
looking
into
it,
other
questions
comments
on
performance,
monitor
draft.
A
We
have
got
twos
up
next
elliot,
discovering
and
retrieving
software
transparency.
E
So
rob
if
you'll
cover
minutes
when
you
see
okay,
great
thanks
all
right,
so
I'm
here
to
talk
about
two
drafts
and
I'll
try
to
be
brief.
I'm
speaking
today
on
behalf
of
myself
and
scott
rose
in
terms
of
draft
ietf
s
bomb
access
to
next
slide.
Please.
E
All
right,
so
what's
this
draft
about
this
is
meant
to
answer
two
questions.
What
software
is
on
a
particular
system
and
what
vulnerabilities
does
that
software
have
now?
The
second
bullet
is
a
change
from
the
previous
draft.
We
added
vulnerability
information
I'll
talk
more
about
that
in
a
minute.
Next
slide.
Please.
E
Okay,
so,
as
I
mentioned,
we've
added
support
for
vulnerability.
E
Now
open
c2
is
not
like
a
restful
endpoint,
it's
a
protocol,
endpoint
and
so
I've
been
in
touch
with
the
openc2
people
and
what
we
should
probably
be
thinking
about
as
we
as
this
thing
head
towards
working
group
last
call
is
just
to
liaise
with
the
oasis
people
to
say:
hey
we're
coming
close
here.
Does
the
do
the
references
look
good?
Can
you
confirm
that
that
this
is
something
you
want
to
have
supported?
And
things
like
that?
E
The
we
we
fixed
some
versioning
for
cloud-based
access,
because
previous
versions
had,
if
you
were
pulling
a
live
copy
of
a
software
build
materials,
you
would
also
get
versioning,
and
that
was
just
wrong
because
you
get
what
you
you
know,
the
the
versioning
was
there.
If
you
needed
to
look
up
a
nest
bomb
by
version,
but
if
you
were
just
pulling
something
live
off
a
system,
you
got
what
was
actually
installed.
E
The
functionality
is
actually
working
on
mudmaker.org
test
and
you
can
play
around
with
it
next
slide.
Please,
okay,
just
a
reminder
as
how
all
this
might
fit
together
right.
This
is
more
for
review.
You
might
have
some
console
that
sits
there
on
the
right
and
it
will
take
in
information
and
where
you
see
the
word
vex,
that's
vulnerability,
information,
people
taking
vulnerability,
information,
cves
software
bills
and
materials
in
the
form
of
spdx
or
cyclone.
That
should
be
say:
cyclone
dx,
not
cyber
dx,
and
it
will.
E
It
will
discover
this
information
via
mud
right
and
then
based
on
that
match,
cves
against
cves
for
the
installed
software.
That
is
indicated
by
the
s-bomb
right,
and
then
you
use
the
vulnerability
information
that
the
vendor
provides
to
say:
hey,
wait
a
minute!
I've
already
fixed
this
cve,
so
don't
try
and
don't
bother
warning
the
user
about
that
being
installed
now.
E
The
the
little
the
duceus
that
you
see
there
is
is
basically
meant
to
be
like
a
medical
device
manufacturer,
and
here
they
will,
they
might
use
other
mechanisms
to
collect
the
same
sort
of
information.
E
E
So
that's,
basically
the
the
vision
for
a
lot
of
this
stuff.
Next
slide,
please,
okay,
so
there,
the
just
to
remind
you.
There
were
three
classic
methods
for
providing
this
information.
The
information
might
be
on
the
box,
so
your
software
inventory
might
be
available
directly
on
the
box,
and
if
it's
like
a
linux
system,
you
can
think
of
this
as
something
like
d
package
or
rpm,
providing
you
information.
E
It
could
be
off
the
box
now.
This
is
going
to
be
for
like
really
small
systems,
so
a
good
example
might
be
suppose
you
have
a
sensor,
that's
trying
to
detect
whether
cement
has
dried
and
the
company
there
they're
companies
like
wholesome
that
use
these
sensors
and
they
last
for
six
weeks.
They
may,
if
you
want
to
see
the
software
build
materials.
E
E
Now.
Another
key
point
is
that
the
draft
is
format
neutral.
There
are
some
amount
of
there
are
a
number
of
formats
that
are
that
are
in
play.
Cyclone
dx
is
one:
spdx
is
another
for,
for
us
bombs
and
for
vulnerability.
Information
people
seem
to
be
aiming
towards
something
called
the
common
security
advisory
framework,
and
that
is
also
work
being
done
by
oasis,
and
so
I've
been
talking
with
them
about
this
as
well,
so
that
you
could
get
the
same.
E
So
we
can
get
pulled
out
information
next
slide.
Please.
E
So
here's
the
model-
it's
no,
I
I
don't
call
it
s
bomb
at
the
at
the
module
level
layer
anymore
and
that's
because
we're
including
these
two
different
types
of
information,
which
is
to
say
sulfur,
builds
material
and
vulnerability.
Information,
and
you
can
see
here
in
the
model
that
you
can
have
one
or
more
s-bombs
based
on
for
the
cloud,
but
you're
not
gonna
have
that
for
for
other
mechanisms,
and
the
same
is
true
for
vulnerability.
Information
which
leads
to
a
question
next
slide.
E
Please,
okay,
one
question
is:
does
it
make
sense
to
actually
have
vulnerability?
Information
come
from
the
device
itself
or
is
that
something
that's
just
going
to
be
on
out
there
on
the
vendor
website
and
you
can
think
of
vulnerability,
information
and
csaf
in
particular,
as
things
like
pcert
advisories
saying
you
know,
you
know,
hey
we've
got
some
vulnerabilities
or
no.
This
thing
isn't
vulnerable.
As
an
example.
E
Second,
question
is:
do
we
have
the
right
security
model,
some
stuff
that
really
needs
testing
the
current
security
model
for
for
this
work
is
if,
if
it
relies
on
the
underlying
mechanisms
like
http,
co-op
and
etc,
I
think
a
little
bit
of
deployment
experience
will
will
tell
us
whether
we
have
this
right
in
particular,
if,
if
vendors
want
to
hold
a
software
bill
of
materials
close
to
the
vest,
there
will
be
a
login
step
and
then
perhaps
an
oauth
token
will
be
exchanged
into
a
tool,
and
so
there
might
need
to
be
some
interaction
initially
as
devices
in
order
to
collect
certain
software
bills
and
material.
E
E
Finally,
as
hank
is
here,
he
and
I
talked
about
coram
coswid,
and
do
we
want
to
support
these
now?
We're
format
neutral
quorum
as
hank
explains
it
to
me,
is
neither
fish
nor
foul
in
terms
of
it's
not
really
a
software
build
materials
on
its
own.
It's
a
little
bit
something
else,
and
so,
while
yes,
we're
we're
format
neutral,
this
is
this
is
something
slightly
different.
E
It
might
need
to
add
a
little
bit
more
into
the
model
and,
if
hank
wants
to
say
more,
he
can,
but
maybe
I'll
just
hold
that
to
the
end,
which
might
be
the
next
slide
in
terms
of
this
draft.
J
E
Slide
yeah,
so
there
are
so
proposed
next
steps,
I'd
like
to
start
getting
some
reviews
from
from
different
areas,
and
I
really
like
a
little
bit
of
guidance
on
on
security.
I'm
I
I
think
I
have
this
right.
I've
tested
something
along
these
lines,
but
some
broader
security
review
would
be
good,
though
that
well-known
uri
review
is
is,
is
also
helpful.
I
did
get
one
comment
back
from
patrick
saying:
do
we
really
have
to
have
you
know
a
top
level?
You
know
transparency.
E
Endpoint
can
we
just
have
vol
and
an
s-bomb
as
the
top-level
well-known
endpoints,
and
I
think
that
should
be
a
question
that
that
I
just
asked
the
reviewers
and
then
take
their
advice
based
on
their
response.
I
don't
think
anybody
really
cares
what
the
what
the
the
names
are
as
long
as
they
follow,
whatever
procedures
are
in
place
or
get
off
my
lawn,
which
is
the
name
of
the
the
rfc
that
cover
this
and
then
my
hope
is
to
sort
of
get
that
done
and
then
just
a
little
before
the
next
ietf.
E
B
B
Okay,
where
to
start
so
I
like
this,
this
top-level
semantics
of
transparency,
because
it
gives
you
insight
into
the
device
that
this
is
all
about.
It's
comes
aligning
with
the
various
efforts
that
are
now
rippling
through
several
u.s
bodies
here
in
the
moment
about
the
supply
chain
security.
So
so
that
aligns
well.
B
I
think,
then,
about
the
a
very
explicit
format
that
is
coast
with
in
the
coast
with
I
don't
know
introduction
for,
like
I
don't
know
five
years
now,
it's
took
long
in
the
making
here
because
it
was
the
very
first
thing
in
the
cdlc
were
to
be
created
at
the
front.
It
says
this
is
used
for
vulnerability
assessment,
so
vex
is
doing
nothing
else
here.
B
So
that's
there
now
for
at
least
for
now
it's
a
moving
target,
because
this
is
all
very
hastily
being
stitched
together,
so
that
might
evolve
typically
I'd
say
for
for
mud.
Don't
worry
about
content
format
too
much,
but
maybe
provide
an
option
to
enumerate
these
and
and
add
these
to
the.
What
do
you
think
you're
actually
fetching
there?
Will
this
be
an
sbdx?
B
Will
that
be
a
cyclone
dx
expression?
I
think
that's
interesting
to
the
manager
that
is
consuming
the
mud,
url
and
then
consuming
the
mud
file
and
then
fetching
all
that
in
the
end.
Otherwise
it's
just
a
big
surprise.
B
So
so
that
might
be
something
and
then
you
can
just
add,
for
example,
to
an
list
of
formats
coastfield,
but
you
don't
have
to
worry
about
the
actual
encoding
in
the
end
and
and
final
comment
on
co
rim
that
definitely
uses
coast
with.
B
So
so
that's
where
the
the
heart
overlap
with
rats
is
because
reds
the
muddy
rats
will
discover
korean
and
there
will
be
coasts
within
these
and
there
might
be
some
semantic
overlap
with
then
the
transparency
module
here
that
also
could
discover
a
co-switch
ex
more
explicitly
but
under
the
s-bomb
leaf.
B
So
in
in
red,
it's
under
the
the
column
statement
and
in
and
here
it
would
be
under
the
s
form
statement,
so
that
might
not
be
bad
at
all,
but
we
really
have
to
at
least
spread
that
out
bonds
that
there
are
might
be
other
means
to
find
these
specific
items.
So
these
are
my
comments
on
here
and
how
this
should
be
done.
I
actually
don't
know
it's
weird
and
yeah.
I
have
no
idea.
E
Okay,
thank
you
for
that
hank.
Let
me
just
add
one
or
two
comments
there:
the
draft
and
term
the
way
it
works
is-
and
I
think
I
could
do
a
little
bit
better
on
this,
but
the
intent
right
is
to
look
at
content
type
in
terms
of
the
response
and
say,
and
for
the
tooling
that's
retrieving
this
stuff
to
to
to
either
take
all
comers
or
silently
discard
stuff.
It
doesn't
understand.
E
I
think
we
can
be
a
little
bit
more
granular
than
that
which
is
you
know.
These
formats
that
are
available
are
between
cyclone
dx
and
spdx,
and
maybe
even
sweat,
I'm
not
sure,
but
certainly
with
the
the
two
former
ones
they're
interchangeable,
because
the
information
elements
are
almost
the
same,
and
so
the
producer
might
produce
both.
And
at
that
point,
if
the
thing
sits
off
in
a
cloud,
it
may
be
reasonable
to
include
an
accept
header.
E
It's
a
little
less
reasonable
to
include
an
accepts
header
when
you're
going
through
the
device,
because
I
don't
know
that
it'll
have
all
the
tooling
to
generate
this,
that
or
the
other
type
of
format.
So
I
I
think
I'll
take
that
as
an
open
issue
and
work
on
that,
if
you
don't
mind
and
then
for
co-rim
I'll
just
add,
I
think
what
we'll
do
is
we'll
continue.
Our
conversation
we'll
look
at
timing.
E
I
don't
want
to
hold
this
up
too
much
precisely
for
the
reasons
that
you
mentioned,
which
is
that
given
the
regulatory
pressures
and
it's
not
just
coming
from
the
u.s
that
that
I
think
people
do
need
to
to
start
to
put
together
their
building
blocks,
and
this
you
know
discovery
of
where
the
s-bomb
is
and
where
this
vulnerability,
where
the
vulnerability
information
is,
is
a
big
part
of
that.
If
they
can't
figure
out
where
it
is,
what
are
they
going
to
do?
Use
postal
mail
so.
B
Yeah,
I
think
not
delaying
this
too
hard
is,
is,
I
think,
a
very
good
objective,
and
I
I
assume
that
all
these
items
can
be
resolved
in
a
matter
of
one
or
two
months,
and
that
should
be
ready
for
our
next
itf
meeting.
E
Yeah,
so
my
request
to
the
chairs
is
only
this,
which
is
to
help
facilitate
area
reviews
early
area
reviews
at
this
point.
A
Got
it
yeah,
we'll
we'll
get
this
tee'd
up
for
for
some
direct
reviews.
E
Thank
you.
Okay
next
slide,
please
and
I'll
press
on
from
here
this
one,
I'm
going
to
be
extremely
brief
on
karsten
found
a
problem.
The
problem
was,
he
couldn't
copy
mud
files
from
some
third-party
providers
because
he
didn't
see
any
permission
statement
and
so
there's
no
way
in
the
json
to
express
copyright
and
licensing
terms.
So
this
extension
does
that
and
it
could
be
used
by
others
apart
from
mud.
E
So
I
made
it-
I
you
don't
see
mud
in
the
name
of
the
draft,
but
the
idea
is
to
allow
if
somebody
else
runs
into
this
problem
with
jason
at
rest
that
we
can,
we
can
solve
it
there
next
slide,
please
so
here's
the
model
right!
You
have
a
list
of
owners,
there's
a
license
type
this.
This
equates
to
an
spdx
tag.
E
Spdx
has
a
fairly
complete
list
of
common
licenses,
but
if
you
don't
want
to
use
one
of
those
provide
a
pointer
to
your
own
and
that's
the
entire
model
extension
my
proposal
at
this
point
next
slide.
Please
is
a
tab,
discussion.
Okay,
so
I
think
I've
explained
this
already
next
slide.
Please
is
to
to
have
discussion,
but
could
we
please
adopt
this
draft
and
just
knock
it.
A
Thanks,
I
think
we
can
bring
this
up.
It
does
seem.
I
haven't
read
it
all
the
way
through
it
does
seem
like
interesting
work.
Hank
did
you
want
to
say
something?
I
see
you
green.
B
Yeah,
I
I
think
put
the
request
for
this
on
the
might
have
already
been
there
to
the
the
wg
list,
and
then
we
can
yeah
confirm
that
as
a
request
for
working
group
adoption,
it
is
relatively
easy
to
review
I'd
say
so.
It
is
relatively
easy
to
to
find
people
who
might
have
an
opinion
about
this,
and
then
you
can
move
this
along.
A
A
L
And
it
was,
I
took
it
to
the
dns
op
working
group
it
in
march.
We
had
an
interesting
conversation
and
that
went
really
well
if
you're
interested
watch
the
video,
that's
the
offset
there.
It's
like
10
minutes
long,
but
most
the
advice
was
essentially
telling
us
that
a
lot
of
it's
not
going
to
work
so
next
slide.
Please.
L
So
the
fundamental
issue
comes
down
with
mud
files
and
iot
devices
and
things
that
are
like
geofenced
or
otherwise
depend
on
on
content,
where
the
server
gives
out
a
different
answer
depending
on
who's
asking
and
the
issue
is
that
if
the
iot
device
gets
a
different
answer
than
the
mud
controller,
then
the
access
control
list
is
not
created
correctly,
which
usually
will
result
in
the
mud
device.
L
The
iot
device
trying
to
access
a
resource
on
the
internet
and
being
denied,
because
it's
got
the
wrong
ip
address
or
an
inconsistent
ip
address,
and
then
what
does
that
do?
Well
it
probably
if,
if
things
are
working
right,
it
sends
off
an
alarm
which
is
of
course
a
false,
positive
and
gets
everyone
upset,
because
false
positives
cost
a
lot
of
money
to
investigate
and
it's
hard
to
know
what's
going
on
for
that.
So
next
slide.
L
So
the
summary
was
it's
not
going
to
work,
sort
of
having
a
magic,
dns
server,
that
the
mud,
controller
would
use,
and
probably
control
and
the
iot
device
would
be
cons,
would
be
convinced
to
use
that
you
know,
could
do
things
like
ignore
the
time
to
live
as
appropriate
or
at
least
inform
the
mud
controller
when
a
query
returned
a
different
answer
or
a
bunch
of
stuff
like
that
that
we
could
consider
and
well
that
is
conceivable
in
a
home
network
scenario
where
it's
all
in
the
your
home,
router
the
mud,
controller,
the
nest
server
and
everything
it's
not
going
to
work
well
in
the
enterprise
scenarios
that
elliott
likes,
and
I
think
that
we
should
care
a
lot
for
so
my
only
real
conclusion
is
to
suggest
if
this
really
doesn't
work
that
you
to
tell
vendors
in
the
document.
L
Please
don't
do
this.
That
may
be
very
unpopular,
and
but
it
may
be.
What
we
need
to
say
is
don't
do
this.
It
isn't
gonna
work
next
slide.
Please
that's
it
for
that
document.
E
L
E
Ops
people
may
not
like
some
of
the
things
that
actually
get
done
to
deal
with
this
yeah
and
that
so
one
of
the
things
that
that
can
be
done
and-
and
this
works
fine
as
far
as
it
goes
right-
is
that
the
queries
can
be
intercepted
in
the
in
the
network.
And
then
you
just
deal
with
the
response
and
and
record,
and
you
record
the
response,
and
then
you
just
manage
things
like
you
know
you,
you
be
conservative
in
terms
of
expectations
of
cash
timeouts.
E
What
is
what's
important
for
the
client
is
simply
that
if
the
connection
breaks,
they
should
retry
a
query
not
just
go
directly
to
to
the
old
address,
because
the
cache
may
have
been
may
have
expired,
the
other
point,
and
then
we
we
did
discuss
this.
I
think
on
the
list
is
that
if
there's
more
complete
integration
between
the
the
name
service
function
and
the
access
control
function
within
the
network,
then
this
problem
is
obviated,
and
I
think
that
was
pointed
out
unless
so
and
that
yeah
and
sorry
so.
L
All
of
that's
a
good
good
suggestion,
and
it
completely
breaks,
of
course,
as
soon
as
the
device
decides
he
wants
to
do,
dns
over
http
and-
and
I
actually
think
that
one
of
the
advices
to
iot
devices
is
they
really
shouldn't
do
that
that
it
breaks
all
sorts
of
other
things
that
people
assume
they
want
to
do.
L
And
so
I
really
think
that
that
that
actually
may
be
an
additional
strong
suggestion
to
manufacturers,
and
I
think
that
part
of
the
problem
here
elliot
is
that
this
has
got
to
be
advice
to
iot
manufacturers,
and
they
don't
know
if
it's,
what
kind
of
a
mud
environment
it's
going
to
go
into,
and
so
they
have
to
figure
out
what
they
can
do
and-
and
I
don't
know
we
might
even
need
to
go
to
the
point
of
saying
whether
or
not
the
you
know
declaring
in
the
mud
file
whether
the
device
is
compliant
to
some
piece.
E
Yeah,
I
think
we
need
to
continue
work
on
this
draft
a
little
bit
more
to
get
to
get
the
advice
to
manufacturers
consistent
in
terms
of
you
know
how
to
make
make
sure
that
a
they
you
know
they
should
be
careful
about
how
they
do
cloud-based
services
and
and
in
terms
of
address
you
know,
addresses
and
that
the
you
know
this
is
not
a
high
volume
service
or
shouldn't
be
shouldn't,
be
considered
high
volume
service.
E
You
shouldn't
have
to
worry
too
much
about
you
know
having
to
heavily
load
balance
and
stuff,
but
I
think
that
even
that
advice
I'm
nervous
about
giving
it,
because
I
think
the
better
approach
is
to
work
it
in
the
deployment
rather
than
to
work
it
on
the
device.
I
think
that's
what
you
heard
from
the
dns
ops.
People
too
sure.
L
Okay,
all
right
anybody
else.
L
Thanks
so
next
slide,
please
so
the
fundamental
question
comes
down.
Is
you
know?
How
do
you
change
or
update
your
mud
file
and
they're
the
document
as
we've
gone
through
this
before
there's
two
kind
of
ways
you
can
change
the
url
or
you
can
change
the
content
of
the
mud
file
for
an
awful
lot
of
things,
just
updating
content,
the
mud
file
probably
is
the
right
answer,
but
there
are
some
issues,
particularly
when
it
overlaps
with
firmware
updates
that
do
different
things.
L
If
you
are
using
teahu's
document
on
tls
profiles,
for
instance,
you
could
create
a
lot
of
false
positives.
L
If
your
firmware
update,
then
includes
say
a
difference
in
a
tls
version,
you
need
to
make
sure
that
the
old
firmware
uses
the
old
profile
and
the
new
firmware
uses
the
new
profile,
and
I
think
that's
pretty
important
for
some
things.
So
then
the
question
is:
if
you
want
to
update
the
you,
the
url,
how
do
you
do
this
next
slide?.
L
So
we've
had
some
different
ideas
and
the
fundamental
one
is
that
we're
saying
that
we
need
to
update
85
20..
I
feel
like
it's
82,
50
85
20.,
to
say
that
the
base
url
must
always
be
the
same
and
that
you
can
change
the
last
component.
So
I
think
next
slide
has
an
example.
L
I
just
go
to
the
next
one
after
that,
so
the
next
time
an
example.
So
if
you
start
off
with
the
first
one
and
it
says
mud001.json
that
you
could
change
it
to
mod
002.,
that's
allowed
remember
see
it
has
the
printer
4567.
L
That's
all
change
say
the
same,
but
if
you
changed
it
to
gamepad
two
or
something
like
that,
that's
not
allowed,
or
if
you
change
the
domain
name,
that's
also
not
allowed,
and
so
this
allows
means
that
you
can
change
your
mud
url
in
your
dhcp
or
your
lldp
reply,
and
that's
okay,
but
the
first
one
that
you
got
was
either
trust
on
first
use
or
it
came
from
the
idev
id
when
you
did
enrollment
and
that's
what
you
started
with
on.
L
The
other
thing
to
import
is
that
within
the
mud
file,
there
is
a
reference
to
the
mud
file
url.
So
if
you
want
to
do
something,
you
know
like
completely
apparent
where
it
is
well.
First
of
all,
you
need
to
update
it
in
its
old
location
and
then
that
becomes
the
new
base
url
for
the
the
next
iteration
of
of
things.
L
It's
a
two-step
process
and
I
think
that
handles
all
of
the
issues
with
with
mergers
and
acquisitions
and
the
fact
that
marketing
wants
to
rebrand
everything
or
something
like
this,
and
they
just
need
to
do
it
in
two
steps.
That's
all
next
slide,
please,
I
think
that's
the
last
one
yeah
so
adopted
in
2012.
I
don't
think,
there's
anything
really
else
to
say
about
it.
I'd
like
to
have
some
more
reviews
and
some
other
stuff
like
this,
and
I
think
we're
pretty
close
to
having
a
working
group
last
call.
L
A
So
no
other
questions
we
can
move
on
to.
I
think
we
are
at
peak.
L
Me
again
yeah
looking
from
rather
hat,
I
don't
have
another
hat
here
to
wear
sorry
hi.
So
it's
me
again.
I
want
to
talk
to
you
about
pcap
and
pcap
ng.
These
are
two
documents
that
are
there.
One
is
oh,
I
mistyped
the
second
one,
I'm
sorry
it's
opp's
awg
p-cap
ng,
and
these
are
things
that
have
existed
for
30
p-cap
has
existed
for
around
30-35
years
or
so
like
this
at
this
point
next
slide
please.
L
So
this
was
first
discussed
in
itf
90
in
toronto.
I
remember
having
a
conflict
and
couldn't
come
to
that
session
and
bill.
Michael
tookeson,
you
know,
was
enthusiastic
about
putting
it
forward
and
they're.
Just
they
just
you
know,
was
hard
to
push
up
the
hill
at
the
time,
and
so
I'm
back
with
this
with
you,
this
I'm
wearing
the
hat
of
being
the
maintainer
of
tcp
dump
and
there's
a
number
of
the
other
authors
are
involved
in
other
pieces
like
this,
and
so
it's
used.
L
The
pcap
format
is
reused
really
everywhere
by
all
sorts
of
people,
for
you
know,
oarc
and
other
dns
people
and
jeff
houston
uses
all
over
the
place
and
stuff.
Like
this,
and
probably
most
of
you
have
used
it
at
various
times
next
slide,
please
so
the
pcap
document
is
proposed
to
be
informational.
You
could
even
publish
it
as
historic
if
you
thought
that
was
a
good
idea.
I
don't
think
I
really
care
one
way
or
the
other,
but
it
you
know,
documents
have
gone
out
and
gone
too
historic
immediately.
L
L
There
is
a
we
cannot
go
to
interdependence
submission
editor,
we've
determined
because
there
is
an
iana
registry
that
we
need
to
create
and
we
cannot
create
them
properly
from
an
ise
stream,
so
it
has
to
go
through
a
working
group
or
an
ad
sponsor
and
I'll
just
mention
that
one
of
the
things
that
pcap
files
is
you
can't
cat
two
of
them
together.
You
can't
concatenate
together
and
get
sensible
result
next
slide
kind
of
explains
that
next
slide.
L
So
that's
because
there's
this
green
header
at
the
beginning
of
each
of
each
packet,
if
you
want
to
know
the
shape
and
the
size
of
that
l2
header,
you
have
to
know
the
link
type,
and
I
said
we
have
about
290
of
them
and
they're,
not
all
ip.
Some
of
them
are
usb.
Some
of
them
involve
things
like
radio
strength,
values.
L
There's
there's
just
a
wide
variety
of
things
that
people
have
decided.
They
want
to
put
in
pcap
format
because
they
have
they
capture
things
in
certain
things.
An
awful
lot
of
them
are
ip
over
foo
for
wide
varieties
of
foo.
L
To
do
this,
and
as
again
as
I
said,
if
the
offset
into
where
the
l3
starts
is
unknowable
until
you
know
the
link
type,
so
that's
an
unfortunate
attribute
of
this
and
that's
how
it's
been
for
30
years
next
slide,
please.
L
So
the
pcap
ng
effort
started
around
2007,
particularly
in
the
windows
port
of
tcp
dump.
They
discovered
they
needed
to
do
other
things,
because
they're
they're,
the
the
the
content
was
not
that
they
could
get
out
of
the
capture.
Mechanisms
is
weird
and
different
and
wireshark
if
you're
familiar
with
that,
has
definitely
run
with
it
and
it
reads
and
writes
them
more
or
less
by
default,
as
pcap
ng.
I
personally
hate
that
name
peak
ng.
L
I
think
anything
ng
needs
to
be
renamed
before
it's
used
and
but
I
you
know,
won't
fall
on
that
sword.
There's
a
whole
bunch
of
stuff
in
this
document
right
now,
because
it's
become
the
the
so
a
bit
of
a
dumping
place
for
anything
that
was
new
new
kinds
of
blocks,
and
so
there's
a
few
like,
for
instance,
the
systemd
logger
logging
block.
That
probably
could
be
moved
to
a
different
document
such
that
this
could
be
about
ipcapture.
L
Only
so
the
link
type
again
is
in
common
with
pcapp,
but
that's
it
next
slide.
Please
the
file,
otherwise
has
a
series
of
section
header
blocks.
Enhanced
packet
blocks
interface
description
blocks
and
they
can
be
interspersed
in
any
way
in
any
order
that
you
like.
So
if
you
have
the
statistics
for
how
many
packets
you've
captured
and
how
many
you've
dropped
and
it's
convenient,
you
know
you
can
put
that
in
every
thousand
packets
or
something
like
this.
L
You
can
change
the
link
type
between
in
what
are
now
called
enhanced
packet
blocks,
and
so
you
can
capture
from
different
sources
and
put
them
in
different
places
in
different
ways.
So
there's
a
lot
of
different
ways
of
doing
that.
That's
the
major
change
to
this.
If
we
started
this
now
well,
we
do
it
all
in
seabor
with
a
cddl
description,
but
that's
kind
of
a
bit
late
for
that.
L
So
we
could
publish
this
as
an
informational
because
there's
not
as
much
change
control
to
the
ietf,
as
perhaps
everyone
would
like,
but
I
would
only
want
to
do
that
if
the
desire
was
then
to
start,
you
know
a
pcap3
working
group
or
something
like
that,
other
than
that.
I
think
it
just
should
be
published
and
people
should
should
we
can
revise
it
later
on.
L
L
Please
so
we've
talked
about
this
on
and
off
for
a
long
time.
I
would
love
if
we
could
just
adopt
it.
I
would
love
suggestions
on
whether
or
not
you
agree
with
me
that
you
hate,
ng
or
we'll
just
continue.
I
think
we
do
need
for
the
pcap
mg.
L
We
probably
need
a
small
design
team
to
meet
a
few
times
to
polish
the
document
off
and
deal
with
with
content,
and
I
would
propose
to
organize
that,
but
basically
I'd
like
to
get
to
I
like
to
finish
it
off
quickly
and
then,
if
someone
wants
to
make
a
revision,
that's
great.
Let's
do
that.
E
Okay,
I
will
turn
on
my
my
my
video
just
for
a
few
moments.
First,
thank
you.
Thank
you,
michael
for
that
marathon
of
presentations.
The
my
suggestion
is,
we
split
the
discussion
into
two.
The
pcap
draft
is
pretty
clearly
informational.
There's.
E
Very
little
of
any
development
going
into
pcapp.
If
I
understand
correctly,
that's
not
entirely
true
right,
you
can
but,
but
maybe
it
is
mostly
true,
I'm
not
sure
well
so.
L
So
so
that
there's
the
the
word
pcap
out
there
outside
the
ietf
refers
to
a
variety
of
different
things,
including
how
you
get
packets
out
of
the
kernel
and
since
a
lot
of
people
would
like
to
do
that
at
10
gig
and
write
them
to
disk
there.
There
are
actually
some
considerations
back
and
forth,
but
those
are
coding
considerations,
not
itf
considerations.
E
Okay,
as
long
as
the
specification
is,
is
stable
and
done
I'd
say
just
let
I
I
would
support
the
idea
of
adopting
and
going
to
informational,
pretty
quickly
the
pcap
ng
is.
I
I
have
a
couple
of
questions.
My
recollection
from
the
previous
discussions
about
this
draft
was
that
there
was
strong
support,
particularly
in
the
wireshark
community,
for
this
stuff
being
worked
on
at
the
ietf,
and
so
that
that's
really
good.
E
The
question
I
have
is
the
velocity
of
change
for
new
blocks,
and
things
that
might
require
updates
of
of
the
rfc
itself
is,
is
an
rfc.
The
right
vehicle
here
is,
the
only
question
is
what
it
boils
down
to
is
the
work
gonna
be
so
is,
is
the
velocity
of
work
so
so
fast
that
we
won't
be
able
to
keep
up.
That's
my
question
so.
L
So
the
the
work
is
cumulative,
so
the
stuff
that
is
out
there
in
the
document,
with
a
few
exceptions
where
I
think
that
it
just
crosses
over
boundaries
of
who
needs
to
know
what
is
pretty
much
stable.
Yes,
there's
new
things
added
and
that's
why
I'm
saying
there
isn't
iana
considerations
for
getting
block
types,
and
I
don't
think
that
we
need
to
do
ietf
actions
on
them.
It's
enough.
L
We
should
have
a
first
come
first
serve
area
which
is
generous
and
we
should
have
a
specification
required
which
doesn't
mean
ietf
document.
Just
you
know:
here's
a
url
on
a
website,
okay,
that
describes
it
and
there
and
what
we
may
do
if
they
are
network
related.
The
new
block
types
is,
we
may
come
back
in
five
years
and
you
know
merge
them
into
a
new
document
of
so
that
they're
clearly
documented,
but
essentially
yeah
you're
right,
I
think
the
the
wireshark
community.
L
You
know
we
deal
with
a
new
link
type
request,
which
is
not
the
same
as
a
block
request,
but
a
new
link
type
request
approximately
twice
a
month.
Okay
at
this
point,
but
again
these
are
are
mostly
people
doing
like
you
know,
I'm
capturing
from
this
weird
thing
that
does
this
thing
and
measures
fish
and
whatever
and
we
just
say
well,
there's
a
stable
specification.
We
can
point
to
and
that's
the
same
as
what
ayanna
would
do.
M
F
L
F
L
Except,
I
think
that
actually
would
actually
state
the
the
that
actually
would
really
represent
the
the
what's
real
the
reality.
M
F
So,
that's
that
that
seems
to
make
sense
all
right,
I'll,
also
support
adopting
the
pcap
ng.
I
think
that's,
I
think
it's
good
useful
work
to
take
forward
if
there's
interest.
F
C
L
Oh,
so
all
right,
so
I'll
rep
make
it
clear.
I
I
run
the
tcp
dump
group,
so
I'm
the
the
maintainer
of
lib
pcapp
and
most
of
the
people
who
are
extremely
active
in
that
area
are
co-authors.
On
this
group.
On
this
document
already
gerald
coombs
who's,
one
of
the
co-authors,
is
the
maintainer
of
wireshark.
L
How
many
more
reviewers
can
we
pull
out
of
the
wireshark
community?
That's
an
open
question
and
I
hope
the
answer
is
at
least
10.,
but
I
don't
think
we're
stepping
in
anyone's
codes
or
gonna
be
my
own.
E
I
think
I
I
I'm
willing
to
support
the
adoption
of
this
work,
but
I
don't
think
that
a
new
work
should
just
be
randomly
thrown
around
in
other
documents
elsewhere
out.
You
know
in
some
random
url
in
terms
of
description,
and
I
think,
as
best
as
can
be
done,
if
the
work's
going
to
be
done
here.
Let
the
work
be
done
here
and
if
you
want
to
I'm
not
saying
you
have
to
immediately
shove
everything
into
an
internet
draft
before
you
actually
do
the
pcap
work.
E
But
rather
you
know
maybe
have
a
running
set
of
updates
in
terms
of
modules
and
then
periodically
produce
that
as
an
internet
draft
that
actually
does
get
published
so
that
you
know,
if
somebody's
looking
to
actually
implement
all
of
this
there's,
the
work
is
within
the
series
and
kept
within
the
series.
I'm
I'm
really
uncomfortable
with
the
idea
that
we're
going
to
specify
just
the
base
work
and
then
people
have
to
go
to
random
locations
to
try
and
do
a
full
implementation.
L
So
so
eliot,
I
think
you're
misunderstanding
some
of
this.
So
99
of
the
time
people
in
the
link
type
they
use
is
a
10
megabit
encapsulation,
because
that's
ethernet
and
there's
no
other
thing.
The
next
most
common
one
is
the
linux
any
device
encapsulation.
Those
are
both
described
in
the
document
right
that
way
and
the
linux
one
has
tells
you
which
interface
it
came
from
as
well.
L
So
so
then
we
get
into
the
esoteric
types
and
we
get
into
things
like,
for
instance,
capture
of
usb
packets
right
very
much,
not
the
ietf's
issue.
But
it's
you
know
you
have
a
usb.
E
E
Right,
I'm
just
saying
that
you
know
if
the
work's
coming
here
let
the
work
come
here,
and
I
understand
that
it's
not
just.
I
don't
view
that
as
all
that
esoteric,
michael
and-
and
I
I
think
we
one
thing
I'll,
tell
you
what
let's
do
this:
let's
have
this
as
an
open
issue
for
discussion
going
forward,
so
we
can
move
beyond.
A
L
L
L
That's
what
the
description
is
and-
and
it's
very
actually
frustrating
to
people
that
it's
not
more
easy
to
to
do,
and
it's
not
self-describing,
for
instance,
so,
but
this
applies
both
to
pcap
and
to
pcap
ng
equally,
so
I'd
be
very
happy
to
have
that
conversation
as
part
of
the
picapng
process,
but
I
would
like,
as
I
think
you
said,
let's
just
publish
the
other
one
as
historic,
because
we
can't
change
anything
particularly
about
we
can't
adding
to
that
document
is
not
going
to
help.
Anybody
is
what
I'm
trying
to
say.
A
So
I
I
had
a
similar
comment
to
elliot,
but
in
in
time
or
in
consideration
of
time
thanks
for
presenting
michael,
I
think
we
have
there's
clearly
some
interest
in
this
we'll
bring
it
to
ops
area
working
group
list
for
an
adoption
call
on
the
pcapp
in
g
work,
and
I
I
agree
with
what
others
have
said
around
the
the
pcap
as
a
normative
sorry,
an
informative
base
to
that.
A
So
likely
we'll
see
what
the
working
group
thinks
about
the
ng
work
and
then
based
on
that
we
can,
we
can
move
forward
with
both
documents.
Okay,
wonderful,
thank
you
for
your
time.
Thanks
and
with
that.
Ladies
and
gentlemen,
we
are
on
the
ops
area
portion
of
our
program,
so
I
would
like
to
hand
it
over
to
robin
warren
and
I
will
start
doing
some
minutes
work
over
here.
I
can
still
do
the
slides.
If
there
are
slides,
I
didn't
see
anything
from
tourists
or
from
either
of
you.
C
C
They
didn't
really
say
anything
other
than
hello
everybody
and
welcome
to
the
ops
area,
part
of
op,
say
ops
area
and
ops
awg
the
person
over
there
is
rob
wave
rob
the
person
over
here
is
warren
hi,
I'm
warren.
We
don't
really
have
much
in
the
way
of
updates.
I
think
our
primary
thing
was
the
open
mic
thing
open
mic
time
where
people
can
throw
tomatoes
at
us,
but
before
that
we
have
actually
I'll
just
hand
it
over
to
rob.
He
can
do
the
intros
right
to
the
interest
which
it
turns
didn't.
C
Yes,
to
be
able
to
do
that,
first,
we'll
do
the
open
mic
first,
I
guess:
let's
do
the
tour
of
this
presentation
first,
just
because
that
way,
any
leftover
time
can
be
used.
Actually
I
guess
maybe
we
should
do
it
in
the
other
thing.
Does
anybody
have
any
open
mic
questions
for
us
questions
and
or
complaints
and
or
general
feedback.
K
C
Well,
let's
do
tour
lists
and
people
can
think
of
questions
in
the
meantime
and
maybe
at
the
very
end.
If
there's
time,
people
can
can
tell
us
what
we're
doing
poorly,
because
that
might
take
much
more.
C
A
All
you,
I
didn't,
get
any
slides
from
you
either.
So
if
you
have
some
by
all
means,
either
make
them
aware
to
me
or
or
you
can
share.
F
C
F
C
I
guess
that
we
can
have
rob,
do
interpretive
dance
for
15
minutes.
I'm
not
going
to
do
that.
Oh
thank
you
in
the
past,
when
I
have
people
have
asked
me
to
never
do
it
again.
Alternatively,
we
could
talk
some
more
about
pcap
ng,
but
I
think
that
we
have
a
plan
for
that.
F
The
only
actually
one
other
thing
we
could
raise
that
came
up
and
warren's
gonna
hate
this,
because
I've
not
discussed
with
him
at
all
was
there
was
some
suggestion
randomly
about
whether
we
should
have
a
dispatchy
type
working
group
in
alps.
F
L
E
C
Okay,
I
mean
at
the
moment
it
seems
that
a
fair
bit
of
ops
areas,
yang
and
mud
all
day
every
day,
so
as
long
as
people
feel
that
they
can
still
bring
things
to
us
and
we
can
help
dispatch
them.
I
think
that
that's
all
working
fine.
C
Well,
I
think
tourist
has
another
minute
or
two
before
we've
reached
the
top
of
his
his
slot,
but
I
guess,
while
we're
waiting,
I
think
that
both
rob
and
I
would
always
appreciate
any
feedback
on
what
we're
doing
well
and
what
we're
doing
poorly,
and
you
know
where
people
would
like
us
to
focus
more
et
cetera.
F
The
stuff
I'm
doing
poorly
you're
welcome
to
send
that
directly
to
nom
com,
because
I
am
going
to
stand
again
for
the
next
term.
So
that's
that's
another
place.
You
can
send
it
if
you
don't
send
it
to
us.
C
And
yeah,
I
think
that
goes
for
me
as
well.
I
mean
I'm
not
up
for
re-election
or
whatever.
The
correct
term
is
this
time,
but
if
you
are
uncomfortable
sending
me
sending
me
grumpy
things
saying
that
I'm
an
idiot
feel
free
to
send
it
to
nomcom.
I
always
ask
nomcom:
if
they
would
mind,
please,
you
know
providing
feedback,
even
if
I'm
not
being
evaluated.
E
Question
around,
actually,
you
guys
are
have
a
pretty
good
view
of
the
other
areas.
Are
you
finding
that
the
other
areas
are
doing
a
pretty
good
job
at
highlighting
operational
issues
that
need
to
come
to
us
are
the
are
the
are
the
are?
The
are
the
is
the
review
process
catching
things
that
that
have
operational
impact
we've
just
gone?
E
Are
others
doing
a
good
enough
job
of
that
in
terms
of
their
work
and
have
we
you
know,
are
we
experienced?
Are
people,
particularly
in
the
ops
community,
experiencing
problems
with
because
of
new
work
coming
out
of
the
itf
or,
conversely,
is
it
all
working
great.
C
I
wouldn't
actually
say
it's
all
working
great,
but
it's
not
actually
working
very
poorly
either.
Something
which
would
actually
have
been
good
if
we
put
on
the
agenda
and
spent
more
time
on
is
talking
some
more
about
the
upstair
process
that
upstair.
I
think
it
would
be
good
if
we
could
get
more
people
participating
in
in
upstair
and
doing
review.
C
Thank
you
very,
very,
very
much
to
everybody
who
does
and
we
could
also
be
doing
a
much
better
job
of
recognizing
people
who
are
doing
reviews.
But
anybody
who
is
willing
to
do
reviews
in
upstair
and
or
you
know,
provide
just
join
upstairs.
I
think,
would
be
incredibly
helpful.
We
have
a
tourist
yep.
F
A
Chat
so
I've
turtles,
I
never
got
slides
from
you.
I
I
requested
them,
but
I
never
got
them.
G
O
O
O
O
Wait
a
second
sorry.
I
wasn't
prepared
to
to
hear
that
sorry,
yeah!
Okay,
maybe
maybe
it's
really
my
my
fault
and
I
missed.
I
gave
the
same
presentation
on
monday
first
session
to
second
so.
O
Yeah
and
yeah,
this
is
the
wrong
working
group.
Sorry
for
that,
it's
even
the
wrong
idea.
Okay,
so
I
wanted
to
quickly
just
give
an
overview
of
what
we
did
with
enema
in
the
past
five
years,
because
we
reached,
I
think,
an
important
milestone.
O
So
this
thing
actually
came
from
nmrg,
which
defined
autonomic
networks
into
rfcs,
which
was
focused
on
you
know:
automating
service
agent
kind
of
you
know,
automation
in
the
network
on
top
of
an
infrastructure,
and
this
infrastructure
is
basically
what
we
took
on
in
anima,
then
as
the
first
working
item
and
it
composes
of
three
big
components
and
so
yeah.
O
That
was
just
you
know,
five
years
420
pages
and
that
cluster
came
out
in
may
2021,
hooray
so
too
bad
that
we
couldn't
celebrate
in
person,
and
I
just
wanted
to
quickly
give
an
overview
for
the
ops
area,
because
I
think
there's
a
lot
that
can
be
reused
and
obviously
we're
also
always
happy
and
that's
a
little
bit
the
goal
of
this
marketing
exercise
here
to
get
more
ideas
coming
into
enema.
O
So
I'll
leave
a
lot
of
the
details
here
for
for
people
up
to
read
in
detail
themselves.
The
overall
architecture
I
think
what's
much
more
interesting,
is
how
does
it
look
to
the
operator
so
assume
you're,
simply
starting
to
plug
together,
routers
and
switches
physically
to
a
network
hook
it
up,
maybe
to
some
management,
laptop
or
orchestrator
controller
one
device?
These
are
all
fresh
out
of
the
you
know,
packaging
nothing
configured
and
what
the
a
I
will
do
is
automatically
create
an
in-band
virtual
network
as
a
second
step.
O
The
first
step
is
it
enrolls
all
of
the
devices
with
pki
certificates,
which
also
have
a
I
specific
information
it
does
the
addressing.
So,
in
the
end,
what
you
have
is
a
secure,
automatically
built
and
also
automatically
self-maintaining
operational
network.
Like
you
know
previously,
and
still
today
we
have
out
of
band
networks,
but
it
is
in-band,
and
you
know
the
security
aspects.
Obviously
you
know
no
unauthorized
devices
can
will
connect
into
it.
O
They're
locked
out,
no
user
data
is
flowing
right,
so
this
network
is
still
not
doing
anything
that
you
don't
want
it
to
do,
because
everything
for
the
user
still
needs
to
be
configured
as
you
have
today
or,
as
would
be
future
autonomic
stuff,
and
obviously
you
can't
spoof
anything
because
everything
is
encrypted
hot
by
hop
by
ipsec
for
this
oem
network,
and
then
all
this
functionality
of
course
persists
not
only
from
day
one
but
through
the
whole
life
cycle.
O
O
So
how
do
we
do
this?
So
the
whole
bootstrapping
stuff
obviously,
is
one
of
the
interesting
core
aspects
and
I'm
showing
here
that
this
actually
can
be
very
easy
to
configure.
So
you
know
pretty
standard
industry.
Implementations
would
have
asked
you
purely
say.
Okay,
I
want
to
have
the
so-called
registrar,
which
is
kind
of
the
seat.
O
Node,
give
it
a
name
for
the
network,
maybe
also
designate
a
specific
unprotected
network,
where
you
can
hook
up
your
local
management
laptop,
so
it
doesn't
need
the
whole
ani
stack
and
then
there
is
an
interesting
back-end
aspect
which
are
called
the
manufacturing
authorized
signing
authorities
that
you
need
to
connect
to
so
that
you
get
to
the
next
stage,
which
is
here.
While
the
boots
are
protocol,
everything
is
difficult,
but
maybe
some
funny
pictures
and
just
showing
who
is
involved
in
them
gives
you
a
better
picture
of
what
it
does
right.
O
So
the
registrar
is
really
the
central
point.
That
does
everything
so
we
do
know
their
certificate
authorities
from
which
to
get
certificates.
Ultimately,
they
need
to
get
into
what
we
call
the
pledges
which
are
the
new
devices
that
need
to
get
into
the
network.
We
may
not
be
able
to
be
directly
connected
to
them.
These
pledges
may
not
have
any
addresses
yet
on
the
ip
side,
so
we
have
automatically
brought
up
proxies.
You
know
any
device,
that's
in
the
ani
and
the
new
device
connects
to
it
will
act
as
a
proxy
and
helper.
O
We
have
address
allocation.
There's
the
database
needed
you
may
need
admission
policies
which
devices
get
into
the
network
and
ultimately,
this
massa
with
a
new
digital
artifact,
which
is
the
voucher
which
basically
tells
the
pledge
hey.
You
can
trust
this
domain
registrar,
so
you
don't
simply
blindly
need
to
trust
any
physical
network
you
get
connected
to
because
it
may
be
the
wrong
one
or
you
may
have
been
stolen
or
something
right.
O
So
that's,
basically
the
whole
bootstrap
in
in
a
wrap
for
you
and,
of
course,
we'll
give
you
all
these
details,
how
it
works
under
the
hood.
So
now
we're
on
our
second
charter.
So
we
added
these
asas
in
2020,
we're
pushing
actually
back
the
intent,
which
is
the
high
level
abstraction
to
nmrg.
O
Hopefully,
at
some
point
in
time
we
can
talk
about
a
second
pull
over
of
that
stuff
into
ietf,
whether
anima
or
another
working
group,
and
then,
as
far
as
where
is
adaptation,
so
we
see
a
huge
interest
in
the
bootstrap
stuff
which
is
proliferating
through
you
know
many
working
groups
and
unfortunately,
also
a
humongous
number
of
small
tiny
variation,
because
some
industry
wants
to
have
yet
another
encoding
of
pretty
much
the
same
functionality.
So
we
have
follow-up
documents
in
different
working
groups
for
variation
of
the
stuff.
O
Well,
I
guess
there
can
never
be
enough
standards,
the
acp
stuff,
this
automatically
build
connectivity
very
little
traction
in
the
industry.
Yet
so
obviously
you
know
if
you
have
any
interest
in
that
contact
me.
That's
my.
O
So
this
is
the
landscape.
I
wouldn't
even
dare
to
start
talking
about.
You
know
what
is
where
in
which
working
group,
but
michael
richardson
has
done
a
good
job
to
creating
the
map
of
you,
know
the
the
bootstrap
landscape,
and
there
is
even
a
draft
and
github
for
that.
O
So
if
we
get
back
to
it
and
if
you're
interested
in
automating
any
parts
of
the
network,
I'd
really
love
you
to
consider
that
the
full,
a
I
or
even
just
very
simple
subset
of
that
are
really
good
basis
for
further
automation.
Right.
We
given
you,
know
any
type
of
agents.
O
Strange
names
called
asa
but
consider
that
as,
for
example,
simple
scripts
right
and
I
think,
we've
seen
a
lot
of
problems
in
automating,
especially
security,
whether
it
is
the
use
of
actual
certificates
in
any
end,
to
end
like
really
certificates,
without
just
user
name
and
passwords
for
oem
operations
into
network
devices.
You
just
need
the
bootstrap
across
the
network,
some
simple
form
of
renewal
of
the
certificates
and
you
have
much
better
than
username
password
and
if
you
then
look
into
a
lot
of
security
and
protocols
right.
O
So
there
are
a
lot
of
protocols
that
have
secure
options
or
not
have
them,
and
the
whole
ani
provides
a
lot
of
options
to
help
with.
If
you
go
through
the
acp,
you
have
automated
security
on
top
of
the
protocol,
because
everything
is
encapsulated
into
ipsec,
but
you
can
of
course,
also
automatically
provision
the
certificates-
and
it's
very
easy-
and
we've
done
that
in
the
past,
to
write
simple
scripts
in
tickle
or
python
to
basically
automate
even
new
signaling,
for
you
know,
distributing
keys
between
neighbors
that
you
can
derive.
O
So
it
should
really
be
a
good
programmable
platform
built
from
few
core
software
components
to
start
automating.
Now,
security
has
been
our
favorite
thing.
Obviously
I
think
there
are
a
lot
more
self
automation
scripts
that
I've
seen
over
the
decades
and
that
I
think,
would
still
be
of
interest
to
right
and
get
away
from
having
you
know:
humongously
big,
complex,
centralized,
sdn
controllers
alone.
O
O
So
if
networks
were
cars
on
the
left
hand,
side
is
our
interpretation
of
what
self-driving
networks
today
are
right,
so
somebody
you
know,
or
some
sdn
controller,
orchestrator
or
so
is
really
driving
a
really
really
stupid
network,
nothing
against
kids,
sorry
I
didn't
mean
to,
but
I
think
you
get
the
point
that
with
enema
we
hopefully
are
creating
the
infrastructure
to
really
enable
really
self-driving
network
cells
that
come
close
to
self-driving
cars
wherever
that's
desirable
and
that's
it.
Thank
you
very
much.
Please
engage
with
us
right.
We've
got
a
mailing
list.
F
Thanks
jenny,
so
thank
you
for
that
was
very
useful
and
I
invite
people
again
to
to
join
anima
if
they
for
the
next
itf.
F
Otherwise,
I
think
we're
at
the
top
of
the
hour,
and
we
can
say
thank
you
for
everyone,
but
upset
with
g
and
ops
area
and
see
you
possibly
not
in
person,
but
see
the
next
virtual
idea
if
I
suspect
112..