►
From YouTube: IETF105-RTGWG-20190723-1000
Description
RTGWG meeting session at IETF105
2019/07/23 1000
https://datatracker.ietf.org/meeting/105/proceedings/
B
B
Okay,
so
there
was
adoption
called
in
version
7
of
the
model.
We
got
some
reasonable
set
of
comments.
We
had
replied
to
some
of
the
comments
beyond
sense.
Some
of
the
comments
we
clarified
some
of
the
comments,
rest
of
the
comments
we
were
able
to
incorporate
and
based
on
that,
we
were
able
to
publish,
wasn't
n
of
the
model
next
slide.
Thank
you.
B
So,
basically,
you
know
some
of
the
comments
would
had
been
regarding
the
references
there
were
some
missing
references.
There
were
some
incorrect
references,
so,
for
example,
we
had
a
reference
for
yang
1.1
into
the
draft.
We
added
reference
for
the
imported
modules,
also
some
of
the
yang
nodes.
We
provided
specific
reference
from
the
work
which
had
been
done
in
the
past
in
the
various
RFC's,
for
example,
for
pali,
sir
one
rate
three
color
and
two
rate
three
color.
We
were
able
to
provide
reference
for
RFC,
two,
six,
nine,
seven
and
two
six,
nine,
eight.
B
B
B
B
Also,
you
know
when
we
were
going
through
when
we
were
reviewing
the
draft
ourselves.
We
figured
out
that
in
the
sir
model,
we
need
to
provide
further
restriction
into
in
what
cases
we
will
be
able
to
configure
difícil
module
and
that
will
be
based
on
the
divs
or
policy
types.
So
accordingly,
we
added
a
when
statement
for
it.
B
So,
to
summarize
the
the
draft
you
know
we
have
created
a
basic
framework
of
Q
s
as
an
classifier
module.
We
have
action,
module
policy,
module
and
target
module,
and
these
are
the
base
modules
based
on
these
base
modules.
We
have
created
set
of
derived
modules,
which
are
difícil
module
and
this'll
include
match
and
action
related
to
yourself,
but
it
takes
those
matches
an
action
and
combine
them,
create
the
base
framework
of
policy
and
classifier
and
create
a
policy
out
of
it.
B
Similarly,
we
have
created
derived
module
of
queueing
policy
which
actually
work
on
the
metadata
information
and
and
then
we
are
able
to
configure
the
queuing
parameters.
Similarly,
for
excuse
me
schedulers,
you
know
we
have
provided
the
actions
for
scheduling.
Also,
you
know
that
reference
II
have
been
provided
from
the
PS
RFC's.
For
that
also,
this
model
is
very,
very
adaptable
to
any
vendor
requirements
and
any
vendor,
because
the
constructs
are
so
different
across
vendors
fork
us
so
they
may
be
able
to.
B
B
Ok
at
the
next
step,
we
expect
any
further
comment.
We
we
will
be
looking
for
any
further
comment
from
the
from
this
community.
Also
vendor
prototyping
is
in
progress
in
some
cases.
Also,
you
know
to
be
realistic
unless,
until
this
is
adopted
and
become
a
working
group,
duct
document
vendor
will
not
invest
that
much
to
actually
implement
the
draft.
So
once
it
become
a
working
document,
then
vendor
will
go
ahead
and
implement
it
out.
B
C
D
D
That,
because
there
was
a
previous
version
of
that
document,
that
was
in
then
we
started
into
it
was
restarted
in
2014
because
or
even
beginning
of
2014,
because
I
was
one
of
the
authors
on
that
right.
You
were
part
of
the
doctor,
yes
XO
and
we
are
still
trying
to
issue
the
first
version
of
that
document.
E
D
The
specific
point
here
is
that
you're
trying
to
match
on
all
the
functionalities
instead
of
saying
an
obstructing
saying
these
are
the
basics.
However,
how
curious
is
working?
These
are
the
basic
elements
and
then
different
characteristics
of
those
elements
came
in
and
specifies
afterwards,
but
right
now
we
still
don't
have
a
common
syntax.
How
to
specifies
you
know
POS
in
the
systems.
B
Operational
excellence
in
many
cases,
but
also
it
allows
many
vendors
to
implement
in
a
couple
of
ways
the
same
configuration.
In
fact,
some
of
the
men
I
do
allow
the
configuration
that,
in
a
multiple
way,
to
to
ease
the
operational
excellence,
so
yeah
means
may
I'm
missing.
The
point
here
means
what
he
does:
pollution.
B
F
So
I
was
really
this
hasn't
been
adopted.
Yet
from
my
point
of
view,
I
think
fairly
obvious.
The
ITF
does
want
to
do
a
qsr
model.
We've
been
working
this
for
a
long
time
and
it's
changing
I'm,
not
sure
we
need
perfection
here.
We
need
to
get
something
out
and
shipped
and
we
can
extend
over
time.
So
I
I'd
be
very
keen
to
see
this.
F
The
doctor,
as
it
is,
there's
a
lot
of
time
spent
on
it
and
then
refine
it
a
bit
as
as
we
go,
but
try
and
actually
gets
out
the
door,
because
you've
got
lots
of
other
yang
models
out
there,
and
we
people
want
to
use
these
or
or
should
be
wanted
to
use
them.
So
we
want
to
try
and
push
this
along.
If
you
can.
Okay.
B
So
yeah
means
that
the
model
has
been
stable
for
some
time
now.
It
just
said
you
know,
be
helping
the
question
for
more
and
what
comment
so
that
we
can
incorporate
those.
There
was
a
versus
seven.
There
was
an
option
called.
We
got
some
comments
regarding
the
you
know,
mainly
regarding
the
format
and
some
of
the
correction
to
be
done
in
the
drops
which
we
have
done,
but
other
than
that
yeah.
The
model
has
been
stable
for
some
time.
G
Defense
former
range
I
have
a
senior
event
has
then
had
about
not
the
complexity,
but
we
develop
details
in
terms
of
scheduling
which
is
in
currently
in
the
document,
because,
especially
the
scheduling
is
something
which
is
really
oddly
dependent
and
you
may
not
be
able
to
do
exactly
the
same
thing
and
express
it
at
least
in
the
same
way,
on
one
Hardware
of
yoga.
So
I'm
really
happy
to
see
that
you
have
some
vendors
that
are
trying
to
prototype
this
model,
and
I
will
be
really
happy
to
see
the
outcomes
of
this
prototyping.
B
G
H
Ceiling
the
masses
of
systems
I
in
defense
of
this
I
haven't
reviewed
the
latest
version,
but
I
did
a
review.
What
a
couple
years
at
least
year-and-a-half
ago
or
something
of
this
model,
and
it's
it's
not
the
one
of
the
real
problems
is,
is
chip
designers
have
had
no
motivation
to
have
any
common
analogy
and
the
in
their
QoS
the
way
it's
attached
and
there's,
and
at
one
time,
I
worked
on
trying
to
unify
the
CLI.
B
Means
it's
not
easy
prominent
assault,
but
over
a
period
of
time
we
have
debated
a
lot.
We
have
come
up
with
the
model
which
actually
works
for
all,
and
we
see
that
all
the
vendors
will
be
able
to
adopt
the
way
we
have
design
it
right
now
and
so
I'm
pretty
confident
that
any
vendor
will
be
able
to
use
this
model
to
to
configure
their
device.
B
Even
though
you
know
for
all
the
you
know,
even
for
a
single
vendor,
there
will
be
differences
for
qsr
based
on
the
platforms
in
all,
but
they
still,
you
know,
provide
that
common
CLI
across
it,
and
so
we
have
merged
all
them
together
and
I.
Think
all
the
vendors
should
be
able
to
probably
a
pretty
confident
for
that.
So.
E
I
E
Other
feedback,
so
I
mean
we're
planning
to
adopt
this
we've
gotten
a
lot
of
feedback
that
this
approach
possibly
isn't
as
useful
as
another
approach,
but
does
anyone
actually
have
an
objection
to
going
ahead,
and
you
know
adopting
this
as
a
working
group
document
polishing
it
off
and
publishing
it?
As
you
know,
this
isn't
a
working
group
last
call,
but
in
general
our
intention
would
be
to
adopt
it
finish
it
off,
publish
it.
Does
that
produce
any
damage?
Any
objections
to
that.
D
E
A
D
There
are
some
changes
coming
in
the
networking
that
will
require
some
significantly
different
and
approach
to
how
we
are
doing
network
automation,
but
we
are
still
using
some
of,
in
my
opinion,
concepts
that
are
where
too
much
device
related
and
not
much
service
related.
Why
I'm
saying
this?
We
are
seeing
a
large
increase
in
routing
endpoints
in
networks.
Today,
large
networks
will
have
six
seven
thousand
routing
points.
D
We
are
talking
to
service
providers
that
are
planning
to
increase
their
networks
to
120,
plus
thousand
endpoints
AT&T,
publicly
announced
they're,
adding
60,000
routing
points
in
their
in
their
network
and
how
we
are
doing
network
management
today,
I,
don't
see
how
we
can
effect.
It
will
scale
that,
because
the
traditional
network
management,
it
is
very
much
focused
on
a
single
device,
you
are
building
up
from
multiple
device
configurations.
You're,
building
up
a
service,
the
larger
the
network
is
the
harder
it
will.
It
will
be.
It
will
be
harder
to
do
that
as
well.
D
It
will,
you
know,
take
longer
to
provision
new
services
across
significantly
larger
network
than
what
we
have
today.
We
are
trying
to
move
away
from
a
human
interface
to
a
machine
interface,
but
some
of
the
content
that
is
being
provided
through
the
human
interface.
We
are
just
translating
it
directly
into
a
machine
interface
and
we
are
missing
some
abstractions.
We
are
trying
to
do
that
with
the
models,
but
still
models
are
too
much.
D
I
would
just
point
out
to
the
QoS,
which,
in
my
opinion,
is
to
be
the
reason
I'm
pointing
it
out,
because
it
was
the
last
one
mentioned
just
before
Mike
before
my
presentation,
but
it
is
instead
of
trying
to
abstract
actions
and
saying
this
is
the
abstract
way
how
we
can
do
it
and
it
can
be
implemented
across
multiple
different
architectures.
We
are
trying
to
cram
all
the
architectures
into
one
model
and
then
we
ending
up
with
something
pretty
complex.
That
is
not
helping
us
moving
forward
as
well.
D
We
are
not
improving
the
programmability,
the
programmable
capabilities
of
the
network,
that
we
are
trying
to
do.
I
put
in
here.
A
couple
of
you
know.
Essentially,
these
are
descriptions,
different
lecture
definitions,
but
the
key
thing
is
that
in
the
automation,
with
minimal
or
no
human
intervention,
there
are
a
few
private
enterprise
operators
that
are
very
good
at
doing
this,
but
many
people
of
them
their
self,
relying
on
the
CLI
and
on
the
human
operators.
D
The
idea
is
that
we
have
to
if
you
want
really
to
scale
those
networks
and
provide
those
new
services
we
have
to
rethink.
You
know
some
of
the
management
how
it's
done.
Even
you
know
some
of
the
tools,
because
the
idea
is
look,
you
have
to
do
it
from
a
service
perspective
and
from
a
service
going
down,
essentially
turn
it
upside
down.
This
brings
us
to
the
API
management.
You
know
approach
and
we
have
today
some
tools
and
protocols
that
are
there.
Some
of
them
are
developed
within
the
ITF
community.
D
Some
of
them
are
being
done
by
the
vendors.
Some
of
them
are
being
done
by
the
consortiums
plus
open
source
they're.
All
helping
us
rethink
how
we
are
doing
the
automation
in
seeing
how
we
are.
You
know
how
we
can
move
forward
in
order
to
address
the
new
requirements,
but
some
of
us
also
have
to
switch
the
net
engineers.
We
have
to
switch
our
thinking
and
start
thinking
more
in
doing
programs.
What
I
will
show
this
later?
There
are
no
conditional
loops
in
the
configurational
data
that
we
are
doing.
D
It
will
be
very
nice
to
see.
Oh,
how
can
we
add
unit
tests
for
certain
functionalities
as
a
network
engineer-
and
this
is
this-
is
one
part
that
we
have
to
start
thinking
more
in
trying
to
adopt
more
software
development
techniques
instead
of
what
we
were
doing
through
different
vendors
provisioning
processes
that
were
mainly
saying.
Oh,
here's,
the
business
logic
that
want
to
be
executed
on
the
device,
but
I
cannot
put
any
conditional
statements
inside
that
provisioning
information
with
the
API
definition
requirements.
D
We
are
defining
the
and
what
we
are
doing
here
at
the
ITF
with
the
data
models
we
are
essentially
defining
and
we
are,
we
are
describing
different
levels
of
functionalities
that
are
available
in
the
devices
as
well.
In
the
networks
we
are
talking
about.
What
operations
can
we
do?
We
are
deciding
how
we
can.
D
You
know,
send
the
data
back
and
forth
that
we
can
understand
it
that
we
have
standardized
it
because
most
of
those
things
which
are
well
known
within
the
software
development
in
the
networking
until
where
recently
was
very
on
its
own
and
our
best
tool
was
tickle
and
expect,
and
we
all
know
the
paint's
that
was
causing
us-
that
the
data
models
there
are,
you
know
so
again,
there
are
vendor
models.
There
are
some
community
models,
I'm
just
building.
D
You
know
going
for
all
of
that,
just
giving
you
a
brief
overview,
but
some
of
the
models
I'm
saying
we
have
to
do.
We
have
to
provide
better
abstractions.
If
we
we
can
say
there
are
common
functionalities
that
every
single
vendor
is
using,
but
how
those
functionalities
are
implemented
should
be
abstracted
away.
We
should
we
should
not
continue
pushing
up
those
implementation
details
into
the
higher
levels
throughout
the
data
models.
D
D
D
Is
you
know
it's
a
nice
thing
to
hear
because,
if
they're
providing
some
good
mechanisms,
they're
a
good
framework,
on
the
other
hand,
I'm
also
hearing
some
concerns
that
some
that
the
framework
is
not
sufficient
enough
for
what
some
other
operators
network
operators
would
like
to
do.
So
if
we
are
looking
at
B
in
network
device
configuration
and
management
api's
is
we
have
device
resource
and
network
functions
that
should
be
used
for
high
level
data
models?
D
If,
in
the
net
mod
working
group
we're
trying
to
define,
how
can
we
build
up
packages
that
will
provide
the
abstractions
for
different
functionalities
and
systems
that
you
want
to
build
in
order
to
ease
the
management
and
provide
common
schemas
to
the
higher
level
ones?
The
point
there
is
the
young
data
model
is
in
the
young.
Language
is
a
common.
It's
a
common
language
that
is
adopted.
D
Some
people
prefer
protobuf,
/
yang,
but
majority
of
majority
of
the
industry
settling
down
on
yang
the
bad
part
of
that
thing
is
it's
too
much
tight
to
two
out
of
three
available
transport
protocols
that
are
in
use
widely
today
and
us
working
on
trying
to
say
hey.
There
is
another
framework
that
is
being
de
facto
standard,
but
yang
is
a
standard
and
those
things
are
incompatible
is
a
problem
that
needs
to
be
solving
that
we
should.
D
You
know,
start
thinking
about
that,
because
the
more
we
will
grow
apart,
the
harder
it
will
be
to
come
together
and
we
will
run
again
into
a
management
problem
forgot
to
mention
at
the
beginning.
There
is
a
I
heard
it
from
several
people
that
the
golden
standard
for
network
management
was
the
Wellfleet
frame
relay
network
management.
Suite
and
many
operators
are
remembering
how
nicely
it
was
done.
They
saying
if
you
can
provide
us
something
like
that.
D
This
is
a
example
of
a
open,
config
device
model
and
the
reason
why
I'm
you
know
putting
it
out.
This
is
done
by
a
consortium
and
they
put
in
functionalities
in
there
that
they
really
need
it.
There
are
things
that
could
be.
You
know
extended.
There
are
things
in
there
that
are,
you,
know
missing,
but
there
are
also
things
that
are
there.
That
could
be
used
that
my
main
my
main
issue,
there
is
it's
a
device
model.
Where
is
the?
Where
is
the
next
one?
The
service
models?
D
D
If
you
look
again
into
the
open,
config
G
RPC
interfaces
and
I'm
going
here
a
little
bit
more
Ruggieri's
interfaces.
Since
last
time,
they're
presented
at
the
ITF,
there
has
been
an
evolution
and
some
of
the
concept
that
did
that
we
did
in
the
ITF
and
drop
they
picked
them
up
and
or
they
came
with
their
own
ideas
that
were
similar
to
ours,
ideas
and
expanded.
That
one
of
the
interesting
interfaces
that
they
added
is
the
G
ribeye.
D
This
is
you
know
if
some
people
might
remember
the
I
to
RS
the
original
ideas
of
the
ITRs
and
JIRA
by
have
certain
things
in
common.
But
then
the
very
interesting
part
is
how
the
integrating
with
the
G
NMR
and
getting
the
information
of
your
body
from
informational
state
they
can
use
for
certain.
You
know
other
operations,
and
this
is
a
nice
example
how
they
were
building
on
top
of
the
abstractions
and
putting
you
know
into
a
pretty.
D
Common
frame
pretty
foundational
framework
that
works
well,
if
you
want
to
build
different
applications
on
top
of
that
so
quickly,
why?
Like
G
nmi
it
you
essentially
capabilities
so
you're
getting
you
know,
okay,
give
me
the
the
capabilities.
What
are
there?
I
can
get
and
set
on
them,
and
I
can
subscribe
and
I
like
the
way
how
their
subscription
stream
works.
I.
Think
that
what
some
of
our
subscription
frameworks
that
we
have
available
today
have
things
missing.
D
I
also,
don't
think
they
I
think
they
are
too
heavy
for
the
devices
and
we
should
try
to
see
what
can
be
changed
and
what
can
be
adapted
from
some
of
the
other
frameworks,
because
one
thing
what
I
really
love
about
the
jean-mi
is
for
the
telemetry
and
you
can
decide.
Okay,
here's
my
you
know
I
want
to
subscribe,
and
this
is
the
path
to
the
path
element
for
which
data
information
I
want
to
get.
This
is
interesting
because
you
can
create
telemetry.
D
You
can
create
data
collection
subscriptions
for
a
cert
for
specific
service
and
get
data
for
that
service.
That
means,
when
I
write
an
application
that
provisions
the
service
I,
can
subscribe
only
to
that
service,
relevant
information
and
use
that,
as
certain
event
triggers
that
can
provide
the
corrective
actions.
That
can
be
the
input
for
my
conditional
statements
in
my
service
provisioning
in
in
in
my
service
provisioning
logic.
D
So
do
we
have
the
right
tools
today?
Yes,
and
no,
we
have
the
right
ideas.
Some
of
our
implementations
could
be
better.
You
know
I'm
guilty
as
charged
I've
been
working
on
that
for
years,
and
you
know
we
are
learning
as
we
are
moving
forward,
but
getting
I
will
make
a
call
out
that
US
vendors
are
not
the
best
people
to
talk
to
and
rely
on
us
on
how
to
do
operations
I've
been
a
vendor.
D
My
whole
life,
so
you
know
this
is
the
one
part
that,
but
we
also
know
how
to
do
certain
abstractions,
and
we
should
do
that.
Forget
the
implementation
details,
focus
on
the
functionalities
and
saying
this
is
what
we
can
do
as
a
vendor.
The
is
what
we
can
get
input
from
the
service.
You
know
from
the
action
from
the
network
operators
and
use
the
input
from
the
network
operators
to
refine
the
network
functions
that
we
are
providing
to
them
to
build
the
network
services.
D
The
service
Wallace
has
mentioned.
You
know
they
are
two
of
them
open,
config,
I
will
say,
the
only
define
you
know,
model
set
the
device
level
and
growing
the
network
just
based
on
the
device
level
will
not
scale.
We
will
run
into
many
problems.
If
you
will.
You
know
when
we
see
like
a
10
or
20
X
increase
in
size
of
our
networks.
The
way
how
we
are
managing.
You
know
that
today
and
the
many
network
operators
have
their
own
proprietary
tools
that
they
are
creating
in
order.
D
You
know
to
manage
the
services
this,
how
they
are
managing
this,
how
they
manage
network,
how
they
are
creating
the
value,
and
this
is
how
they
are
at
the
end,
making
money
making
profits
if
we
can
help
them
by
providing
them
better
tools
for
them
to
create
the
higher.
You
know
values
that
will,
you
know,
be
also
better
for
our
industry
in
general.
So
the
question
is:
could
we
use
any
reasonable
pattern
to
design
and
automate
networking
service?
D
There's
something
that
we
should
be
asking
us
when
we
are
working
on
any
of
the
standards
that
we
are
working
on?
So
we
try
to
classify
certain
things.
You
know
in
the
ITF,
but
yesterday,
during
the
first
working
group
session,
the
presentation
from
Reza
and
Nokia,
he
was
mainly
talking
about
translation
of
a
business
service
into
lower
layers.
D
One
of
them
is
a
business
user
I
like
to
say
this
is
our
good
old
non
PLM.
Here
they
have
to
define
the
use,
cases
tell
us,
you
know
what
use
cases
have
to
be
defined
and
the
network
operator
knows
about
troubleshooting
operations
provisioning,
and
then
we
have
a
network
developer
when
they
talk
to
some
of
the
VARs
and
s
I--'s.
Today,
they're
saying
we
have
2000
CC,
II's
and
1800
J
and
C
is
great,
but
those
guys
cannot
really.
They
are
good
as
a
network
developers.
D
You
know
the
question
is
how
many
of
them
are
as
a
network
operators
and
how
many
of
them
will
be
really
good
at
translating
the
business
user
requirements
into
you
know
into
the
lower
layers.
So
if
you
look
at
the
traditional
network
service
orchestration
approach,
you
still
have
a
network
operator
that
is
following
the
alarms
and
then
executing
certain
predetermined
actions.
When
I
was
working
for
a
large
vendor
at
an
SDK
one
of
the
biggest
applications
they
were
using
for
the
SDK
was
preset
commands
that
the
network
operator
was
executing
based
on
the
alarms.
D
They
were
creating
custom
CLI
for
a
different
level
of
an
operator,
I'm
asking.
Why
do
you
need
that
operator
in
there
to
execute
on
that?
Create
a
loop
control
loop
and
let
that
automate
that
and
let
that
operator
do
something
more
valuable,
but
our
tools
are
not
there
yet,
because
if
we
want
to
build
an
ensign
application,
the
natural
developer
has
to
listen
to
the
business
guide.
They
have
to
look
at
the
operators
guys
and
say
this
is
my
business.
D
Technical
and
operational
requirements
and
I
will
put
that
together
into
a
single
network
application
I
will
be
using
the
the
the
well-known
procedures
of
software
development
where
I
can
unit
test
my
functions.
I
can
unit
test
my
service
I
can
do
you
know
different
types
of
testing
functional
testing
on
that
I
can
run
that
application
multiple
times.
I
will
have
no
the
predictable
results.
When
we
have
been
up
putting
in
different
configurations,
we
are
still
trying
to
figure
out
what
is
the
state.
D
D
The
first
part
is
that
we
have
to
saying
we
are
having
a
set
of
api's
from
our
devices
that
are
being
you
know,
streamed
upstream
data
being
from
a
network
service
instance
being
pushed
down
and
they're
being,
you
know,
essentially
streamed
up
for
the
monitoring
you
know
of
the
device
resources.
This
would
be
the
step
one
when
we
are
trying
to
add
conditions
on
the
network
to
be
tested
and
verified
where
our
service
logic
based
is
checking
on
the
function
that
we
have
invoked.
D
D
That
is
done
by
a
vendor,
and
there
are
certain
things
that
I
would
like
to
see
in
that
framework
to
be
expanded
and
extended,
maybe
even
standardized,
because
this
would
be
very
helpful
and
that
we
can
have
for
the
configuration
actions
as
well.
For
the
monitoring
actions,
a
single
API.
We
can
have
a
single
common
data
model
for
both
of
them,
which
would
makes
the
something
because
one
of
our
biggest
promise
realization
between
the
operational
model
and
the
configurational
model
and
trying
to
figure
out
what
does
this
operational
model
mean
in
configurational
terms?
D
This
should
you
know,
be
able
to
simplify
the
actions
that
we
are
trying
to
do
and
then,
as
the
last
iteration
would
be,
that,
instead
of
having
enough
separate
configuration
and
operational
parts,
we
will
just
have
a
network
service
instance.
That
would
be
using
data
lying
SDK
and
instead
of
being
an
expert
in
CLI.
D
You
would
say,
oh
this
in
your
library
that
they
have
to
learn
in
order
to
be
able
to
provision
this
new
service
and
writing
a
new
application
would
be
network
independent,
as
well
as
a
vendor
independent,
because
you're
talking
about
the
abstractions
and
saying
look
for
me
to
do
a
filter
have
to
have
a
match
condition.
I
have
to
have
a
action
on
top
of
that,
and
I
will
be
learning
about
different
types
of
actions
and
match
and
actual
conditions
I
have
available.
D
In
order
to
execute
on
that,
I
can
find
out
from
the
network
what
is
available?
What
is
not
available
are
the
resources.
Are
there
are
no
resources
and
based
on
that,
make
a
decision
can
something
like
that
be
deployed
across
the
service
topology
or
not
these
days?
Why
do
we
still
have
to
use
rollback
and
then
question
is
what
is
the
state
across
my
network
after
I
did
the
rollback,
and
that
would
be
the
end
of
the
application,
the
presentation
and,
if
you
have
any
questions,
I
welcome.
J
D
Will
welcome
getting
so
I
will
go
back
to
QoS
and
Akko
to
have
it
better,
abstract,
it'd,
be
less
implementation.
Detail
so
provide
better
abstractions
for
all
the
yang
models
get
in
try
to
reach
out,
because
my
big
war
is
telemetry
and
GN.
Mi
is
a
really
good
telemetry
framework.
What
we
are
doing
here
needs
a
lot
of
you
know,
work
and
I.
D
Don't
think
that
it
can
scale
to
what
we
are
to
what
we
need
and
try
to
re-engage
the
GN
mi
in
order
in
together
that
so,
but
then
also
I
would
ask
that
vendor
to
be
sometimes
a
little
bit
more
open
to
our
input
as
well.
What
we
are
proposing
back,
because
we
also
have
our
own
reasons
why
we
need
certain
things
that
my
different
you
know
from
defender,
so
my
I
will
say
again:
we
need
better
abstractions
for
devices
for,
therefore,
the
network
functions
devices,
network
functions
and
a
certain
extent.
First
for
network
services.
F
So
I
like
to
presentations,
good
and
I,
think
that
I
agree.
That
would
be
useful
to
have
an
official
draft
documenting
how
to
use
some
of
this
and
do
the
lifecycle
management
through
yang
unless
they
have
that
be
greatly
beneficial
and
I
have
an
interested
in
that's
what
suffers
well.
One
question
on
this
particular
is:
what
do
you
see
the
s?
What
do
you
see
the
API
has
between
the
operators
and
the
services?
Is
that
something
that's
written
in
yang,
or
is
that
a
programmatic
interface
in
some
particular
language,
its.
D
The
you
have
frameworks
that
can
once
you
write,
the
definition
can
give
you
a
library
in
many
different
languages
and
it's
a
question
now
how
you
can
get
the
data
model
be
translated
into
the
language,
so
I
will
not
go
into
the
specific
different
frameworks
that
are
providing
you
their
functionality,
but
that
should
you
know
there
are
frameworks
out
there
that
can
be
used
and
again
it
would
be
easier.
I
will
come
down
to
that.
D
If
yang
would
be
a
little
bit
more
independent
to
be
able
to
write
some
of
those
translation
between
Yang
and
some
of
the
other
frameworks
without
having
the
other
transfer
protocol
restrictions,
what
we
have,
we
could,
you
know,
work
from
there,
so
this
is
another
part
that
we
could.
You
know
we
work
in
as
a
community,
because
yang
is
being
adopted
and
it's
a
useful
tool
that
we
can
use,
but
we
have
to
evolve.
I
mean
they
also
I
would
like
to
see
more
about
yang
next.
What
he
could
do.
D
D
F
K
Listen
Leon
from
sallee
Oh
from
North
American.
We
support
different
defense.
I
have
two
questions.
One
question
is
aware
of
northbound
interface
in
this
architecture,
and
the
second
question
is
regarding
this
streaming
event:
bass.
So
he's
past
you
are
talking
about
pops
up,
which
is
required.
Communication
for
telemetry
may
be
fine,
but
for
the
per
inning,
how
you
guarantee
you
know
what
your
print
will
be
immediately.
You
know
being
committed.
It's
working,
your
pops
Avenida
synchronize
not
necessary.
What
do
you
intend
to
present
well
beeper
yeah,
so
there
may
be
delayed
okay.
D
It
has
been
provisioned
across
the
service
that
you
desire,
yeah
so
on
the
northbound
and
solve
an
interface.
This
is
relative.
You
know
where
you're
putting
in
in
this
case
yeah
southbound
I
should
have
put
it
there,
an
API
and
say
this
is
my
API
to
the
devices
and
think
about
devices
are
the
physical
layer
that
are
doing
the
packet
forwarding?
Then
you
have
the
device
management
platform
is
where
you
are
abstracting
the
devices
in
a
set
of
functions
and
the
resources
that
they
are
using
as
well.
D
You
are
providing
you
know
the
the
messaging,
the
message,
bus
that
has
the
provisioning
and
the
operational
data
that
you
can
subscribe
to,
that
you
can,
you
know,
collect
and
send
the
data
to
so
you
have
here
multiple
northbound
and
solve
on
interfaces.
I
am
NOT,
hung
up
and
very
much
on
that.
What
framework
it
is
I
just
want
to
define
what
are
those
you
know,
data
models,
what
are
the
schemas
for
those
interfaces
for
the
what
the
actual
implementation
will
it
be
on
that
part?
D
What
I
meant
does
this?
You
know
operational
model
really
translates
correctly
into
my
provisioning
model
and
vice
versa.
So
this
is
one
of
the
problems
that
we
have
today
when
we
are
doing
that.
If
you
can
remove
some
of
those
abstractions
in
between,
then
you
can
start
doing
unit
testing
and
making
sure
through
others.
You
can
then
decide
what
do
it
does
it
have
to
be
an
end
function
or
it
has
to
be
an
end
function
or
how
will
you
know
combined
of
each
of
those
unit,
tested
you're
they're
going
across
the
network?
D
K
In
the
synchronize,
the
communication
busier,
you
send
the
request,
your
autonomy
that
come
back
e-reading
effect
few
seconds,
but
for
us
here
is
the
bus.
You
send
something
with
what
you
respond.
May
come
back
our
later,
so
you
either
no
guarantee
you
will
miss.
So
it's
bad,
that's
a
big
difference.
So
for
telemetry
it
probably
is
fine
but
hold.
D
K
It's
super
busy,
like
you,
can
write
a
right
Reggie
of
software
right
for
simple
right.
Synchronized
communication
means
you
send
the
request
you
respond.
I'll
come
back
within
second
expected
is
come
back
with
our
short
time
window,
but
we
will
give
you
utilize.
The
search
path,
which
is
mr.,
is
a
pop
subscription
model.
This
means
you
can
be
sure
it's
a
synchronized.
You
send
a
request.
You
respond.
We
come
back
hours
later,
so
you
now
guard
he'll
come
back
within
a
few
seconds,
so.
D
These
days,
sometimes
to
get
the
wire
that
get
the
state
on
the
wire
takes
20
minutes.
So
a
few
seconds
I
will
see
that
there's
a
quite
a
good
of
improvement.
I
mean
I.
If
I
find
this
with
your
question
is
today
we
have
a
problem
that
you
know
different
devices
take
times
in
order
to
get
a
note
on
the
on
the
same,
to
get
the
same
provisioning
information,
my
network.
K
L
L
M
Chief
on
your
from
that
of
all
the
networks,
so
for
the
scenario
you
described
it's
pretty
much
like
notification,
it's
a
other
kind
of
notification,
not
a
telemetry.
So
for
that
kind
of
notification,
other
common
management
protocols
are
they
support
that
nikon
has
notification
and
there.
So
you
can
get
the
nod
of
cleaner.
That
way,.
L
Two
questions
for
clarifications:
the
first
one
he
songs
sliced.
You
have
two
platforms
and
both
of
them
are
marked
as
distributed
here
so
from
the
service
one.
We
have
multiple
instance
and-
and
it
looks
like
a
distributive
system,
but
the
bottom
one.
We
call
it
the
device
management
system
and
it
looks
like
it
should
be.
Centralized
reminder
explain
why
you
think
this
is
distributed
system.
D
Devices
in
general
are
will
be
so
so
and
then
like.
If
I
want
to
create
a
single
centralized
management
platform.
The
question
is
how
to
scale
it,
and
if
the
idea
there
is
that
you
want
to
keep
up
certain
latency
requirements
for
the
certain
devices
that
you're
abstracting
in
the
geographical
area,
you
could
be
using
today's
technology.
Can
bull
build
a
single
device
management
platform
for
the
whole
us
for
the
whole
North
America.
But
how
much
does
it
make
sense
because
of
the
latency
that
you
will
be
seeing
in
order
to
communicate
those
devices
collected?
L
L
L
In
this
presentation,
you
talk
about
a
lot
about
the
network
service
and,
if
I
understand,
the
crackly
low
service
is
something
that
called
exists
in
the
service
management
platform
and
something
beyond
it.
For
the
user,
plain
I
also
notice
that
in
this
slide
and
some
other
previous
slides,
the
term
service
is
missed
in
the
kind
of
device
management
platform.
So
are
you
implying?
Are
you
implying
that
the
service
say
the
management
platform
is,
is
not
aware
of
this
network
service
or.
D
So
the
device
management
platform
and
the
service
platforms
are
different
and
I
was
talking
to
you
more
about
network
management
than
specific
services.
I
just
see
it
as
build
ups
on
one
on
top
of
the
other,
because
the
network
operator
for
them
services
are
revenue
generating
and
the
control
plane.
The
physical
layer
is
a
cost
center,
so
they
would
be
focused
mainly
on
services
how
they
can
provision
the
services
faster
with
more
ease
it
or
to
satisfy
the
customer
demands
in
making
sure
that
the
underlying
operational
infrastructure
is
being
managed
most
efficiently.
E
G
From
Orange
I
have
a
very,
very
open
question
and
I
don't
have
any
strong
opinion
about
it,
let's
focus
in
10
or
20
years.
Okay,
abstraction
are
really
something
which
is
required,
especially
from
provisioning,
because
it
will
speed
up
how
we
are
creating
services
and
so
on.
But
now,
if
we
are
focusing
on
really
network
operations,
don't
you
think
that
at
least
on
the
operator
side,
people
may
lose
some
skills
and
will
not
understand
anymore
how
things
are
really
working
if
they
are
only
manipulating
abstraction.
I
can.
D
D
Same
way,
their
computer
science
are
we
losing.
You
know
that
people
are
only
learning
higher-level
languages.
There
will
be
people
who
will
want
to
understand
the
system
throughout.
That
would
like
to
understand
how
packet
pipeline
is
working,
but
I
don't
see
that
within
a
large
enterprise
like
yours,
you
will
have
five
thousand
people
that
are
really
interested
in
knowing
how
packet
pipeline
you
know,
creation
is
working.
You
might
be
interested.
You
might
really
want
to
dig
that
understand
that
there
will
be
people
who
really
would
like
to
know
that,
and
they
will
dig
into
it.
D
F
So
I
think
there's
a
there's
a
lot
of
benefits
of
being
able
to
monitor
and
get
telemetry
data
backup
of
what
the
configuration
changes
are.
So
you
can
actually
see
what
the
device
is
doing
over
that
period
of
time,
rather
than
getting
a
snapshot
after
twenty
minutes.
Is
that
now
it's
all
done,
and
in
that
in
that
window
you
don't
really
know
what
it's
doing.
So
that's
one
benefit
of
doing
this
in
a
serious
way.
F
D
A
Halla
document
dealing
with
us
pretty
much
in
daily
basis.
I
would
second,
you
have
to
be
a
synchronous
networking
if
distributed
system,
you
don't
want
to
deal
with
slurry
there's
slow
writers.
You
have
to
do
this.
We
cannot
go
into
synchronous
month
with
thousands
of
devices
you'll
be
looking
forever.
So
it's
personal
comment.
N
O
O
O
It's
a
pity
not
to
be
with
you
today,
but
fortunately
we
have
these
remote
facilities
to
to
present
so
I
think
this
or
the
idea
today
is
to
present
you,
the
layer,
3
VPN
network
model
that
will
have
lessened.
This
admitted
together
with
some
other
operators,
and
there
was
a
request
in
the
middle-
is
to
present
it
in
the
routine
working
group,
especially
a
wide.
We
need
a
new
model
and
implications
with
the
rest
of
modern-day
architectural
implications.
So
please,
if
you
move
one
more
slide:
okay,
so
we'll
I'll
go
from
Kratos.
O
O
Okay,
so,
first
of
all,
why
do
with
network
for
the
VPN?
So
we
have
already
a
layer.
Three,
a
service
model,
the
one
that
is
defined
in
RFC
899
there.
This
model
is
very
nice
and
describe
the
service
from
the
customer
perspective,
and
it
can
be
seen
the
communication
between
the
customer
and
the
network
operator.
So
we
think
this
model
is
good
for
that
a
communication,
so
this
does
not
enter
a
discussion
of
the
parameterization
of
the
net.
O
O
Okay,
so
so
what
would
be
the
the
architecture?
So
we
have
taken
the
pictures
from
the
RFC
and
map
their
different
models,
so
in
a
deadener
architecture.
What
we'll
have
is
that
the
customer
that
is
the
user
of
the
service
they
can
be-
is
a
l3
same
model
to
communicate
with
the
service
orchestration
layer
in
the
operator.
Okay,
so
that
will
have
a
working
gun
young
model
for
that
and,
as
we
said,
this
model
should
not
carry
me
anything
about
the
network
resources.
O
Even
internal
routing
details
he's
just
his
part
of
the
of
the
movie
okay.
So
then
we
have
the
what
we
call
the
service
the
network
model.
So
this
describes
the
service
as
perceived
by
the
network,
and
he
saying
that
a
business
the
input
to
automated
tools,
so
you
can
do
the
provisioning.
You
can
do
the
assurance
so
some
model
to
be
used
by
the
operators.
Okay,
so
this
work
came
as
input.
O
They
also
you
need
to
give
them
as
input
when
you
want
to
create
a
service,
especially
when
you
need
to
go
through
multiple
domains
that
preserve
some
of
these
parameters
across
different
segments.
Then
you
need
to
include
them
in
the
network
model,
but
those
days
you
don't
need
them
for
the
customer.
The
customer
can't
forget
about
them
also
a
model,
but
it
is
aimed
at
input
to
automation
tools.
It
does
not
detail
how
the
service
is
transported
and
also
does
not
detail
the
node
configuration.
O
That
is,
the
role
of
the
automated
layer
to
again
translate
this
this
model
into
device
configuration.
So
here
also,
we
are
assuming
that
the
routine
is
already
configured,
so
you
don't
need
to
do
it
in
advance
without
entering
that
in
the
in
the
model.
So
also
later,
this
orchestration
layer
will
take
care
of
how
to
present
a
service
if
it's
needed
to
set
up
new
Gillespie's
who
to
transport
it.
Ok,
he
will
take
care
of
that
occasion.
Next
slide,
please
so
also
we
can
try
to
map
the
dispatchers
in
the
ICT
and
architecture.
O
Ok,
so
we
think
there
is
where
the
model
the
model
will
will
apply,
ok
and
but
not
in
the
device
constellation
part
okay,
so
we
live
l3
SM
between
customer
homonym,
Yesi
and
internal
energy
NC
on
between
parent
and
child.
So
please
you
go
to
next
next
slide,
okay,
so
what
is
missing
in
the
in
current
service
model
is
the
reason,
while
creating
the
the
network
model.
O
So
there
are
some
Easton
areas
where
the
the
service
model
from
the
customer
perspective
is
not
sufficient
for
the
plot
of
the
service,
so
we
need
to
identify
and
to
identify
the
provider
rates
where
we
are
going
to
deploy
the
service.
Also,
we
need
data
submitters,
so
I
think
we
think
that
the
key
are
the
the
bidders
that
are
the
physical
connections
to
the
piece,
so
that
is
the
network
element
and
the
port,
but
correct
like
so.
O
We
need
the
eeriest
and
I
think
a
peon,
and
we
need
also
the
list
of
the
pillars
that
are
available
for
each
side.
Also,
we
need
to
have
cases
where
we
need
the
remote-firing
configuration.
For
example,
we
have
use
cases
in
our
operation
where
we
have
a
pseudo
wire
stitching
to
an
l3
VPN.
Also
a
we
have
cases
for
multi
domain
resource
management,
so
we
have
to
our
VPN
is
splitted
in
several
domains.
O
O
Okay,
so
I
do
it,
so
we
are
doing
a
Protestant
approach.
Okay,
so
we
try
to
preserve
as
much
as
possible
the
structure
of
the
of
the
service
model
and
just
to
remove
what
is
unnecessary
for
the
network
perspective,
everything
about
customer
details
and
locations
etc
from
the
customer,
and
we
can
remove
them
and
we
extend
extended
to
consider
more
the
operator
perspective.
So
we
include
the
concept
of
a
VPN
nobles
and
the
people
willing
them
to
the
bidders
that
are
the
connections
to
the
VPN
nodes.
O
Okay,
so
I
don't
want
to
enter
into
the
details
of
the
other
model
itself.
That
is
for
you
to
read
and
discuss
here
just
to
present
a
concept,
the
concept
today.
Okay,
so
maybe
can
you
go
to
the
next
and
the
next
slide?
Please,
okay!
So
what
are
the
open
issues
and
I
think
those
are
the
ones
that
are
some
of
them
related
to
the
previous
talk
or
team.
So,
first
of
all
is
how
to
link
the
network
solution
model
with
other
modules.
O
So
we
are
assuming
that
the
network
operation,
the
network,
automation,
also
called
some
people,
call
it
Sdn
controllers.
As
you
want
it,
there
will
be
set
off
a
modules
available
there
and
they
need
to
be
linked
to
each
other,
for
example
topology
a
first
one.
So
we
assume
that
the
service
endpoints
or
the
solution
or
the
points
from
where
we
want
to
establish
services.
They
are
part
of
an
existing
topology,
okay,
so
to
link
them
somehow
a
for
traffic
exceeding.
O
O
O
Is
a
domain
it
will
have
its
own
control.
We
need
to
create
a
hierarchy.
So
can
we
create
this
model
genetic
enough?
So
it
allows
this
hierarchy
also.
We
have
some,
as
in
every
new
design,
every
time
we
have
our
own
model
in
discussions,
for
example,
the
set
attachments,
if
you
have
separate
container
or
part
of
assignment
velocities,
are
just
people
young,
modern
discussions-
also,
for
example,
the
use
of
profiles
versus
creating
the
resources
deadly
under
the
EPA
no
concept.
O
So
here
we
have
our
pros
and
cons
of
disability,
but
you
said
yes,
I,
think
mine
or
a
lot
more
I
can
discuss
and
not
as
general.
So
for
me
general
discussion
that
is
a
need
or
what
IDF
an
especially
rooting
row
working
group
can
help
is
how
to
link
different
young
modems
together,
so
that
they
are
not
separated
modules
Islands,
because
otherwise
it
is,
and
you
have
to
do,
hugs
or
tricks
to
be
able
to
link
them
together.
P
Was
the
singer
Britain,
so
just
question
for
clarification
today
we
have
Leah
3sm
model
right,
as
you
mentioned,
that
allows
clients
to
communicate
service
to
the
network.
We
have
numerous
models
for
the
network
Orchestrator,
for
example,
to
discover
topologies,
ok,
including
multi
domain
scenario,
setting
up
tunnels.
We
are
also
working
on
the
model
that
allows
steering
services
like
layer,
3
services
to
the
tunnels,
O'donnell
pools
or
even
topologies
of
slices.
So
basically
it
is
not
really
clear
for
me
what
exactly
is
missing.
O
And
those
those
last
pieces
of
work
that
you
have
mentioned
I
have
a
complimentary,
ok,
so
what
this
year
or
what
these
complements
is
the
service
model
that
currently
the
service
model
is
just
created
from
the
perspective
of
the
customer,
so,
for
example,
the
customer
does
not
see
where
the
quality
to
which
a
specific
port
is.
It
is
connected
in
the
network.
O
He
does
not
care,
it
can
go
through
difference,
which
is
it
it
does
not
know
to
which
encapsulation
it
is
reaching
your
network
so
that
you
can
use
it
as
input
and
the
operator
can
decide.
Okay,
based
on
this
service
description,
I
am
going
to
put
this
customer
in
this
P
and
I'm,
going
to
put
it
in
this
particular
in
port
and
with
this
particular
encapsulation.
O
So
that
is
not
part
of
the
service
model,
because
that
is
done
from
his
perspective.
So
this
is
why
it
complements
the
the
service
is
the
current
series
model.
So
it
is
a
description
of
the
series
from
the
network
perspective,
okay,
so
this
is
why,
and
the
other
works
that
you
just
mentioned,
the
stealing
of
the
traffic
etcetera,
they
are
complimentary
to
to
this
one.
Okay
and
the
other
things
that
are
missing.
They
are
there
Spain.
O
Also
they,
for
example,
the
l3
same,
does
not
have
parameters
like
artists
or
artists
that
as
operators,
when
we
create
a
service
we
give
them,
and
today
the
l3
same
model
explicitly
says
that
they
do
not
enter
into
that
resource
allocation.
So
in
the
network
model
as
operators,
we
need
to
enter
into
that
resource
allocation
business.
So
this
is
why
we
have
to
obtain
today
to
the
model
so.
O
C
O
So
the
customer
is
perfectly
fine
from
with
using
their
three
same
model,
okay,
so
this
is
from
the
service
orchestration
on
a
layer
or
the
OSS
layer
within
an
operator
today
to
a
network
controller.
So
this
is
the
particular
part
of
the
chain
or
the
tool
chain
in
an
operator
where
we
do
think
this
model
is,
is
needed
and
where
we
are
going
to
implement
it.
So.
P
The
network
historico
takes
as
an
input,
but
our
client
communicates
over
a
layer,
3
sm
model,
and
then
it
use
separate
models
right
to
discover
and
basically
allocate
resources
and
set
up
services.
Ok,
so
we
are
talking
about
different
models
which
are
all
in
progress
right,
some
of
them
in
tears,
some
of
them
in
the
source
right.
So
basically
from
what
you
well,
what
I
hear
there
is
something
missing
in
terms
of
client
to
discover
how
their
services
map
to
the
access
points,
but
beyond
that
I
don't
understand.
C
Q
O
Q
F
Bob
Wilson
Cisco,
so
I
just
had
one
question
on
your
implementation.
You
say
that
you
prune
and
extend
and
I
was
wondering
about
the
prune
bit,
particularly
the
cases
like
hierarchical
models
where
you
want
to
have
hierarchical
controllers.
I
was
wondering
what
you
need
to
carry
some
of
the
information.
That's
in
the
l3
SM
top
model,
further
down
the
stack
and
hence
whether
it
should
be
more
extend,
improve
I,
don't
I,
don't
know
either
the
model,
so
they
know
what's
been
proved.
O
So
far,
let
me
clarify
that
the
we
have
done
extend
and
we
have
not
yet
started
the
prune
okay.
So
yes,
when
we
start
the
prune,
it
will
see
how
much
a
can
we
remove
from
the
l3
SM
or
how
much
do
we
need
to
pass
from
from
threesome
I?
Guess
all
the
technical
and
routine
CP
part
will
be
kept
and
we
will
just
have
to
remove
some
of
the
more
commercial
related
information
or
the
site
related
information
which
is
relevant
for
the
service,
but
not
for
the
for
the
network?
O
Okay,
so
this
is
next
next
next
step.
There
are
also
some
parameters
like
a
grouping
that
were
associated
to
the
client
and
that
you
use
them
in
the
service
layer
or
in
the
service
orchestration
layer
to
decide,
for
example,
if
you,
if
one
or
two
accesses
or
dude,
took
or
do
you
connect
them
to
two
separate
years
and
so
on.
So
once
you
have
decide
that,
maybe
then
they
are
not
needed.
O
F
O
N
Can
we
go
last
very
quick
comment?
Sure
yeah?
This
is
true
from
Huawei
I
feel
this
work
is
quite
important
because
I
are
in
some
implementations
we
were
seeing
people
directly,
converting
l3
SM
model
to
device
model
and
because
that's
the
only
new
models
that
existed
and
not
having
this
network
model
was
creating
even
lot
of
implementation.
Complexity,
so
really
welcome
discussion.
O
R
Right
good
morning,
this
is
work
that
I've
done
together
with
Brian
Ted
and
Steven,
and
it
isn't
necessarily
a
new
thing
and
it's
not
rocket
science,
but
it's.
We
think
it
change
in
the
environment
and
the
internet
environment
that
causes
us
to
think
that
this
is
a
topic
that
should
get
a
little
bit
more
attention
now
at
the
IETF.
Another
other
places.
R
There's
a
couple
of
drafts
and
there
will
be
a
society
a
few
more
you
can.
You
can
take
a
look
at
these
if
you
like.
It's
also
be
some
discussion
that
the
recent
IAB
workshop
on
deployment
expectations
and
versus
reality
workshop
happen
in
Finland
at
the
beginning
of
June,
and
at
the
this
idea
we
also
will
have
a
discussion
at
the
security
area
group
on
Thursday,
I,
think
and
so
there's
this
RFC
RFC
3550.
R
They
can
be
attackers
in
our
environment
and
may
be
making
some
progress,
I
think
recently
on
encrypting,
more
traffic
and
using
more
encryption
and
cryptographic
mechanisms
to
protect
our
communications
and
that's
great,
but
it
also
says
that
we
assume
that
the
end
systems
engaging
in
protocol
exchange
have
not
themselves
being
compromised,
so
basically
assuming
that.
Well,
you
know,
outsiders
are
bad
inside.
R
This
are
good
and-
and
that's
the
assumption
that
we
build
protocols
for
and
try
to
describe
how
they
manage
in
that
that
situation
and
basically
the
the
belief,
is
that
changing
my
screen
here,
okay,
so
the
we
believe
that
this,
the
protecting
the
communication
is
still
very
much
necessary
and
we
probably
need
to
be
doing
it
better
than
we're
doing
today.
There's
some
improvements
that
that
are
useful
there,
but
we
are
sort
of
doubting
this
second
part
of
this
assumption
in
in
this
this
RFC.
R
It
seems
to
be
basically
counter
to
current
reality,
so
and
there's
a
couple
of
reasons
for
that.
We've,
as
I
said,
made
some
progress
in
encrypting,
Internet
traffic
I
think
at
least
from
some
networks
that
I
follow.
We
went
from
say
20
percent
encrypted
traffic
to
80
percent
and
you
know
headed
towards
hundred.
R
R
You
will
think
about
other
options,
so
you
look
elsewhere
now
and
we've
seen
some
of
this
actually
there's
been
government
surveillance
agencies
who
are
today
more
focused
on
acquiring
data
from
say
provider
than
firm.
Looking
at
you
know,
what's
going
on
in
the
in
the
wire
or
the
wireless
domain
for
that
matter
there
was
a
case
of
Australian
proposal
for
a
law
and
say
I
think
actually
came
to
be
a
law
about
what
they
can.
R
You
know,
try
and
force
various
internet
entities
to
provide
for
them,
and
this
is
sort
of
to
the
heart
of
that
desire
by
some
some
surveillance
agencies
there's
also
surveillance
in
a
commercial
sense,
surveillance
capitalism
estate,
call
it
and
there's
new
risks
for
us,
the
users,
because
some
applications
are
having
you
know,
far
more
data
collection
than
they
perhaps
did
in
the
past.
So
information
about
us
or
our
activities
are
being
collected.
R
There's
a
very
big
database
is
being
created,
perhaps
as
part
of
this
first
item
here
and
there's
a
fairly
common
design
pattern
for
building
network
things
where
you
have.
You
know,
centralized
parties
that
are
controlling
other
other
entities
and
or
you
know
that
that
if
I
want
to
communicate
with
my
friend
first
I
go
to
the
cloud
and
then
the
cloud
communicates
back
to
my
friend
and
that
that
design
pattern
is
is
almost
universal.
R
R
R
And
there's
also,
you
know
more
pros
like
approach
this
describing
the
situation.
So
basically
we
assume
that
applications
either
on
our
end
or
the
other
end
may
themselves
be
working
for
adversary
or
maybe
on
a
network
with
other
endpoints
hosted
through
to
our
interests
or
the
applications,
interests
and
and
that's
sort
of
breaking
what
the
RFC's
said
earlier.
R
So
the
question
is:
what
do
we
do
so?
The
four
of
us
we've
been
thinking
about
this
we've
been
writing
some
things
and
and
and
talking
about
it
it's
we
happen
to
be
on
the
IAB,
at
least
for
now
for
us,
but
but
it's
not
an
IAB
thing
at
the
moment.
It's
a
personal
thing
that
we're
we're
trying
to
discuss
this
idea
of
basically,
which
is
sort
of
calling
for
interest
and
discussion
and
get
some
guidance
and
feedback.
R
R
R
R
You
know
PFS
capable
today,
even
though
it
was
designed
as
not
such
a
protocol
many
years
ago
and
and
the
reason
for
that
is
that,
if
something
leaks
or
some
node
gets
compromised,
then
you
don't
want
to
lose
all
the
communications
in
the
past
and
in
the
future,
but
you
actually
have
some
compartments
and
another
example.
That's
not
on
the
slide.
R
I've
been
working
quite
a
bit
with
5g,
and
it
has
many
many
really
good
improvements
over
previous
generations
of
systems
and
not
just
in
speed
and
latency,
but
also
in
insecurity.
One
of
those
improvements
is
identity,
privacy
that
the
identity
of
the
end
users
is
not
not
visible
to
other
sites.
It's
pretty
secure.
From
from
that
perspective,
it's
not
visible
to
others,
sort
of
like
looking
at
the
radio
traffic,
but
internally
in
the
networks.
The
network's,
of
course,
still
have
to
know.
You
know
who
this
is,
for
you
know,
building
reasons
and
other
other
reasons.
R
But
but
if
you
look
at
the
network
design
the
details
of
that
they,
the
real
identity
of
often
are
the
real
phone
number
of
a
device
is
actually
revealed
to
a
fairly
large
number
of
devices
in
the
network,
which
you
know
if
we
redesign
things
now.
Maybe
that
would
be
something
that
we
should
look
at
and
reduce
the
number
of
entities
that
hear
about
this
particular
piece
of
interesting
privacy.
R
Related
information
just
keep
it
on
on
a
need-to-know
basis,
so
that
that's
the
kind
of
example
that
we
can
do
in
this
space,
and
also
when
you
do
your
security
considerations
or
design
new
architectures
or
protocols,
do
think
about
the
abuse
cases
and
not
just
the
use
cases
like
what,
if
you
know
somebody
compromised
this
node,
what
would
happen
or
what?
If
somebody
made
this
a
centralized
architecture
and
collected
the
information,
what
would
it
look
like
and
and
see
if
he
can
actually
defend
against
it?
R
R
Yeah
I
wanted
to
sort
of
briefly
go
into
like
why
I'm
here
and
what,
how
it
might
impact
network
operator
situations,
for
instance,
I
I,
did
want
to
say
and
hacked
on
my
slides.
But
if
you
look
at
my
draft,
there's
a
bunch
of
guidelines
and-
and
it's
one
sort
of
briefly
mentioned
few
of
them
so
starts
with
considering
the
first
principles
in
in
communication
or
protecting
communications
that
like,
if
you
perform
something
by
something
of
some
node.
R
Instead
of
going
directly
from
your
friend
from
you
to
your
friend,
then
that
means
that
if,
if
you
want
to
protect
the
communications
against
others,
then
maybe
you
should
protect
them,
not
just
hop
by
hop
to
the
node
in
the
middle
and
and
then
back
to
your
friend,
but
all
the
way
so
end-to-end
protection.
So
this
means
that
you
have
to
think
about
things.
Not
just
in
terms
of
you
know.
R
We
just
use
TLS
and
in
just
stick
it
in
and
then
everything
can
it
be
five,
but
you
actually
have
to
think
about
like
what
are
you
doing
and
what
are
you
trying
to
protect
from
want
to
minimize
information
pass
to
others
want
to
minimize
passing
control
functions
to
others.
What
we
do
with
all
of
that
in
in
the
operator
networks
want
to
avoid
centralized
resources,
I
mean,
or
at
least
need
to
be
aware
of
the
risks
of
centralized
free
resources
and
controls
anyway,
so
network
operator
networks,
it's
a
so.
R
Do
we
leak
information
from
individuals
to
to
large
entities
from
the
other
side
of
the
world,
and
that's
not
really
the
problem
that
we
have
in
with
operators,
but
they
also
have
large
networks
and
their
problem
is
slightly
easier
because
you
don't
necessarily
need
alignment
that
you
have
to
worry
about
in
a
lot
of
other
cases.
So
all
your
things
are
sort
of
under
one
control,
one
owner
said:
perhaps
one
network
manager,
but
even
in
a
closed
or
you
know
what
network
owned
by
one
party
there's.
R
R
Think
we
should
assume
that
entities
like
this
can
be
compromised
in
in
all
kinds
of
networks
and
design.
Architectures
with
that
in
mind,
doesn't
mean
that
you
can't
have
your
nice
control
node
in
the
middle
of
the
network,
but
it
does
me
that
you
should
understand
the
implications
of
you
know
what
what
happens
if
this
thing
goes
down
or
if
this
thing
gets
compromised
in
some
fashion
and
of
course,
that's
in
the
most
general
sense.
R
S
S
So
maybe
we
just
mistrust
everything
and
then
no
like
we
have
today
where
we
believe
everything
behaves
and
maybe
tomorrow
we
believe
that
nothing
behaves
and
as
it's
proven,
that
it
behaves
and
I
think
there's
a
steering
that
direction
so
that
you're
reversing
the
logic
of
what
we
believe
in
equipment
does
today
and
I.
Think
it's
useful
to
go
and
look
at
that.
S
What
we
can
do,
whether
we
can
have
information
conveyed
along
with
the
operation
that
this
device
can
be
trusted
and
as
such
and
then
intrusion
and
then
compromise
could
be
slight
misbehavior,
like
iqu
messages
a
little
longer
than
mine,
so
that
in
a
financial
transaction
you
loose.
Oh
I,
win
right.
So
it's
not
massive
necessarily.
A
T
So
sorry,
Adrian
Farrell,
it's
alright
Yuri!
You
don't
have
to
come
back
as
a
man
targeting
Frank
I
I.
Don't
think
you
can
approach
this
because
of
that
last
line
by
downtown
Reuters
are
hard.
You
can't
approach
this
by
saying:
I,
won't
trust
a
node
unless
I
can
prove
it
works
because,
as
a
sociopathic
principal
there
that
the
node
will
prove
that
it's
okay
until
such
time
as
you
trust
it
yeah.