►
From YouTube: IETF100-OPSAWG-20171114-1550
Description
OPSAWG meeting session at IETF100
2017/11/14 1550
https://datatracker.ietf.org/meeting/100/proceedings/
B
D
So
hello,
everyone
if
people
could
walk
in
and
sit
down
and
take
a
seat
and
stop
talking
and
listen
for
a
second
and
I'm
gonna
talk
louder
and
louder
and
louder
until
people.
Thank
you
very
much.
Apparently,
that
didn't
work
for
Kathleen
or
Eliot
and
still
doesn't.
Okay,
so
I'll
give
people
another
30
seconds
to
walk
in
and
sit
down.
D
Alrighty
we'll
count
that
as
good
enough
so
hello,
everybody
and
welcome
to
the
joint
ops
area
and
updated
liji
meeting
there
are
blue
sheets,
which
should
be
circling
or
will
be
soon
been,
was
just
filling
them
in
this.
Is
the
IETF
note?
Well,
please
make
sure
that
you
note
it
well,
it
has
important
stuff
on
some
of
it
is
legal
and
IPR
stuff.
Please
make
sure
that
you
understand
what
it
means
and
talk
to
your
lawyers
or
whatever
we're
not
going
to
interpret
it
for
you
next
slide.
D
So
as
I
say,
this
is
the
joint
ops,
AWG
and
ops
area
meeting.
We
start
off
with
ops
area.
First
note:
well,
we've
done
blue
sheets
we've
done.
Who
would
like
to
do
minutes?
I
know
someone
would
just
love
to
do
minutes
for
us
and
suddenly
everybody
who
used
to
be
my
friend
is
ignoring
me
like,
for
example,
Wes
hanukkah
who's
sitting
in
the
front
and
would
just
love
to
do
some
minutes.
D
Okay,
good
enough
nothing's
really
happened
yet
alrighty,
so
we
have
a
JavaScript.
We
have
minutes
slides
are
over
here.
We
also
have
asked
Kathleen
to
come
along
and
give
a
talk
on
the
Oh
actually
first
agenda.
This
is
our
agenda.
We've
asked
Kathleen
to
come
along
and
give
a
quick
update
on
effects
of
pervasive
encryption
on
operators.
This
is
a
document
which
had
gone
through
one
eye.
D
Atf
last
call
then
had
a
bunch
of
reasonably
sized
large
changes
and
has
gone
through
somewhat
of
an
is
G
of
L,
but
now
it's
having
a
second
IETF
last
call.
This
is
a
document
that
I
would
really
appreciate
it.
If
people
can
read
and
can
comment
from
an
operator
standpoint,
Kathleen
will
explain
what
it
is,
but
it's
I
think
a
really
important
document
for
operators
to
actually
provide
input
on
network
slicing.
D
E
G
H
F
F
Let's
see,
and
it's
also
to
have
these
documented
so
that
new
methods
where
appropriate
might
be
developed
to
replace
methods.
So
with
that,
the
document
does
not
try
to
solve
the
problems
that
would
be
taking
on
much
more
than
we
want
to
at
this
time
when
I'll
bring
up
the
table
of
contents
in
a
bit,
but
essentially
once
these
are
documented.
If
there
are
ones
that
should
have
some
work
done
on
them,
it
could
be
a
draft
on
it.
F
Each
section
could
be
a
draft
on
its
own
right
on
in
terms
of
how
do
you
progress
or
change
the
ones
that
make
sense
to
look
at,
so
we
don't
try
to
solve
the
problems.
So
we
try
to
document
the
current
state
and
in
some
cases,
and
what
we're
learning
through
comments
and
feedback
is
that
there
might
be
multiple
approaches
being
used
for
the
same
thing.
F
If
we
haven't
captured
an
approach
used
for
a
particular
goal,
it
would
be
good
to
have
the
current
practices
all
documented
within
that
goal
area
and
that
might
even
help
some
of
the
operators,
because
some
may
have
come
along
further
in
terms
of
dealing
with
encryption
right.
So
it
might
help
people
with
solutions
understanding.
F
You
know
they
have
the
same
goal
to
be
met,
and
this
is
the
data
that
they
were
using
and
how
they
accomplish.
That
goal
right.
So
I
just
wanted
to
make
sure
folks
are
familiar
with
some
of
the
principles
as
to
you
know
and
I
guess
this
is
complicated.
Is
there's
lots
of
reasons
why
encryption
is
increasing
on
the
internet?
One
motivator
is
privacy
and
confidentiality,
so
you
could
look
to
RFC
six,
nine,
seven
three.
F
If
folks
aren't
familiar
with
that
document,
I
think
it's
a
good
read
and
an
important
consideration
so
that
you
know
you're
looking
at
this
from
perspectives
of
others
as
well
right.
So
this
documents
focused
on
operators
impacts
but
understanding
the
flip
side
of
why
this
push
is
happening
is
important.
So
this
is
one
of
the
reasons
for
that
push.
F
Rfc
7258
is
another
right,
so
I
think
most
people
should
be
familiar
with
that
RFC
and
the
plenary
from
several
years
back
where
the
IETF
made
a
decision
to
do
that.
Pervasive
monitoring
is
classified
as
an
attack,
and
with
that
decision
and
the
document
there
was
a
call
for
balance
between
security
and
network
monitoring,
and
so
this
draft
is
meant
to
be
an
initial
step
at
working
towards
that
balance
right.
F
So
if
we
have
to
understand
what's
needed
on
both
ends
of
this
to
be
able
to
have
meaningful
discussions
in
terms
of
how
do
we
go
forward-
and
you
know
it's
7258
is
nice,
because
it
does
call
out
network
monitoring
explicitly
and
separate
from
other
types
of
others
separately
from
like
pervasive
monitoring
right.
So
it
does
call
out
that
there
are
separate
functions
here
at
hands
and
separate
goals
here,
and
you
know
and
that's
why
we're
looking
for
balance
with
with
those
particulars.
F
So
this
is
just
a
note
of
some
of
the
changes
from
7258
and
there's
a
later
slide
in
the
back
up
that
could
be
distributed.
That
has
a
little
bit
fuller,
a
list
of
efforts
from
the
pervasive
monitoring
decisions,
so
opportunistic
security
was
a
change
and
basically
how
many
in
the
room
are
familiar
with
opportunistic
security.
Oh
great,
so
it's
a
it's
a
fair
amount.
The
push
for
that
just
to
give
a
real
quick
overview
for
those
who
aren't.
F
Let's
see
some
other
changes
that
have
happened
in
the
in
the
past
few
years
is
improved
improvements
for
TLS
1.3,
which
isn't
yet
out,
but
forward
secrecy
and
and
other
changes
were
put
into
1.3
and
these
while
they
present
problems
for
administrators.
The
recommendations
were
actually
in
TLS
1.2,
best
practices
already
so.
F
I
think
in
cases
where
we're
seeing
pushback
on
that
is,
is
just
when
people
haven't
upgraded
to
the
BCP
recommendation,
so
they're
still
using
RSA
static
keys
because
they
have
to
perform
monitoring,
and
it's
it's
also.
So
in
that
case
it's
an
important
case
to
think
about,
because
there
are
needs
that.
F
They
have
requirements
to
monitor
within
their
network.
They
are
actually
not
required.
As
far
as
I
can
tell
from
regulations
to
encrypt,
they
are
encrypting
their
internal
traffic
because
it's
a
best
practice
and
a
good
thing
to
do
to
prevent
attacks
so
I
think
that's
a
laudable
goal
and
they
have
to
figure
out
how
they
can
do
the
monitoring
necessary,
but
still
protect
their
their
internal
data
from
attacks.
F
So
I
think
this
is
also
pointing
to
by
enumerated
all
these
problems,
we're
pointing
to
problems
that
could
be
a
result
of
issues
with
data
and
troubleshooting
capabilities
logging
from
applications
right.
So
there's
there's
a
mix
of
things
that
are
going
to
surface
from
this
and
I
think
the
discussions
that
hopefully,
this
draft
and
other
work
will
enable,
will
be
positive
to
get
us
towards
a
better
endgame
I
personally
feel
that
if
we
don't
get
a
handle
on
this,
the
encryption
that
folks
want
to
see
won't
happen
because
it
won't
have
the
adoption.
F
But
if
we
hit
this
head-on
and
we
have
the
hard
discussions
and
we
figure
out
how
do
we
go
forward
with
each
of
these
things?
And
we
offer
help
and
have
operators,
you
know
document
these
and
and
we
work
together
with
protocol
designers
developers,
my
as
we
get
to
a
better
place
and
we
figure
out
a
balance
and
what
that
balance
means
for
for
us.
F
F
F
Http
header
insertion
the
enterprises-
I
think
we're
pretty
well
set
on
that.
But
if
there
are
more
comments,
we'd
love
to
get
them
and
I'm
gonna
try
to
leave
a
lot
of
the
time
to
discuss
here
gaps.
So
I'm
actually
gonna
make
this
quite
quick.
So
I
hope
that
that
works,
and
I
hope
that
people
are
interested
in
discussing
maybe
gaps
that
they
see
here
in
the
agenda
or,
if
they've
read
the
draft
and
they
have
some
direct
feedback.
F
So
security
there's
a
whole
section
where
security
was
pulled
out
separately
from
the
different
types
of
networks
in
the
structure,
because
some
of
these
applied
more
broadly
and
in
some
cases
like
the
ddos,
it
talks
to
it
not
being
a
problem
for
being
able
to
fingerprint
traffic,
whether
it's
encrypted
or
not,
encrypted.
Things
like
that
were
actually
verified
with
three
different
people
at
different
organizations
that
the
text
was
who
do
ddos
research.
Now
we
weren't
lucky
it's
so
lucky
in
every
single
contribution
that
we
were
able
to
get
diverse
input.
So
that
would
help.
F
If
you
know
you
have
expertise
in
one
area
that
you
review
it
and
contribute
and
improve
that
text,
application
flow
information,
so
the
IP
fix
text
was
recently
added
in
the
latest
revision.
That
was
a
glaring
gap
that
benoit
pointed
out,
and
I'm
glad
that
we
were
able
to
fix
that
if
there
are
others.
I
hope
that
those
of
you
with
the
expertise
can
help
so
that
we
can
get
this
documented
TLS
server
name
indication.
I
think
that
section
probably
needs
a
little
updating,
because
there's
active
discussion
happening
on
that
now.
F
Let's
see,
and
this
last
section
on
mobility
could
use
a
lot
of
help,
so
we
have
not
had
enough
contributions
on
that
section
in
my
so
we
had
maybe
three
different
people
over
the
whole
section,
but
it's
a
really
big
space.
So
if
you
have
expertise
in
that
area,
I
ask
that
you
review
the
document
in
last
call
and
provide
your
feedback
and
comments
and
text.
So
this
one
only
right
now
it
just
covers
the
effective
encrypted
acts,
effective
encrypted
transport,
headers,
effective
encryption
on
new
or
emerging
services,
and
effective
encryption
on
mobile
network
evolution.
F
Let
me
see,
if
there's
anything
so
I
guess
a
few
points
like
I
left
out
some
of
the
sections
in
the
in
the
table
of
contents
that
were
displayed
because
things
like
data
storage.
Is
it's
not
an
issue
right,
so
I
I
work
at
a
vendor
and
I
had
reached
out
to
Lars,
for
you
know
any
feedback
or
questions
or
text
on
that
and
I
think
neither
of
us
are
seeing
big
issues
because
encryption
was
required
by
our
customers.
F
We
implemented
it
and
we
also
made
sure
that
the
management
functions
that
they
needed
were
present
with
that
encryption.
So
I
think
that
you
know
leaving
that
text
in
as
good
as
an
example
of
you
know,
this
can
be
done
and
you
can
do
your
monitoring
and
I
know
that's
different
than
the
larger
Network
I
understand
that,
but
it
just
does
serve
as
an
example
and
another
area
that's
covered
is
hosted
providers
but
the
motivations
there
were
very
different
right.
F
F
So
I
don't
think
it's
as
controversial
and
I.
Don't
think
it's
as
in
need
of
of
as
much
attention
as
some
of
the
other
sections
just
in
terms
of
Rio
and
making
sure
that
we
get
this
right
middle
box
function.
So
I
think
I
highlighted
some
of
these
that
understand.
Making
sure
that
we've
got
this
right
would
be
really
helpful
from
those
of
you
who
could
contribute
and.
F
Yeah
DDoS
and
incident
management.
The
impact
does
vary
there.
Some
people
are
really
reliant
on
decrypted
streams
and
others
who
have
quite
advanced.
These
sorts
have
worked
ways
around
that,
so
it
really
depends
on
operational
practices,
and
maybe,
if
we
are
sharing
more
on
these
practices,
will
learn
from
each
other
and
understand
how
we
can
move
forward
in
better
ways.
F
I
Otto
Erica
from
Huawei
interesting
talk.
It's
not
the
questions
more
of
a
comment,
so
you
are
talking
about
the
impact
of
let's
say,
security
measures
on
network
management
right,
however,
in
principle
they
are
mutually
dependent
because
you
can
also
be
talking.
You
could
be
talking
right
now
about
the
impact
of
network
management
on
the
security
of
the
network.
Right.
Can
you
repeat.
J
I
Most
of
Security's
actually
active,
you
need,
you
know,
monitoring
and
updates
to
maintain
your
security
level.
So
this
you
know,
operational
security
assurance
depends
hugely
on
the
monitoring.
So
I
was
just
commenting
that
this
is
indeed
and
very
important
and
interesting
dependency,
but
it's
mutual.
So
we
can-
probably
maybe
you
know,
extend
this
to
discuss
this
mutual
dependency
right.
F
Right
so
the
document
frames
the
the
encryption
usage
and
motivations
and
the
introduction.
Then
it
moves
on
to
operator
impacts,
and
that
includes
security
operators
as
well
as
network
operators,
and
it's
aimed
at
having
the
goal
stated
and
what
data
is
used
to
accomplish
those
functions
and
then
not
to
solve
anything,
and
we
might
not
have
gotten
that
perfect
everywhere.
So,
if
you're
reading
the
draft-
and
you
think
we
didn't
do
that
quite
well
enough
to
keep
it
neutral
enough-
let
us
know
and.
D
Actually,
very
quickly,
chime
in
as
well
folk
read
the
earlier
versions
of
the
document.
Sorry
I'll
get
closer
to
the
mic
again,
because
they're
really
sensitive
if
folk
have
read
earlier
documents
of
the
document
or
read
it
when
it
had
its
first
last
call
I
strongly
encourage
them
to
reread
it.
One
of
the
big
changes
has
been
in
the
tone
of
it
and
you
know
potentially
that
something
that
still
should
get
a
little
bit
of
looking
at,
but
some
folk
had
viewed
it.
D
K
K
K
You're
there
at
least
in
most
sections
there,
a
couple
places
where
I
so
I'm
going
to
review
as
much
as
I.
Can
it's
a
fairly
lengthy
document,
so
I
can
I
just
don't
know
when
I
would
find
time,
but
I
will
also
then
ask
other
people
in
the
room
if
everybody
will
commit
to
reviewing
a
page
or
two
or
a
section,
that's
relevant
to
their
area
of
expertise.
This
could
be
a
really
it's
already.
You
know.
J
K
F
L
F
So
I
made
that
comment
in
general
and
left
that
section
out,
because
I'm
not
seeing
the
same
types
of
controversy
for
that,
because
the
motivations
for
encryption
in
those
spaces
are
different.
Now
this
is
not
getting
into
the
so
with
that
I'm
not
getting
into
like
the
the
discussions
of
the
TLS
working
group
and
applying
that
to
hosted
environments
right,
that's
a
more
general
so
not
specific
to
a
hosted
provider.
F
F
L
L
M
It
knows
bonus,
Equinix
is
speaking
as
a
working
group
member,
so
I've
been
socializing
this
document
and
in
general,
this
topic
of
increased
encryption
ever
with
several
operator
forums
and
events
and
few
topics
has
an
aggregated
feedback
about
that.
First,
on
the
language,
it's
very.
There
is
a
difference
of
the
language
used
to
describe
the
same
things
here
at
ATF
and
at
operations
community.
M
To
give
an
example
saying
that
encryption
with
effective
functions
of
middleboxes
might
not
mean
not
the
same
as
saying
that
encryption
will
affect
the
IG
MP
snooping
on
my
laptop
switch
and
therefore
break
my
AP
TV
service.
So
if,
if
more
feedback
from
operations
community
is
expected,
maybe
a
companion
document
or
simply
expect
some
other
format
of
of
translating
this
into
the
language
and
topics
which
are
more
relevant
to
the
actual
field
operations
would
be
good.
I
do
understand.
This
is
a
hard
work,
but
this
is
just
that
feedback
from
the
community.
So.
E
M
E
F
G
M
In
particular,
this
he
has
been
presented
at
in
OGG,
which
is
operators
forum
for
russian-speaking
region,
which
is
part
of
a
ripe
ripe
region
coverage.
This
has
been
presented
at
euro
ax.
This
has
been
presented
as
a
side
meetings
at
right
meeting,
some
other
smaller
country,
specific
network
operator
groups.
E
E
M
F
F
Really,
no,
the
whole
point
is
to
start
having
the
conversation,
because
if
operators
are
having
problems
and
they
have
specific
functions
and
application
developers
are
not
aware
of
those
functions,
this
is
one
way
to
surface
those.
So
the
conversations
can
happen.
I
like
to
kind
of
hit
problems
head-on
and
I
guess
I
did
with
this
one.
It's
been
a
lot
of
fun
to
work
on,
but
it
opens
up
the
conversation
and
the
goal
would
be.
You
know
how
do
we
actually
get
the
encryption
deployed
because
we
can
release
all
the
protocols
we
want?
F
It
doesn't
mean
they're
going
to
be
adopted
and
deployed
right,
so
having
these
conversations
on
obstacles
is
really
important,
because
at
the
end
of
the
day
you
know,
operators
are
out
there
on
the
network
and
make
choices
right,
and
so
they
have
to
go
on
what
what
they
have.
And
so,
if
we
open
up
this
conversation,
we
may
give
them
more
choices.
F
Yeah,
so
that's
come
up.
I
actually
responded
to
that.
I
think
this
morning
on
list
I'm
the
same
the
same
point,
and
hopefully
that's
been
made
clear
enough.
I
thought
it
was
clear
enough
in
the
draft,
but
if
you
see
text
that
you
think
makes
that
confusing.
Please
point
it
out
because
I'm
not
seeing
it
and
I'm
probably
reading
with
a
bias,
so
it
would
be
helpful
to
have
that
pointed
out.
So
we
could
correct
it.
E
One
example
of
this
so
in
the
quick
charter,
I
insisted
that
we
have
a
management
draft
explaining
like
in
the
drought
that
kept
in
mention
what
would
we
lose
by
doing
encryption?
And
the
only
point
is
to
document
this.
Now,
it's
up
to
the
committee
to
decide
if
it's
a
big
issue,
a
small
issue
or
something
we
should
not
address
but
documenting
the
the
gap
of
what
you've
been
losing
is
important.
It.
F
D
Just
to
answer
an
earlier
question,
the
working
group
last
call
ends
on
December
4th,
but
for
people
in
the
US,
there's,
Thanksgiving
and
stuff
so
many
days
are
lost
then,
and
also
I'd
like
to
point
out
you're
likely
to
be
sitting
on
a
plane
for
a
really
long
time
in
the
next
couple
of
days.
Reading
this
on
a
plane
would
be
an
awfully
good
idea.
C
Absolutely
I'm
Darrin,
Pettis
I'm,
an
operator
and
I
want
to
thank
Kathleen
and
al
for
taking
the
time
to
write
the
document
and
I
am
one
that's
guilty
of
not
reading
the
current
format,
so
I'd
like
to
read
it
update,
read
the
updates
and
understand
them
on
those
very
long
plane,
rights.
The
way
LF
but
and
I
and
I
think
that
it
addresses
many
of
the
usages
but
I'd
like
to
share
that.
There
are
some
very
real
needs
here
that
you
have
explained
for
us
to
do
that.
C
The
work
that
we
need
to
do
to
secure
data,
there's
expectations
that
your
data
secure
and
there's
expectations
that
the
applications
are
up
in
time
and
we
all
use
these
applications.
You
know
whether
it's
banking
or
shopping
or
things
that
we
all
do
today.
So
while
it's
very
important
to
be
secured
on
the
internet
and
I'm,
a
privacy
advocate
as
well
I
think
that
everything
that
TLS
group
is
done
with
1.3
on
the
Internet
is
outstanding,
but
I
think
there's
a
different
use
case
for
inside
the
enterprise.
C
Because
of
those
expectations
we
need
to
secure
and
keep
keep
those
up.
So
that's
one
of
the
reasons
that
we've
been
working
to
bring
that
awareness
because
encryption,
it's
a
hot
topic
right.
Some
folks,
you
know
really
want
encryption
as
much
as
possible,
but
we
also
have
to
perform
our
job
and
that's
kind
of
where
we're
in
the
middle
right.
So
we
have
to
find
that
middle
ground.
C
F
J
J
C
C
How
do
you
do
it
if
you
can't
see
so
right
now,
yep
right
now
we
have
the
finger
pointing
going
on
between
the
cloud
and
the
enterprise
with
problems
and
it's
dark
and
we're
not
able
to
see
it
so
I
think
having
some
visibility
internally.
Only
two
people
that
only
need
to
see
it
will
be
extremely
helpful.
Yes,.
P
Making
encryption
like
less
attractive
or
less
desirable,
I
think
over
time
we
have
encountered
problems
that
have
a
lot
that
have
caused
us
to
reconsider
or
abandon
methodologies
that
we
formerly
used,
because
they
were
no
longer
good
enough
and
I
think
like
static
keying
was
an
attractive
thing
for
a
long
time.
Much
like
say,
our
c4
was
an
attractive
thing
for
a
long
time
and
because
they
were
sufficient
to
meet
our
needs
and
we
had
tooling
around
them
and
they
offered
certain
benefits
like,
for
example,
computational
efficiency.
P
It
was
fast
on
low-end
hardware
for
certain
kinds
of
behaviors
at
some
point,
like
some
of
those
things
we
we
look
at
them
and
we
decide
that
they're
a
little
dangerous,
and
so
you
know
if,
if
we
decide
that
static
keys
are
a
little
bit
too
dangerous
at
some
point,
then
you
know
they
end
up
being
a
less
desirable
portion
of
our
toolkit
and
over
time
you
know
they
they
end
up
not
being
part
of
it
so,
and
we
use
better
things
instead,
yeah.
F
F
F
P
So
whether
it
meets
your
needs
are
not
as
sort
of
irrelevant
at
that
point
and
I
think
we
need
to
be
mindful
of
sort
of
existential
threat
of
that
happening
with
any
particular
tool
that
we
use.
But
in
fact.
P
We
use
now
because
tools
that
we
don't
use
yet
are
actually
really
easy
to
get
rid
of
right.
It's
the
it's
the
tools
that
we
that
are
actually
embedded
in
our
methodologies
and
in
our
organizations
that
are
actually
a
hard
and
take
time
to
replace
and
so
I
mean
those
are,
in
fact
the
ones
that
are
the
most
expensive
to
deal
with
and,
of
course,
the
the
most
problematic
when
they
become
less
desirable
to
use.
So.
F
Q
I
heard
so
not
speaking
against
Creek,
chair
but
nope,
but
over
in
quick.
We
we
only
scratched
the
surface
of
this,
where
we
have
only
a
very
limited
problem
compared
to
what
you
have
up
on
the
slide
there,
but
it's
already
proving
quite
challenging
and
specifically
sort
of
so
quick
base.
It's
also
network
operators
may
or
may
not
have
equipment
that
uses
information.
That
TCP
provided
in
the
clear
arm
to
do.
Q
Network
management
and
quick
encrypts
that
information
and
one
of
the
options
over
in
quick
now
is
that
maybe
we
were
going
to
expose
some
limited
set
of
that
information
in
authenticated,
clear
text,
so
we
couldn't
modify
it.
They
couldn't
NAT,
for
example,
but
you
could
still
see
it.
The
interesting
issue
is
that
it's
new
with
quake
is
that,
because
the
quick
state
machine
actually
is
gonna
act
on
the
information
that
is
in
the
encrypted
part
of
the
packet
and
we're
just
basically
copying
out
some
stuff
into
the
clear
text.
Q
That's
not
necessarily
accurate
right.
So,
just
because
we're
putting
something
in
the
clear
does
not
actually
make
quick
a
quick
stick
operate
on
that
at
all,
and
so
inherently
there's
less
trust
for
an
operator
because
we
TCP
you
kind
of
trust
that
the
ITT
you
saw
was
the
ITT
that
the
TCP
sec
on
the
other
end
was
going
to
use
with
quick.
Q
You
don't
know
and
I,
don't
know
if
there's
any
good
answer
to
this,
but
it
sort
of
adds
another
problem
dimension
to
this
whole
thing,
and
even
if
you
expose
information,
then
network
operator
or
the
function,
if
you
want
to
generalize
it
kind
of
needs
to
sort
of
somehow
have
some
opinion
about
whether
you
can
trust
that
information
at
all.
So.
F
Because
we
don't
necessarily-
and
the
operators
responding,
might
not
have
experience
with
quick,
they
might
not
realize
some
of
their
impacts.
So
if
you
could
read
the
draft
or
have
someone
help
and
and
see
that
angle,
the
other
thing
I
don't
think
we
got
responses
specific
to
would
be
like
TCP
crypt
work,
so
these
they're
all
good
things,
but
understanding
how
we
broach
these
conversations
so
that
you
know
you
guys
can
consider.
Q
Recreate
you
could
recreate
a
problem,
a
TCP
crypt
by
simply
sending
encrypted
TCP
header
information
inside
the
crypto
forum
in
TCP,
operates
on
that
and
whatever's
on
the
other
half
the
packet
isn't
actually
what
is
if
he
operates
on
we're
not
at
that
stage
which
easy
peepers
as
a
large
installed
base
amount
that
between
quick,
that's
currently
where
we
are
everything's
encrypted,
and
now
we're
sort
of
talking
about
making
unencrypted
and
sort
of.
So
my
meta
point
is
that
sort
of
if
we
it
would
be
awfully
nice
if
we
were
to
actually
you
know.
Q
F
E
Thank
You
Lars,
so
we're
fifteen
minutes
behind
nearly
we
cut
the
line
already
so
can
we
just?
Can
we
have
your
reply
on
the
ITF
mailing
list
of
the
last
call?
Thank
you
very
much
and.
D
Thank
you
and
while
Ignace
is
bringing
up
the
next
set
of
slides
the
last
time
this
went
to
IETF
last
call,
we
got
almost
no
feedback
from
operators
to
say
you
know.
These
are
actually
problems
that
I,
see
and
think
are
important.
So
this
time
it
would
be
really
useful
if
people
can
comment,
you
know
during
it
after
okay.
Thank
you
and.
R
Hello,
everyone
I'm
Leon
from
China
mobile
today
and
presenting
on
behalf
of
the
proponents
of
the
network
slicing
team.
We
basically
want
to
share
with
you
what
we
have
been
doing
after
a
tip.
Ninety
nine
and,
in
particular
in
response
to
the
feedback
from
the
non
working
group
forming
bath
and
the
presentation
will
be
formed
with
for
individual
drafts
and
in
two
parts.
The
first
part
I
will
talk
about
the
problem
statement
and
use
cases,
and
the
other
one
is
about
a
two
solution
based
draft.
R
So
next,
like
oh
I,
can
control
it
myself
right
so
problem
statement
and
you
skate.
So
if
we
have
a
look
at
what
we
get
from
the
80s
and
and
all
these
attendance
from
the
IETF,
ninety
nine
in
the
bath,
a
general
question
is
ARC's
about
what
we
have
been
presenting
is
well.
This
is
a
too
big
question
to
work
on
as
a
single
working
group,
so
in
response
to
that,
and
we
as
a
team
actually
decide
to
move
the
focus
specifically
to
the
operation
of
management
of
network
slicing
in
scope
of
the
IETF
work.
R
So
there
also
discussion
about
okay,
there's,
no
clear
requirement
for
transport
network
that
were
slicing
from
3gpp
revision
15
perspective.
Should
we
still
do
network
slicing
in
IETF
and
our
point
of
view.
The
answer
is
absolutely
yes,
because
network
slicing
is
a
general
topic
not
for
a
specific
standardization
I'm,
a
group.
R
We
see
that,
although
slicing
is
more
about
a
new
concept
of
business
model,
a
new
concept
of
how
you
manage
your
network,
how
you
slice
your
network
for
dedication
uses,
we
see
these
type
of
dedication
and
business
model
is
a
norm
for
the
future
network.
People
can
argue
that
VPN
is
a
network
slice
in
transport
network.
I
I.
Don't
argue
that
that
this
is
wrong.
This
is
right,
but
this
is
this
is
correct,
but
this
is
only
one
case
for
the
basic,
the
most
simple
network
slicing.
R
R
So
we
believe
we
have
consensus
now
that
networks
slicing
with
ing
is
a
mechanism
is
a
management
mechanism
that
an
service
provider
or
a
infrastructure
owner
or
a
virtual
service
provider
whatever
can
use
to
make
the
dedication
to
their
network
and
to
provide
this
dedication
to
third
party
tenant,
which
we
call
in
the
draft
network.
Slice,
tenants
and
network
slice
without
the
ing
is
actually
the
dedicated
network
and
it
is
a
manageable
group
of
network
components,
including
connectivity,
storage
computing,
which
other
resources
part
and
also
include
which
we
call
it
in
the
draft.
R
Generalized
network
function
or
generalized
service
functions.
So
those
are
the
functions
either.
It
is
physical
network
function
or
virtualized
network
function
that
exists
in
the
network
that,
under
the
supervision
of
your
service
provider,
can
be
provided,
can
be
exposed
to
the
network
slice
tenant.
R
So
we
have
the
name
as
the
problem
statement
supervised
heterogeneous
network
slicing.
This
is
a
general
diagram.
We
see
where
our
operation
and
management
set
in
the
system
or
in
the
architecture.
So
the
the
upper
block
is
what
we
call
it
network
slice
as
a
service.
So
it's
really
not
ITF
specific.
It's
just
you
know
help
us
to
understand,
so
you
can
create
via
a
portal,
for
example,
from
a
template.
R
You
know
predefined
by
a
service
provider
or
infrastructure
and
for
you
know,
generalized
a
purpose
slices
or
you
know,
most
common
slice
that
has
been
discussed
a
lot
in
3gpp,
for
example,
three
different
types
of
rents
and
also
you
can
create
you
know
more
customized
ones,
just
about
adding
the
components
you
want.
For
example,
a
gaming
company
may
want
a
certain
topology
for
their
game
servers
for
deterministic
or
for
low
latency
applications.
So
that's
different
type
of
creations.
R
So
in
the
middle
part,
where
you
know
the
common
operation
and
management
come
into,
the
picture
is
what
we
call
it
cross
segment
slice
manager,
we
define
SEC,
but
this
can
be
discussed.
This
is
just
a
terminology
we
are
using.
Currently
we
define
segment
simply
as
a
you
know.
If
we
think
I
need
to
have,
you
know,
take
care
of
the
internet,
then
we
also
take
care
of
the
back
home
and
then
there
are
other
segments.
For
example,
you
have
run
and
you
have
the
Sailor
core.
R
So
that's
the
segment
and
inside
the
ietf
segment.
There
are
also
different
domains,
so
we
have,
for
example,
maybe
a
CTN
domains.
You
have
you
know
the
legacy
domains
where
we
still
use
non
Sdn
aware
traditional
EMS
system
to
manage
our
transport
devices,
and
you
also
have
your
access
domains
and
you
have
your
Odeon
or
the
WM
domains
where
you
have
different
managers.
So
that's
we
call
it
domain
and
those
controllers
or
management
system.
R
We
call
it
two
main
agents
and
it's
in
red
because
in
the
latest
version
draft,
there's
no
there's
a
different
name,
but
please
refer
to
the
slides.
I
said
you
know
a
more
latest
version,
so
components
for
network
slicing.
Now
we
have
defined
four
types
of
five
types
of
different
components:
connectivity,
computing,
storage.
R
Similarly,
for
you
know,
nfe
methodology
where
the
networking
computing
and
storage,
so
the
three
major
part
of
three
major
different
kinds
of
network
components,
also
exist
and
transport,
because
in
computing
storage,
a
typical
usage
of
these
two
type
of
resources
in
transport
is
a
customized
controller
or
in
recipient
network.
It
could
be
a
storage
of
centric
service
that
a
tenant
won't
may
want
in
their
network
slice
and
then
the
generalized
function
will
be
a
you
know:
a
wider
character
e.
R
So
it's
also
a
you
know,
a
section
that
is
left
out
for
a
more
discussion
here.
So
we
tried
I'll
talk
about
this
later
in
the
solution
based
draft.
We
tried
to
integrate
some
of
the
examples
of
the
existing
network
functions
that
we
think
may
be
capable
of
exposed
to
network
slice
tenant.
So
the
example
can
be
firewalls
a
next
service
and
others,
and
then
we
leave
a
extend
extendable
session
with
others,
because
we
see
new
technologies
that
may
not
be
widely
distributed
widely
deployed
in
wide
area
network.
R
It
might
be
deployed
in
song,
specific
local
local
network
or
some
specific
domain
in
a
operators
network
for
some
ICN
and
others.
So
we
will
leave
that
out
and
then
people
can
add
what
they
actually
think
is
available
for
slicing
as
well.
So
the
common
operation
and
management
in
short,
CE,
o
NS,
is
the
base
of
our
work
now,
and
we
basically
deal
with
these
operation
and
management.
A
matters
for
network
slicing
and
I,
don't
know
if
it
is
too
small.
This
is
basically
a
working
flow.
R
How
a
network
slice
tenant
ask
for
a
nap
slice
service
and
then
a
the
service
profile
can
be
step-by-step
mapping
to
the
bottom
layer,
what
we
call
in
an
IETF
network
configuration
model.
So
basically
you
have
a
service
delivery
model
which
is
more
businesslike
business
viewpoint
and
then
a
because
we
have
different
segments.
R
Then
the
service
delivery
model
would
be
a
global
one,
and
these
you
know
the
decompose
at
once
and
then
the
co
mas
comms
we
are
talking
about,
will
take
the
delivery
model,
service,
delivery
model
and
map
them
to
a
information
model
described
inside
the
crop,
segment,
slice
manager
or
the
slice
manager
within
the
IDF
domain.
Because
using
the
information
model,
you
can
have
a
visualized
a
set
of
information,
how
a
network
slice
actually
looked
like,
and
then
these
information
model
will
be
used
to
further
map.
R
To
do
many
specific
network
configuration
models
which
can
be
used
by
what
we
call
domain
agent,
which
is
the
controllers.
You
know,
controls
the
specific,
a
demonstrated,
an
administrative
domains,
so
that's
basically
working
flow
and
the
basic
the
main
functions
of
comms
I've
listed
there
I
won't.
R
So
with
the
narrowed
scope,
we
have
a
bullet.
We
have
some
bullet
point.
So,
as
I
said,
the
common
information
model
will
be
the
key
for
the
comms
and
then
there
are
other
concerns,
including
monitoring,
including
lifecycle,
management
for
detection
protection
mechanisms
and
those
are
OEM
concerns
and
that
will
have
derived
models
or
mechanism
or
operation
or
interfaces
and
the
last
three.
You
know
it's
probably
more
easy
to
visualize.
As
a
network
slice
manager,
you
will
have
a
northbound
interface
with
these.
R
You
know
we
call
it
an
SaaS
platform
where
the
service
delivery
model
will
be
sent
to
the
North
Hmong
interface.
Often
that
was
lesson
that
manager.
So
we
need
to
define
what
that
model
looks
like
what
product
is
going
to
be
used,
we're
not
going
to
for
now.
We
don't
see
the
necessity
of
defining
new
protocols
to
deliver
that,
but
we
do
see
requirements
of
defining
a
model
and
also
for
the
southmont
interface.
R
But
southbound
interface
needs
to
be
discussed
because
it
might
be
in
scope
and
might
not,
because
for
specific
domains
with
mature
technology
has
been
done
in
the
ITF
they
may
want
to
do
their
own
network
configuration
model
themselves
which
is
Capac
paddleball
with
the
network,
slice
level
kind
of
information
model
and
we're
open
to
that.
But
for
some
legacy
systems
and
others
we
can
also
discuss
to
bring
that
working
eyes
into
the
scope
of
comms.
O
O
So
this
is
one
comment:
I
appreciated
the
many
affair,
your
proposals
in
actually
the
way
that
you
presented
that
looking
from
the
business
a
level
in
the
catalog
based
and
whatever,
but
one
thing
that
I
must
raise
concern
is
that
and
medicalizing.
At
the
end
of
the
day,
it's
end-to-end,
the
entering
network
ties,
can
be
built
of
multiple
slices,
one
from
the
ran
one
from
the
core
one
from
the
transport
etc.
O
I
sing
and
I
am
very
much
concerned
that
we
deviate,
or
might
they
v8
from
what
is
being
done
and
considered
there
and
develop
own
solutions
here
that,
at
the
end
of
the
day,
would
not
be
consistent
with
what
is
being
done
there.
So
I
see
a
lot
of
value
here
in
what
you
say,
but
I
just
see
the
need
to
work
together
to
align,
because
otherwise
it
would
not
be
valuable
for
the
industry.
Yes,.
R
Yes,
that's
very
good
suggestions
and
and
honestly
because
whiffing
we've
been
working
with
inside
china
mobile
the
3gpp
team
just
sit,
you
know
beside
me,
so
we
have
been
working
closely
and
we
know
you
know
next,
a
to
the
definition
of
natural
slice
in
3gpp
does
not
include
transport
network,
so
it's
ramp.
Last
core
end
to
end
is
rent
and
core.
It's
not
ren
transport
core
so
that
that's
that's
in
three
DPP
I
say
two
but
I
know
in
essay
5.
There
are
discussion
of
a
end-to-end
management
in
terms
of
that
was
licensing.
R
That
includes
everything,
but
my
understanding
is
3.
Dpp
is
not
going
to
manage
transport
network
anyway,
but
there
is
going
to
be
requirement
coming
through
and
that's
I
agree
with
Greg
there's
no
clear
requirement.
You
know
three
months
ago
in
99,
but
we
are
more
confident
in
Kiev
as
a
team
working
on
our
slicing,
when
there
is
a
requirement
as
part
of
the
end-to-end
network,
size
and
management,
from
xa5
we're
more
confident
to
response
and
in
term
internally
in
IETF,
there
are
more
use
cases
that
end-to-end
does
not
include
random
core
everybody.
R
S
S
We
don't
have
any
official
requirements
still
now
and
I'm
doubtful
that
this
will
happen
within
the
next
year
that
there
will
anything
come
up
dedicatedly
from
us
towards
IDF,
but
I
think
what
we
said
last
time
and
what
you
also
have
in
your
presentation
and
what
I
fully
agree
with
is
this
work?
If
ITF
sees
a
need
to
work
on
slicing
within
the
IDF,
then
you
should
go
ahead
and
not
should
all
the
time
ask
what
is
3gpp
doing,
and
why
should
you
be
P
doing
that?
S
As
you
said
now,
for
example,
transport
network
is
left
out
of
our
focus.
It's
usually
not
in
our
focus.
So
these
this
work
on
slicing
is
going
on
in
several
standards
bodies
in
parallel,
and
we
will
have.
We
will
create
a
certain
amount
of
confusion
for
sure,
with
different
definitions
and
so
on,
that's
inescapable.
S
So
that
fact
we
have
to
to
be
clear
about,
but
I
think
if
you
look
at
it
from
the
ITF
perspective,
that's
what
we
also
determined
last
time
is
the
healthiest
way
forward
at
the
moment
and
then
in
the
end
we
can
say
see
what
what
parts
of
your
work
will
be
needed
and
could
be
incorporated
into
the
5g
Berk.
So
I'm,
not
saying
we
shouldn't
coordinate
but
I
think
the
time
for
coordination
is
very
short.
So
therefore,
I
appreciate
the
approach
you're
doing
here.
Thank
you.
O
Yeah
I
must
say
that
I
agree
to
many
of
your
comments.
So
it's
not
a
question
and
I
also
acknowledge
that
a
transport,
a
slice,
is
also
something
that
we
need
to
look
into.
I
just
say
that
the
management
and
alteration
is
something
more
holistic,
something
that
you
need
to
have
consistent
approach
end
to
end,
and
they
don't
see
that
for
management
and
orchestration
point
of
view.
You'll
have
different
approaches
in
the
coin
to
transport
and
they
in
the
access.
O
T
Gre
Arkham,
thank
you
for
this,
and
this
is
an
important
topic,
it's
dear
to
me
as
well,
but
I
think
you're
describing
this
sort
of
an
you
know,
largely
in
the
same
approach
as
we
took
in
in
the
previous
ITF
sort
of
top-down
that
describe
the
concept
and
then
you
know
keep
describing
what
what
pieces
it
actually
needs
and
it's
useful
concept,
but
the
concept.
This
is
not
entirely
new.
It's
you
know
it's.
It's
probably
going
to
depend
on
several
other
technologies
and
and
concepts
as
well,
and
there
are
many
existing
or
under
development.
T
I
would
actually
like
to
advocate
also
thinking
about
this,
not
just
from
the
top
down,
but
also
bottom
up,
like
what
do
we
have
and
which
one
of
those
things
actually
may
need
some
enhancements,
I'm
actually
working
with
EF
contour.
On
that
question,
we're
not
quite
done
yet
we're
trying
to
get
to
a
presentation
on
on
Thursday
in
the
routing
area
working
group.
Maybe
you
can
join
us
there
for
that
and
have
a
discussion
we'll
see
how
far
we
get
we're
trying
to
publish
the
document
before
this
idea
failed
to
get
to
the
end.
T
It's
just
just
then
and
I
think
the
data
models,
internal
data
model
describing
a
slice
or
a
slice
service,
or
you
know
some
of
the
components,
is
it's
one
obvious
answer
that
we
will
need
to
work
on,
but
even
there
you
have
this
question
of.
How
does
that
relate?
If
we
do
some
data
model,
how
does
it
relate
to
other
data
models
that
we've
had
done
in
various
ITR
working
groups
already
and
and
of
course,
then,
in
the
other
other
parts,
so
I
think
that's
that
that
work,
that
we
have
to
do?
What's
the?
T
T
U
I
generally
have
a
yeah.
It
was
always
the
same.
I
generally
have
an
issue
with
the
term
common
information
model,
because
you
never
the
read
and
never
knows
to
whom
it
is
common
or
from
which
perspective
it
is
common.
It
common
is
a
general
word
or
generic
word.
You
can
use
for
everything,
so
you
probably
need
to
give
a
more
precise
title
to
it
to
be
able
to
know
what
it
is.
U
So,
as
you
probably
know,
NFV
in
general
is
in
standard
development
already
many
years,
and
there
are
different
Steel's
out
there
working
on
information
models
and
they
have
defined
such
basic
elements
of
those
information
models.
Already
some
of
them
are
really
substantial.
I
would
like
to
propose
to
use
them.
Others
are
also
there
which
need
to
be
kind
of
harmonized.
So
are
you,
as
I,
didn't
see
any
sign
in
your
drafts
that
you
are
going
to
cooperate
or
use
an
existing
information
model
as
the
basis
of
your
model
or
built
on
top
of
it?
R
Now
we're
more
than
happy
to
buting
models
based
on
existing
technology.
Just
like
Jeff
said
Jerry
said:
there's
a
lot
of
it
within
a
civil
or
outside
incl
they're.
All
so
many
existing
technologies
or
data
mode
or
different
kind
of
model
that
can
be
can
be
referred
to
to
be
built
on
to
have
these
well
I
still
prefer
common
information
model
because
I
have
really
not
go
through
that
slide.
The
common
information
model
is
technology
nonspecific.
R
So
that's
a
slight
level
description
and
your
concern
of
you
know
you
have
you
have
to
have
specific
type
of
models
that
you
can
use
to.
You
know
guide
your
underlay
technology
to
initiate
your
dedication,
then
that's
you
know
the
mapping
part
and
that's
what
we
call
network
configuration
model,
and
that
is
you
know
your
concern
of
the
specific
ones
as.
U
E
R
You,
okay,
I'll,
get
really
quickly
so
use
cases
only
two
slides
of
use
cases
you
see,
as
it
doesn't
really
change
too
much.
We
we
take
out
those
and
release
it
use
case
and
we
add
one
more
which
is
categorized
in
the
customisation
group.
So
we
basically
the
use
cases
are
divided
to
three
different
type,
which
is
the
customization
resource
assurance
and
new
technologies
and
in
fact,
I'm
have
a
look
at
it
and
leave
your
comments
in
the
mailing
list
and
then
a
solution
based
ones.
R
R
He
calls
you
can
either
use
a
finer
granularity
of
the
description
in
the
IETF
domain
or
you
can
use
a
bigger
granularity,
a
rougher
granular
granularity
information
model
with
the
same
level
of
abstraction
in
the
cross
segment,
slice
manager,
but
methodology
are
the
same,
so
they
they
all
give
you
a
visualized
network
slice
and-
and
it
is
the
middle
part
or
middleware-
to
map
your
service
delivery
model
to
the
underlay.
A
specific
network
configuration
model
and.
R
D
R
About
that,
so
yes,
this
is
the
information
model
aligned
with
the
components
I
talked
about
in
the
problem
statement
and
then
the
last
one
interconnect.
This
is
the
the
second
solution
based
graph
we
have
so
we
have
visualized
a
extendable
feature
of
network
slicing
management.
Where
you
can.
You
know
how
this
kind
of
recursive
a
management
profile,
treating
a
sector
of
your
neck
slice,
a
subnet,
so
with
this
recursion
you
can
create
or
something
and
connect
them
with
interconnect
to
create
a
end-to-end
out-science,
of
course,
this
end
and
is
within
the
working
scope
in
IETF.
R
R
S
S
E
S
R
Depends
and
it's
the
name.
S
J
V
Alex
galleys
from
a
heuristic
origin
I
just
want
to
make
comment
in
somehow
clarifying
previous
speakers
yeah.
Not
you
one
is
that
I.
Don't
think
that
this
working
group
is
trying
to
create
a
common
Universal
information
model
across
all
the
seven
separately
defined
by
standard
bodies.
Information
model
which
exists
today.
The
one
which
is
created
here
is
only
for
the
use
in
a
context
of
network
slicing,
which
is
specific
and
to
be
practically
used
and
information.
V
Good
model
is
as
good
as
it
is
used
and
clearly
such
information
model
for
network
slicing
could
be
used
in
orchestration
mark
and
management
and
few
other
things
and
api's,
and
in
that
sense
it
is
common
to
all
this
area
is
possible,
but
what
we
shall
requires
coordination
second
point
is
I.
Don't
think
that
this
group
fail
to
understand
that
in
the
last
twenty
years
were
a
lot
of
definition
and
work
on
network
slicing,
actually
quite
a
comprehensive
list
of
definition
were
created
last
time.
V
V
T
Yari
Eric,
so
I
think
one
of
the
practical
questions
is
that
if
you're
doing
data
models,
are
they
sort
of
sort
of
guess
employed
that
they're
beasts
only
for
slicing
or
are
they
some
extensions
of
existing,
say
VPN
data
models,
or
what
are
they
I
mean
that
that's,
at
least
in
my
mind
and
unclear
question
at
the
moment,
and
it
would
be
good
to
get
clarification
for
that
somehow.
But
I
actually
came
up
here
to
respond
to
this
discussion
about
working
group
or
both
status
and
name
I.
T
Don't
think
you
should
only
think
about
the
possibility
of
success
being
you
know
we
have
a
bath
and
then
a
working
group
is
created
and
socks.
It
can
also
be
other
things.
It
can
be
that
we
gain
understanding
of
what
we
need
to
do
and
then
we
put
that
work
on
multiple
different
working
groups,
not.
W
T
T
R
You
that's
also
why,
internally,
we
we
didn't
use
our
slices
as
the
name
for
our
you
know,
newest
draft.
We
think
that's
too
broad
and
that
make
people
think
it's
too
general.
There
are
too
many
things
to
do
in
a
single
working
group,
so
we
want
to
just
focus
on
the
management
and
operation
parts
of
it
and
to
make
things
small
and,
as
a
you
know,
a
coordination
kind
of
working
group
to
do
this.
Let's
level
management.
So,
yes,
we
can
have
more
discussion
on.
D
M
M
M
M
W
We
have
six
active
working
cook
document.
Firstly,
the
cutback
alternated
tunnel.
We
change
the
document
type
to
experimental
and
no
completed
the
working
group
procedure
and
sent
to
is
G
on
the
service
model
explained
document.
X
We're
also
going
to
have
a
presentation
on
the
the
yang
model.
Today,
a
chin
will
be
presenting
that
currently
it's
gone
through
yang
doctor's
review
and
there's
been
some
substantive
updates
to
the
model
based
on
that
review,
specifically
around
features
and
we'll
get
a
summary
of
that
in
the
presentation
today.
M
A
couple
of
items
which
are
somewhat
more
active
and
larger
pieces
of
work,
the
IP
fix
BGP
community
document.
It
has
been
through
a
few
revisions.
It
is
not
being
presented
this
time.
Authors
believe
that
the
document
is
quite
stable
it
and
they
think
that
they
have
addressed
the
comments
received
so
far.
Please
take
a
look
at
the
document
and
comment
on
that.
M
A
we
plan
to
issue
a
last
call
for
that
soon
and
we're
also
looking
for
a
Shepherd
for
this
document
if
it
daily
affiliated
with
an
operator
and
who
would
have
interest
in
this
technology
if
somebody
would
like
to
volunteer
for
that,
please
do
either
that
on
a
list
or
approach
working
groups.
Yes,
so
please,
if
somebody
is
interested
in
helping
tisha
to
move
this
document
forward,
please
volunteer
for
becoming
a
Shepherd
with
the
second
large
item
is
tax
tax
otters
are
not
presenting
at
this
meeting.
Once
again,
the
document
has
been
updated.
M
W
Y
Okay,
good
afternoon,
everyone,
my
name,
is
chingu,
so
Muhammad
cannot
make
a
trip
to
Singapore,
but
he
joined
remotely.
I
will
be
speaker
for
this
topic
loudly
okay
matter,
okay,
so
this
topic
is
about
yamoto,
fournette,
and
so
don't.
This
is
what
actually
motivated
by
the
network,
programming
and
automation,
and
we
cover
several
mad
flavor
that
a
wired
deployed,
for
example,
net
for
for
nat64,
Natalie,
V,
T
and
Stella.
This
activity,
before
at
least
six
translation
and
EAM
and.
Y
So
we
actually,
this
chapter
has
been
there
for
a
while.
We
we
actually
make
a
several
revision
for
this
job,
the
before
the
Singapore
meeting,
and
we
chapter
just
we
get
adopted
in
August
since
the
2007,
and
we
try
to
job
this
well
faster
to
to
to
reach
several
people
in
a
community
to
to
have
to
review
from
seven
perspective,
for
example,
in
zero
one
zero
one
working,
we
actually
cover,
say
our
eighty
support.
We
got
a
review
from
leha
and
also
get
some
comments
from
Judy
and
actually
I.
Think
we,
the
design
consideration.
Y
Actually
we
will
consider
to
option
it.
Will
we
support
a
dedicated
perfect,
and
that
means
the
stated
is
xr8.
He
will
be
provided
if
there's
no
dedicated
perfects
that
that
II
can
figure,
then
we
were
required
to
configure
the
metaphor
for
and
then
the
Daedalus
XLT
will
be
applied
on
the
net
for
for
the
second
changes
pout
and
net
net
at
MPD
v6.
For
this,
actually
we
invite
review
front
of
Fred
Baker
and
we
make
some
change
motor
change.
Y
Actually,
for
example,
we
at
the
ingress
interface
equations
in
the
face
for
the
net
device,
and
we
also
improve
the
example
that
that
in
that
is
in
appendix
and
in
zeros
verging,
we
actually
add
the
e/m
support
and
we
so
the
suggesting
actually
from
tall
Anderson,
and
we
actually
may
make
a
revision
to
to
add
these
features.
Support
in
there
for
version
we
at
the
cgn
support,
we
get
a
sufficient
review
from
our
car
loosen
like
a
whim
and
another
evil
is
Christina
and
who
supports
each
year.
We
actually
the
the
change
we
made.
Y
Actually,
we
can
associate
the
policy
with
a
net
instance.
We
also
add
the
net
rim
supporter.
That
means
the
net
function
can
be
associated
ways,
interface
or
worth
instance
in
they
were
foraging.
We
add
the
net
six
for
support,
so
it's
actually
a
rich
if
to
help
to
comment
on
that
away,
actually
make
some
clarification
to
Khafre
how
the
module
to
apply
for
the
state,
honest
and
este
for
and
in
zero
six
version.
We
actually
just
made
some
editorial
change
and
we
request
their
young
doctor
review.
Y
As
chair
mentioned,
we
actually
actually
we
get
some
review
from
your
doctor,
like
you
can,
and
we
have
a
lot
of
discussion.
We
made
a
to
revision,
which
is
some
my
leveraging
and
a
major
version,
and
here
we
will
actually
focus
on
the
major
issue.
We
will
actually
to
discuss
this
open
issue.
Actually,
we
already
made
a
new
revision.
The
nutrition
is
0h
and
we
already
already
posted
and
this
discussion
we
address
written
comments
so
in
early
young
doctor
review.
Y
Actually
there
are
several
issue
we
we
discussed
as
the
first
one
out
for
some
of
the
Pamela
said
we
may
be
optional,
so
we
actually
use
feature
to
represent
these
kind
of
optional
parameter
set.
So
we
make
a
lot
of
changes
to
make
a
good
use
of
this
kind
of
entity.
The
second
change
is,
we
think
we
misuse
some
entity
that
reference
to
work
instance.
Y
So
we
have
a
lot
of
discussion
on
OBS
aw
many
stop
policies
and
we
actually
stray
option
those
the
we
can
use
identity
actually,
but
we
will
avoid
the
struggling
to
define
the
semantics
for
the
very
instance.
The
second
option
is,
we
will
reference
to
metal
instance,
but
we
singer
is
not
a
stable
reference.
Y
The
sort
of
choice
is
the
way
we
were
totally
abandoned,
the
war
for
instance,
but
we
may
leave
for
the
future
to
define
this
kind
of
feature
to
define
these
concerns,
and
but
we
think
in
our
net
model
for
many
use
case
they
actually
for
summer
use
cases
actually
use
verb
instance
for
some
music,
which
they
don't
use,
for
instance,
and
also
some
of
a
reviewer
actually
request
to
support
the
Murphy
incident
so
based
on
these,
so
we
given.
That
is
this.
We
think
we
will
actually
take
the
first
option.
Y
We
will
actually
use
identity
and
so
the
the
current
changing
cover
this
another
issue
is
about
logging.
Actually,
logging
is
actually
has
to
be
defined
as
part
of
these
metamodel,
and
in
this
net
model
we
actually
specify
like
interface
and
IP
address
for
the
log
server.
We
also
specify
what
kind
of
protocol
can
be
used,
for
example,
a
be
fixed
and
a
syslog,
but
you
can
think
for
standard
track
document.
Maybe
is
not
wise
to
actually
leave
the
all
of
these
logged
either
parameter
unspecified
or
not
we're
defined,
so
we
actually
based
on
these
countries.
Y
Caching,
we
to
resolve
this.
We
actually
we
totally
remove
this
log,
a
specific
parameter
to
address
this,
but
we
still
keep
the
login
able
parameter
yeah,
so
another
one
is
how
the
relationship
with
a
mid-match-
actually,
we
I
defined
a
new
section
to
clarify
the
relationship
with
me.
Botnet
actually
I
think
is
the
difference
with
me
plant
actually.
Is
we
also
consider
to
associated
Polly
policy
with
net
function
at
a
similar
to
the
net
emit?
Actually,
we
we
sink
net
me
actually
only
consider
the
performance
monitoring,
but
in
Natalie
FC.
Y
Actually,
they
did
indicate
what
kind
of
parameter
need
to
be
configured,
so
the
net
young
model
will
be
used
to
config
all
these
parameters.
That's
a
similarity
so
also,
there's
there's
some
minimal
change.
X,
for
example.
Some
page
you
need
to
fly
a
flight
rate
faster
so
which
we
actually
add
some
notification
interval
to
rate
animated
these
kind
of
notification
so
that
that's
pretty
much
the
change
we
made.
Actually,
we
already
cover
these
in
the
latest
version,
inversing
page,
so
we
we
sync.
Y
Actually
this
is
John
Walker
with
cisco
juniper
and
also
carries
a
few
review
from
the
local
occlusion,
and
we
also
we
have
a
implementation
in
FDA
our
project
open
source
project,
so
we
singly
isn't
much
it
pretty
much
already
and
a
stable.
We
like
to
request
the
working
with
us:
calm,
Thank,
You,.
Y
Y
G
X
Yeah
just
just
to
be
brief,
but
we
did
get
there
worse,
a
lot
of
reviews,
so
the
the
the
iteration
was
great,
but
it
was
because
we
were
getting
those
reviews,
so
I
I
would
encourage
people
to
read
this
latest
version.
I
found
some
issues
also
them
out
on
the
list,
but
please
review
and
I
I
do
agree.
I
think
going
through
a
last
call
at
this
point
would
probably
be
a
useful
thing
to
your
point.
Early.
Y
X
G
I'll
push
it
as
fast
as
I.
Can
goodness
me,
how
did
you
end
up
with
this
deck.
G
Okay,
just
a
moment
all
right-
these
are
the
it's.
The
wrong
slide
is
the
simple
answer,
so
I'm
just
gonna
step
through
some
of
the
changes
that
we've
gone
to
I'm,
not
going
through
the
whole
deck
that
I.
Thank
you.
We
are
now
complete
with
working
group.
Last
call
and
ietf
last
call
with
the
mud
drop.
I,
don't
have
the
exact
I,
don't
have
the
slides
I
intended
to
have
up
here,
I'm,
sorry
about
that
there.
Let
me
just
go
through
some
of
the
open
issues
that
came
out
of
that.
G
We
had
some
discussions
about
privacy
considerations
with
with
Adrian.
There
were
some
terminology
and
consistency
issues
that
that
improved
with
Adrian
being
the
new
is
he.
He
was
particularly
editorial
towards
this
document,
even
though
it
he
won't
run
through
his
stream
mark.
Nottingham
has
helped
me
with
a
number
of
issues,
most
notably
Clara
clarity
on
the
use
of
HTTP
processing,
which
is
his
expertise.
G
We
pulled
the
masa
server
out
of
the
document
based
on
working
group
last
call
comments.
Now
there
are
a
couple
of
open
issues:
the
the
first
open
issue
that
we
have
and
it's
sort
of
a
big
one-
is
that
the
we're
normatively
a
dependent
on
the
net
mod
Akal
model
that
that
model
has
been
went
through.
The
last
call
its
fourth
I
think,
and
there
are
some
open
issues
Christian
raised
in
the
net
mod
working
group,
I'm,
hoping
that
he
will
close
those
with
the
authors
very
soon
by
making
some
proposals.
G
But
that
means
that
there
will
be
some
changes
to
the
model
to
the
resultant
missed
an
she
ation
in
Jason
for
mud.
My
proposal
is
to
pause
at
least
for
a
little
while
to
let
them
try
to
fix
their
wagons
and
if
they
don't,
then
we'll
take
further
steps
come
and
we'll
come
back.
I'll
come
back
to
you
for
further
steps,
but
I'm,
hoping
that
all
that
is
really
necessary
is
that
we
take
into
account
their
changes.
I
regenerate
the
examples
in
the
draft
and
and
life
is
good.
G
Now
there
are
two
or
three
other
issues
that
are
open.
Mark
Nottingham
would
like
the
version
number
to
come
out
of
the
URL
and
go
into
the
model
so
that
it's
represented
in
Jason.
The
good
news,
apparently
about
the
good
about
that,
is
that
it
apparently
it
conforms
to
some
sort
of
best
practice
within
the
the
web
community.
The
bad
about
that
is
it.
G
Will
fire
forever
tie
us
to
Jason,
at
least
until
we
do
a
next
version,
which
specifies
some
other
extension
model,
so
I
propose
to
move
this
draft
forward
if
nobody
really
cares
about
being
forever
tied
to
Jason
that
we
just
live
with
that
and
say
okay
we'll
commit
to
that
for
for
for
the
foreseeable
future
and
I
think
that's
the
easiest
way
forward.
If
anybody
has
an
objection,
I
think
now
we're
on
the
list
soon
is
the
best
thing
to
address
that,
and
now.
G
J
H
G
G
G
G
J
G
X
G
Well,
I've
talked
to
one
or
two
implementers
and
they're
like
okay.
This
actually
simplifies
things.
Sometimes
if
they
mean
some,
sometimes
they
say
yeah.
Okay,
simplifies
things
in
some
way,
I,
don't
think
people
really
care.
To
be
honest,
though
these
are
relatively,
you
know,
the
only
issue,
I
think
we
would
see
and
the
only
ones
that
that
would
see
it
would
be
people
who
are
trying
to
look
well
well
into
the
future
as
to
whether
somebody
wants
to
translate
all
this
into
C
bar
instead
of
Jason
and
I.
G
G
G
M
But
your
audio
is
really
poor
quality.
Maybe
it
will
improve
with
time.
Could
you
please
try
speaking,
is
to
train,
codecs
and
and
and
buffers
and
other
things.
M
M
M
G
Z
Z
Z
Wdm
system
use
the
multiplexer
as
a
transmitter
to
join
the
establish
signals
together
and
did
multiplexer
are
just
resist
the
receiver
to
wisdom,
a
passion
so
touring
the
verb.
A
Blas
division
service
running
network
data
is
consistently
generated
from
the
web
last
division
devices
and
you
can
reflect
the
process
of
service
learning
and
service
to
the
motivation.
The
motivation
of
this
script
has
two
minutes.
First,
why
is
in
the
case
of
traditional
web
last
division
service?
The
custom
customer
is
a
customer
to
handle
the
network
pair
of
the
service
interruption.
Z
Second,
is
we
know
the
test
statistic
or
critical
list
of
network
data
cable
operator
to
judge
the
10-pounder,
whether
the
this
is
abnormal
or
normal?
All
the
service
is
in
whiskey
or
healthy,
so
they
go
as
three
three
points.
The
first
one
is
illustrated.
The
requirements
of
navigator
use
the
two:
we
evaluated
the
performance
of
webblock
division
service
and
you
must
register
different
application
scenarios
of
network
extender
and
a
second
we
are
presented.
Some
existing
problem
of
learning
network
together.
Z
Next
type
is
so
I
will
introduce
a
chappie
item
terminology,
so
the
tepee,
our
terminology,
is
coming.
You
stood
in
the
HU
under
the
est
I
organization,
so
it
can
be
used
as
the
operational
state
of
the
networker
device
link
on
the
head
of
the
protocol
in
the
network.
So,
in
general,
the
network
of
KPI
present
steady
state
the
changes
with
good
network
ecology.
While
your
choose
the
transition,
the
state
changes
the
characteristics
when
there
is
another
of
the
fair
or
abnormal
state.
Z
Let
me
look
status,
so
we
summarize
the
secret
quiz
mystic
of
the
network
data,
the
subject.
Something
is
the
object
to
be
made
and
it
has
the
mod
form
for
properties
from
dependent
machines
and
the
subject
may
have
one
or
more
major
values
and
it
available
corresponds
to
a
specific
indicator,
and
each
report
of
the
mayor
value
will
have
a
temp
stamps
attribute
that
you
indicate
is
time.
Next
time
is
so
here.
He'll
win
goes
the
Childress
cast,
because
when
is
the
a
land,
an
inanimate
detection,
so
it
is
I,
didn't
identification
of
items.
Z
Even
all
of
the
machines
wish
to
not
Kabam
to
expect
pattern
or
other
items
in
data,
so
the
typically
the
anonymous
items
we
all
trusted
translate
to
send
some
kind
of
problem,
such
as
the
optical
optical,
not
lay
a
problem
for
the
networker
equipment
performance
Alon
amis
multiple
features
are
usually
extracted
from
can
here,
data
ok,
such
as
time
the
value,
frequency
and
then
other
key
factors.
So,
for
this
scenario,
network
appear
data
include
includes
a
such
as
a
PCB
f.
Z
This
is
a
short
term
for
forward
II
error,
correction
coding
before
a
real
cracking
under
the
input,
optical
power
and
so
on.
So
this
is
the
sticker.
Data
can
be
for
the
user
to
detector
detector.
The
web
last
revision
service
abalone
or
improve
the
accuracy
rate
for
this
direction
and
a
second
is
the
risk
exists
assessment.
So
you
this
use
case
is
C
is
similar
to
the
al
animate
detection.
However,
an
Nanami
detection
is
Kaku
is
network
force
and
failure
that
already
happen
under
the
risk
assessment
is
cope
with
networker
risk
and
have
not
happened.
Z
So
this
is
a
change
of
the
two
newest
case,
so
there
are
two
ways
you
obsessed:
the
net
of
the
risk
is
a
single
heavy
ice
coating
and
the
multiple
casts
coding
and
single
scrolling
strategy
is
used.
A
score
of
a
single
KPI
to
assess
the
network
twist
also
refer
if
the
device
is
the
monitor
is
monitored
by
Samrat
separately
kpi's.
The
risk
should
be
analogous
to
by
the
integration
of
this
KBS
cause.
Okay,
okay,
so
you
say.
Z
Z
Z
So
after
they,
after
the
three
dimensions
of
caviar
under
system,
the
console
responding
scores
are
calculated,
so
the
main
core
of
the
abrasion
or
process
is
assigned
the
different
ways
of
the
three
dimensions.
Okay,
next
scientist:
this
is
a
multi
KPI
scoring
Oh.
If
a
device
is
the
monitor
pile
several
key
KPI
the
risk,
it
should
be
an
ancestor
by
the
integration
of
this
caviar
sauce
and
now
we
can
see
the
is
the
formula
of
the
of
the
wedding
first
process
and
the
way
in
the
right.
Well
figure
we
have
there.
Z
We
have
the
two
KPI
with
integrated
is
to
caviar
to
obtain
the
final
final
networks
store
next
phase,
so
we
we
we,
this
is
the
our
roster
Styles
under
way.
Present
is
obvious:
boobers
issues
how
to
Mirchi
data
from
different
time
periods
in
the
press
of
a
data
collection.
The
teleTracking
period
of
the
Sam
KPI
may
be
different
from
each
other,
for
example
from
multiple
domain
deployment
service.
The
remedy,
the
dependent
connection
para
poner
devices
such
as
xxxii,
are
families
as
well,
so
we
here
to
welcome
everyone
to
use
such
havoc.
G
Hyatt
Elliott
first
thanks
for
presenting
a
drop
and
for
your
patience
with
dealing
with
the
AV
issues.
It
two
comments
come
to
me
immediately
to
mind.
One
is
extremely
superficial,
which
is
that
you
seemed
I'm,
not
sure
if
you're,
actually
using
2119
language
in
the
draft
and
I,
don't
think
you
really
intend
to
for
this
purpose.
The
second
is
more
substantial,
which
is
that
I
I
don't
quite
know
what
you
want
to
do
with
this
work.
G
Z
M
M
M
Might
be
that
we
have
again
at
the
communication
problems
or
something
this
will
be
taken
then
to
the
list.
So
thank
you
again
for
presenting
this
and
with
this
presentation.
Officially,
the
agenda
of
the
op
cwg
is
over
this
one
open
and
that
item
open
mic.
Would
anyone
have
anything
to
say
at
open
mic.