►
From YouTube: IETF103-OPSAWG-20181106-1610
Description
OPSAWG meeting session at IETF103
2018/11/06 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
Okay,
that's
a
good
story,
hello.
Everyone
welcome
to
the
opposite,
apogee
anders
and
the
absurd
average
nobs
aerial
meeting
and
before
we
start.
Please
make
sure
you
understand
those
important
legal
issues,
basically
or
your
contributions
to
IETF,
like
your
video
audio
draft
need
to
follow
the
important
legal
issues
and.
B
This
is
a
welcome
to
the
opposite:
obligee
meet
him
first,
and
this
is
a
child
by
Kara
and
the
Joe
and
the
pollution
is
circulating.
Please
write
on
your
name
so
that
we
can
get
the
room
with
rice
ice
next
time
and
before
we
really
start,
we
need
Java
spider
and
the
minions
taker.
Is
there
a
new
volunteer?
C
So
the
first
step
is
mud.
The
mud
manufacturer
usage
description
document
is
currently
in
the
RFC
editor
queue
it
is
pending.
It
is
on
a
missing
ref
state.
Pending
the
ratification
of
the
ACL
yang
model.
That's
in
net
mod
I
spoke
with
Mahesh.
One
of
the
authors
that
is
is
pending
one
more
discuss,
which
should
clear,
I'm
hoping
shortly
he's,
provided
one
more
update,
some
updated
text
so
we're
waiting
on
that
to
to
go
through
I'm,
hoping
like
I,
said
it
happens
quickly.
C
The
GNAT
yang
model
is
currently
in
the
RFC
editor
queue
so
again,
hoping
that
one
also
ratifies
the
tack
acts
draft
went
through
working
group
last
call.
We
did
get
some
comments
that
the
author's
are
going
to
address
with
an
updated
draft
I'm
going
to
act
as
the
document
shepherd
for
that
and
write
it
up
again.
That
is
the
intent.
There
is
the
informational
draft
to
describe
how
tac-x
is
currently
implemented.
B
We
have
the
IP
fix
the
PGP
community
document.
This
one
contains
the
worst
info
idea
and
it
also
has
resolved
all
the
comments
from
the
last
call,
and
we
stand
it.
The
truth
is
still
for
publication.
As
to
the
as
to
the
eighties
request,
we
wave
down
an
additional
proofreading
and
thanks
Andy
for
the
warrant
here.
B
D
D
The
motivation
none
of
the
currently
defined
customer
service
model
and
service
delivery
model,
discuss
how
to
decompose,
end-to-end
VPN
service
across
multiple
domain,
environment
and
segmented
tunnel
or
segmented
VPN
service
in
each
domain,
or
composed
segment
VPN
service
into
one
m2
and
VPN
service.
The
composite
VPN
requirements
have
been
briefly
discussed
and
in
in
drafting
ops
working
group
composed
the
VP
MSM
requirements,
its
automated
VPN
service
delivery
across
multiple
operators,
and
this
is
not
practical.
Since
segmented
repair
information
may
not
be
available
using
a
single
management
system.
D
D
And
so
we
have
a
layer,
2,
VPN
service
and
layer.
2
VPN
service
from
offered
service
portal
requires
coordination
between
two
different
department.
In
the
same
same
operator,
the
limitation
in
multi
domain
VPN
deployment
case
customer
service
model
to
smoke
network
visibility
to
like
a
topo
in
operator
domain
and
cannot
provide
service
decomposition
in
different
domain
through
unified
interface.
So
the
proposal
is
to
define
the
compose
VPN
model.
D
So
the
modern
design
we
have.
The
the
access
point,
use
the
service
access
point
for
connectivity
service
segment
between
any
two
domains:
the
segment
segment
VPN
the
VPN
deployment
information
in
each
domain.
So
we
have
two.
In
this
example,
we
have
two
segmented
VPN
segment,
VPN
one
min
segment,
VPN
two
and
the
composed
VPN
provides
the
M
to
M
VPN
deployment
information
across
multiple
domains
and
can
be
met
in
to
connect
from
layer
3,
a
SM
to
layer,
2
SM,
with
additional
operational
cost.
D
So
this
is
this:
is
the
model
overview
in
the
we
have
a
young.
The
composite
VPN
is
is
divided
into
two
models.
The
one
is
the
IDF
compose
VPN
s
service.
This
is
the
global
parameters,
an
essential
component
of
a
kokum
of
a
composed
VPN,
the
ITF
segment,
3
p.m.
it's
per
domain
segment,
VPN
parameters
and
associated
access
point,
its
parameters
that
are
used
to
connect
to
the
pure
device
or
domain.
The
relationship
between
the
relation
between
the
composed
VPN,
this
Agreement
BPM
access
point.
D
So
a
composed
VPN
is
composed
for
at
least
one
access
point
in
at
least
one
segment.
We
pn
a
segment
VPN
under
segment
repair
and
in
list
is
composed
of
at
least
one
access
point.
So
the
model
is
access,
boring,
a
segment
VPM
in
the
compost,
VPM
and
here's
the
example
and
what
we
have
been
emphasized
there
is
that
we
received
the
I,
the
VPN
ID
the
modes
and
the
see
mode
of
that.
So
we
see
that
the
connection
between
the
customer,
the
the
PE
and
the
ASB
are
in
this
model.
D
We
think
this
is
something
that
we
need
to
in
order
to
provide
also
this
capability
to
describe
a
composed
VPN
that
they
enter
and
VPN,
and
we
hope
we
can
start
to
have
it
as
a
mission
document
to
address
this.
This
specific
architecture
of
one
operators
and
multiple
domains
inside
that
with
the
operator
Network.
F
Randy
Bush
IJ
anarchists,
so
the
problems
with
the
first
document
were
things
like,
inter
provider,
authentication
and
unification
of
endpoints.
So
now
we
just
have
one
provider
with
different
departments:
cost
allocation
describing
and
provisioning
with
privacy
constraints
across
the
different
entities,
etc.
So
now
we
just
call
it
one
company
and
that
solves
all
these
secure.
F
D
D
The
question
is
whether
it's
it's,
we
see
first,
as
the
use
case,
the
use
case
of
having
one
service
provider
that
has
multiple
departments.
Each
of
them
has
their
own
management
and
they
want
to
just
do
to
to
be
able
to
describe
this
this
solution.
We
understand
that,
in
order
to
go
to
the
multiple
domain,
it's
a
different
problem.
It's
a
different
requirement.
D
C
C
It
was
a
very
tiny
draft,
a
very
high
level,
very
abstracted
and
the
points
he
was
raising,
or
he
raised
then
and
I
think
and
again
not
putting
words
in
his
mouth
around
how
you
deal
with
even
interdepartmental
security,
authentication,
authorization,
billing,
I,
think
just
putting
a
gang
model
over
some
of
those
things
and
creating
a
or
redefining
what
a
domain
is
doesn't
necessarily
address
some
of
those
shortcomings,
and
you
you,
your
request
or
your
ask-
was
about
adoption
and
milestone
work.
I
I
would
ask
the
working
group
how
many
people
have
read
this
draft.
C
What
this
is
not
the
2016
draft
and
I
have
not
seen
a
lot
of
feedback
on
this
particular
revision
of
it.
So
I
I
would
ask.
Is
this
something
that
the
working
group
has
has
read
I'm,
seeing
one
I'm
seeing
two
hands,
I
read
a
few
and
III
have
not
seen
a
lot
of
substantive
discussion
on
this,
and
certainly
nothing
that
addresses
the
issues
that
were
brought
up.
That
might
still
be
pertinent
back
in
the
2016
version
of
this
text.
I'm
known.
F
For
being
inarticulate,
so
let
me
try
again:
the
problems
exist
period
when
there
are
multiple
entities
when
they
belong
to
the
same
corporation,
whether
they're,
multiple
backbones,
whether
they're,
multiple
ISPs,
etc.
You
have
authentication
privacy,
etcetera,
etcetera
and
those
need
to
be
covered.
I'm,
not
saying
it's
impossible,
I'm
saying
it's
not
there.
D
I
agree
to
another
the
question
that
the
question
that
we
have
on
that
is
whether,
if,
if
I'm
a
service
provider
and
I
have
a
connectivity
between
my
metro
network
and
my
core
network
and
I
want
to
describe
this,
to
be
able
to
define
just
a
VPN
and
to
and
VPN
based
on
the
assumption
that
they
are
connected
and
they
are
connected
by
default
by
definition
by
the
service
provider.
They
provide
this
link.
D
So
the
way
it's
going
downward
to
to
do
the
the
the
orchestration
of
the
difference
of
the
separate
segments
is
part
of
the
just
goes
to
to
to
to
to
these
two
different
orchestrators.
That
does
this
VPN
definition
that's
all
and
that
that's
what
we
expect
to
do
in
this
case.
I
understand
it.
If
you
want
a
more
general
problem,
you
need
to
address
this
issue,
so
I
I,
don't
know.
B
B
G
One
network
and
this
draft
was
initially
presented
in
last
meeting
by
channel-to-channel
Telecom,
based
on
their
network
deployment,
experience
and
also
in
last
IETF
meeting
Oh
nog,
which
is
an
enterprise
community,
also
proposed
to
define
the
service
model
so
based
on
the
owner
service,
modeling
and
also
corresponding
ITF.
As
the
one
related
jobs.
We
changed
our
jobs
to
add
to
adapt
to
more
common
as
the
one
definition
and.
G
Here
is
our
understanding,
although
IETF
has
defined
the
base
with
Ian
and
but
it
peers
that,
as
the
one
has
more
functions
than
the
defines
AE
based
with
Ian,
for
example,
in
spring
working
group
as
a
fro,
sd1
assumed
a
sea
of
sty
and
could
be
attached
to
internet
or
am
choice
network.
That
is
a
different
than
the
previous
sea-based
hpm,
because
sea
bass
with
Rypien
is
supposed
to
link
to
only
to
internet
or
antelope.
G
They
have
only
one
when
access
and
the
other
thing
is,
si
can
make
l3
to
our
seventh
flow
classification
and
do
the
steering
the
flow
based
on
different
SLA
to
different
paths
and
also
in
best
working
group.
A
secure
layer,
3
VPN
has
been
defined
and
that
job
specify
a
C
CPE
term,
because
C
can
offer
by
granularity
were
to
network
that's
end
of
APN
there's
another
multi-tenant
network,
and-
and
apart
from
these
things
and
also
security
working
group
are
working
on
the
a
base
VPN.
I
advanced
a
at
least
a
Caribbean.
G
That's
controller
based
episode,
VPN,
so
based
on
our
analysis,
what
we
think
we
propose
to
define
the
st1
VPN
service
is
not
only
based
on
the
sea
bass,
VPN
already
defining
IETF
in
4110,
but
also
the
work
going
on
in
ITF.
That's
the
hybrid
one
connection,
different
paths
flow
steering
based
on
the
SLA
and
also
multi-tenant
separation
inside
when
so
that's
a
the
trapped
I
I
mentioned
earlier.
G
So
here
is
a
the
sd1
web
here
service
overview
based
on
we
analysis
earlier
so
sd1
VPN
service
could
include
two
or
more
sites
and
each
site
could
have
one
or
more
see
device,
see
devices
and
each
device
could
connect
to
one
or
more
when
network
that
is
m-class
network
or
Internet
or
it
could
be
5g
network.
So
that
could
be
the
case
and
in
each
as
the
one-way
pian
there
could
be
one
or
more
subway
pian,
and
each
subway
in
has
own
topology
and
policy.
G
There
is
a
oh,
no,
so
so
that's
a
imperious
lights.
I
would
give
the
overview
of
this,
and
that's
the
estimate.
Series
we'd
like
to
model
we
like
to
to
define
and
the
last
meeting
ona
proposal
propose
the
service
model
definition
requirements
to
IETF
they.
What
they
propose
in
their
life
is
an
enterprise
network.
There
could
be
two
Wender
as
the
one
controller,
so
in
that
way,
they're
the
two
vendor
controller
domain
needs
to
be
intercommunication
to
provide
into
communication,
and
they
don't
want
you
to
touch
like
their
one
domain
service
definition.
G
They
propose
to
define
the
gateway
service
to
to
provide
the
two
different
vendor
domain
to
to
a
vendor
domain
reach
ability,
that's
gateway
service
and
the
other
one
is
the
past
management.
Also,
that
means
flow
classification
and
different
path:
selection
based
on
different
SLA,
so
based
on
the
our
analysis
earlier
in
the
sty
service
model
we
define
earlier
and
that
its
own
arc
requirements.
G
We
think
we
see
there's
a
lot
of
common
commonality
between
these
two
service
model
and
and
like
the
the
connectivity
service
and
huiqian
subway
pian
configuration
because,
but
they
use
different
concept
because,
like
own
and
use
segmentation,
but
we
here
use
a
similar
concept:
English
3sm
so
and
but
most
thing
are
common.
So
we
think
our
model
is
used
in
the
customer
service.
Size
service
model,
that's
an
abstraction,
so
then
the
owner
they
try
to
define
the
Ox
traitor
and
vendor
controller
interface
service
model.
G
G
H
It's
not
put
donors
Equinix.
Speaking
about
anything
idea.
Listening
to
how
you
position
this,
it
sounds
that
you
have
created
something
which
you
potentially
have
already
deployed
of
your
customers.
Now
you
want
to
push
that
back
to
the
hoanib,
saying
that
this
is
the
right
way
to
do
the
things,
whereas
from
own
oxide,
the
agreement
to
work
with
IDF
was
that
they
will
provide
the
requirements
aggregated
from
the
user
base
and
then.
I
G
J
J
J
That's
nearly
complete,
there's
just
a
very
rough
like
skeleton
of
a
yang
model,
and
so
I
think
it
might
be
a
good
idea
to
see
about
aligning
not
just
on
the
picture,
but
maybe
on
the
terminology
and
to
see
if
we
could
have
one
yang
model.
That
kind
of
okay
meets
both
use
cases.
Okay,
we
will
have
that
I,
don't
think
it
would
address
the
onna
use
case
because
they
are
very
specific.
You
know
explicitly
looking
for
a
different
solution.
Yes,.
G
I'm
just
saying
that
ona
proposed
their
intern
when
their
domain
definition,
but
actually
because
they
don't
give
the
one
domain
as
the
one
functionality
definition.
Then
there
is
a
gap
between
it,
because
if
there
is
a
no
one
domain
within
functionality
definition,
then
how
can
you
get
the
inter
domain
functionality?
So
that's
a
gap.
We
we
think
we
can
provide
a
look
I,
think
not
the
exclusive
region
components
in
there.
G
B
Not
just
for
this
draft
and
we
just
have
something
about
the
service
models
and,
and
since
this
is
also
another
source
model,
my
question
is
to
the
ID.
It's
there
and
I.
Think
the
the
source
model
is
not
usual,
not
as
usual
as
other
device
models
in
ATF,
so
for
the
ad
to
have
hanging
guidelines
or
requirement
for
the
service
models.
H
Well,
just
to
clarify
what
kind
of
requirements
are
you
looking
into
that?
Shall
this
working
group
work
on
something
along
those
lines
or
not?
I
would
say.
Definitely
yes,
there
is
so
industry
overall
needs
this.
The
question
is:
which
way
should
the
work
be
done
and
structure
requirements
coming
from
actual
users
of
the
technology
and
the
work
gets
done
based
on
those
requirements
or
taking
an
implementation
and
trying
to
standardize
and
push
that
to
the
rest
of
the
world?
The
second
direction
seems
to
be
not
right,
whereas
the
first
one
is.
C
G
G
H
F
C
You
have
this
escape
hatch,
that
and-
and
that
goes
to
the
questions
that
I'll
raise
on
the
list,
because
we're
running
short
of
time
is
I'm,
not
certain.
How
well
your
use
case
would
one
of
the
things
you
stated
early
on?
Is
you
wanted
a
generic
or
you
wanted
to
quantify
sd1
as
a
thing
and
I
think
this
might
be.
Your
approach
might
be
very
specific
to
a
use
case
or
set
of
use
cases
and
may
not
cover
a
broader
s,
deal
and
sense.
So
I
think.
Maybe
we
need
to
scope.
C
G
G
But
right
now
this
working
group
already
defined
the
Tagus
protocol
analyzers
also,
while
used
authentication
protocol.
So
we
think
it's
quite
useful
to
define
our
Texas
client
young
model
based
on
the
text
protocol
to
augment
the
current
system,
young
model
and
this
draft
was
initially
proposed
in
that
mode
and
that
mode
working
group
suggests
and
suggested
ours
to
change
to
this,
to
ops
working
group
to
work
on
that,
because
this
is
this
working
group
provide
better
expertise
in
Texas
protocol
definition.
So
we
sings
last
meeting.
G
We
restructured
our
modeling
based
on
the
comments
received
from
the
nav
mode
list.
So
for
now
we
define
the
Texas
llamo.
You
have
the
this
structure
and
it
has
a
global
parameters
that
could
be
applied
to
servers
all
the
server's,
all
the
tackle
servers
and
then
each
text
server
could
have
its
individual
configuration
parameters
like
server,
name,
server,
IP,
port
k
and
single
connection
model.
That's
all
be
defined
in
protocol
and
also
we.
G
So
this
is
a
the
current
status
of
this
model
draft
so
and
in
this
meeting
we
also
received
some
other
comments
from
the
Juniper
and
they
proposed
us
to
change
our
modeling
according
following
the
system,
modeling
radius
design.
So
we
in
the
next
version.
We
would
we
like
to
incorporate
their
comments
and
to
to
get
update
and
we'll
follow
the
radius
architecture.
C
That
was
actually
going
to
be
my
contributor
comment
that
you
seem
to
deviate
quite
a
bit
from
what
the
radius
system
yeah
infrastructure
does
at
the
risk
of
stepping
in
and
again
with
tac-x.
C
Just
a
handful,
maybe
six
like
maybe
of
those
who's
read
it.
What
does
the
or
in
just
a
gut
feel
what
does
the
working
group
think
of
this
work?
Is
it
something
that,
if
we're
going
to
ratify
or
document
tax
as
an
informational
draft,
and
maybe
go
further
and
securing
it,
is
this
worth
having
a
model
to
configure
tax
on
the
client
like
we
can
do
radius?
As
an
author
is
a
or
a
authentication
authorization,
accounting
thoughts.
L
M
Elliott
leer,
the
only
comment
I
would
have
is
which
you
want
to
do.
First,
if
you're
going
to
go
back
and
and
and
modify
tack,
acts
and
create
a
tax
v2
or
a
secure
tax
or
whatever
you
want
to
call
it.
You
can
interviewing
a
lot
of
work
here
now
and
then
any
of
doing
a
lot
more
work
again
later,
and
so
it's
just
an
order
of
operations.
Question
that
I
have.
E
Learn
one
class,
so,
yes,
it
makes
sense
of
a
yang
model
for
any
technology.
The
way
I
tried
to
categorize
this
is
this
like
the
day,
one
day,
zero
day
one
day,
two
right
the
day.
Two
is
something
enqueue
change
many
times
I
can
access
list?
Yes,
it's
up
to
the
require.
Now
this
one
attack
axe
is
something
you
need
to
configure
a
single
time
right.
So
yes,
it's
good
to
have
it,
but
it's
priority
to.
H
N
H
One
commenters
pointed
Vanara:
yes,
you
could
typically
configure
that
once
in
a
lifetime
of
the
node.
But
if
you
instantiate
note
every
10
seconds,
that's
quite
often
now
tax
is
universally
deployed,
radius
is
also
universally
deployed.
The
use
cases
are
different.
Some
some
deploy
diameters
some
might
deploy
something
else.
I
think
what
is
important
is
to
define
the
ITF
system,
its
extensions
fortification,
authorization
accounting
to
have
those
pluggable.
Then,
if
someday,
we
have
tax
version,
2
or
radius
version
27
that
can
be
plugged
into
all
of
this
architecture.
H
C
O
C
We
see,
hopefully
tac-x
move
forward
and
and
bring
in
more
security,
so
I
think
I.
My
gut
tells
me
yes,
the
work
is
valuable,
I
agree
with
and
WOM,
maybe
it's
not
immediately,
but
making
sure
that
we
can
fully
define
or
Express
this
from
a
triple-a
standpoint
system
is
valuable.
Now
what
you
learn
there
could
be
very
useful
for
finding
augmentations.
F
M
All
right
so
I'm
going
to
talk
a
little
bit
today
about
what
we
have
going
on
with
device
onboarding
at
the
I/o
at
the
ITF.
Now
the
vise
onboarding
isn't
going
on
for
many
years,
mostly
because
there's
always
been
a
human
there's,
always
been
a
keyboard
and
there's
always
been
a
display
and
with
IOT
you
don't
have
any
of
that.
So
that's
that's
the
problem
statement
right
there.
M
So
basically
I've
you
this
from
the
enterprise
perspective.
The
enterprise
has
a
bunch
of
questions.
They
want
to
ask
you
know
in
terms
the
administration
under
under
what
is
this
thing?
You
know
you
have
things
like
what
is
the
devices
identity?
Then
you
have
some
amount
of
accountability
that
needs
to
be
to
be
framed
and
then
what
access
doesn't
need
and
is
it
doing
what
it
should
be
doing?
M
You
need
a
correct
network
selection
to
occur.
If
that
doesn't
happen,
then
we
have
big
problems.
Proof
of
ownership
is
a
really
nice
feature
in
that
process.
Did
the
thing
fall
off
the
truck
supply
chain
security?
Has
somebody
monkeyed
with
a
device
in
some
way,
so
we
have
this
basic
concept
that
has
been
developed
here
at
the
ITF,
actually,
which
is
the
voucher,
RTA
T
366.
M
We
like
this
and
basically
it's
a
bag
of
bits
that
are
not
that
are
well
organized,
and
this
one
is
based,
though,
primarily
on
the
assumption
that
devices
will
both
have
and
will
be
able
to
prague
own
up
to
certificates.
So
this
is
what
anima
brewski
uses.
This
is
work
that
was
done
in
the
animal
working
group,
which
is
draft
IETF,
anima,
bootstrapping,
key
infrastructure,
otherwise
known
as
ruski,
and
so
what
they've
done
is
they
say?
M
Well,
we've
created
a
workflow
here
where
the
pledge
that
is
say
the
end
device
goes
and
talks
to
a
switch.
This
is
on
wired
identifies
this
thing
called
a
registrar
which
some
of
us
might
call
the
triple
a
server
OCA
and
at
some
point
or
another.
It
then
sends
a
voucher
request
and
the
Registrar
forwards
that
along
this
is
done
just
using
tcp/ip
and
HTTP
and
using
a
provisional
state
model.
The
thing,
then,
excuse
me,
a
provisional
trust
model.
The
thing
then
the
Registrar
then
towards
that
off
to
the
manufacturer.
M
He
says:
oh
yes,
you
bought
that
thing.
Okay,
so
you
have
mister
registrar,
I'm
gonna,
give
you
a
voucher
that
is
locally
significant
for
you.
You
provided
me
some
information
I'm,
providing
you
a
signature
to
go
back
with
that
in
the
form
of
a
voucher,
and
that
should
be
tunneled
back
to
the
at
which
point
the
pledge
is
in
a
position
to
to
then
go
to
the
next
step,
which
is
to
then
just
do
a
normal,
ESD
transaction.
M
So
this
is
all
works
pretty
well
and
wired.
We
have
some
proof
of
concept
code
and
we've
been
working
with
a
couple
vendors
to
to
prove
it
out,
but
it
has
a
couple
of
issues,
particularly
with
wireless,
and
so
the
first
question
that
we
had
to
address
was:
oh,
you
need
IP
access
in
order
to
do
this,
but
in
order
that,
in
order
to
have
IP
access,
you
have
to
have
network
access,
wireless
802,
11,
I,
know
cram
it
all
in
eat.
Well,
that's
exactly
what
we
did.
M
So
we
created
a
draft
called
draft
Lear
brueski,
which
essentially,
you
know,
carries
the
same
flow,
but
you
don't
need
to
have
already
authorized
the
device
on
so
the
network
in
order
to
do
that,
so
it
breaks
the
dependency
loop,
which
is
nice,
and
you
can
look.
There's
there's
a
I
presented
this
in
EMU
a
little
bit
oh
and
feel,
and
Nancy
can
wonder
that
I
have
I've
drawn
this
up.
M
It's
still
in
early
stages
and
we're
not
yet
asking
for
adoption,
because
we
have
some
questions,
which
is
why
I'm
here
and
the
first
question
we
have
is
what?
If
so,
this
model
works
great,
assuming
that
there
is
some
form
of
sales
integration,
in
which
case
in
which
the
manufacturer
knows
that
a
particular
registrar
is
meant
to
to
receive
a
device.
But
if,
let's
say
as
I
was
telling
my
friend
Dan
before
the
rake
that
the
lomasa
is
a
laid
back
Massa
and
just
as
sure
I'll
let
you
join
no
matter
who
you
are
now.
M
This
leads
to
a
problem
which
is:
if
the
device
sees
network
aids
come
the
company
a
CID
first
and
it's
meant
to
join
a
company,
be
the
wrong
things
happens,
and
not
only
that,
but
company
B
gets
very
little
diagnostics.
Out
of
this
know
what
happened?
So
that's
bad,
so
there's
another
problem,
which
is
what
happens
that
the
Internet's
not
there
and
you
can't
you
can't
actually
access
the
manufacturer-
and
this
is
these-
are
some
known
problems
that
with
ruski
work
now
that
doesn't
mean
brewskis
it
not
valuable.
M
It's
valuable
for
the
use
cases
it's
intending
and
solve,
which
is
on
an
autonomic
computing
and
where
you
can
make
certain
assumptions
when
an
IOT
world-
that's
not
necessarily
the
case.
So
a
good
example
might
be.
You've
got
a
bunch
of
building
components
that
are
going
up
prior
to
the
internet
having
been
installed,
and
maybe
you
have
some
of
your
network
infrastructure
installed
and
you
might
want
to
actually
have
some
form
of
transfer
of
ownership.
So
there
one
of
the
problems
when
the
IOT
space
is.
M
There
are
tons
of
use
cases,
they're
scattered
all
over
the
map,
and
that
leads
to
a
you
know.
If
you
have
order
n
use
cases,
it
seems
that
we
have
order
n
squared
solutions
for
them
which
is
sort
of
bad.
So
one
way
that
we
were
thinking
about
solving
this
problem
is
to
essentially
provide
proof
of
ownership.
M
This
is
all
around
proof
of
ownership
and
out
of
ant,
and
if
you
were
in
the
EMU
working
group
yesterday,
you
heard
a
little
bit
about
this,
but
you
also
heard
a
little
bit
from
the
new
people,
essentially
describing
an
alternative
that
does
the
same
thing
and
which
is
nice
it.
The
idea
here
is
that
you
scan
in
a
label.
You
do
the
normal
voucher
request.
You
pass
both
along
to
the
masa
and
at
that
point
in
time
you,
the
masa,
can
verify
a
proof
of
proof
of
ownership.
M
M
Right
so
then
there's
a
there's,
a
there's,
another
approach
which
is
that
never
mind
the
lomasa?
Let's
just
do
the
proof
of
ownership
and
go
to
the
registrar
and
then
go
and
then
have
the
communication
just
between
the
thing
and
the
registrar
and
never
and
let's
get
rid
of
the
masa,
and
this
is
very
similar
to
DPP.
It's
very
similar
if
you
eat
new,
so
some
very
common
elements
here
across
the
solution
space.
In
fact,
there
I'm
not
mentioning
a
few
of
the
few
other
mechanisms
that
are
around
as
well.
M
The
thing
you
lose
in
this
case
is
that
you
have
to
have
that
label
scan.
You
have
to
have
some.
You
have
to
have
done
the
proof
of
ownership
and
there's
no
possibility
of
doing
some
sort
of
sales
channel
integrations
such
that
things
just
plug
in
and
they
work,
which
is
where
the
masa
server
really
shines.
So
this
is
problematic
in
other
regards
ok,
so
I
made
up
a
little
bit
of
a
table.
I
want
to
start
by
saying
this
table
is
woefully
incomplete.
M
It's
just
the
beginning
and
it's
an
eye
chart
for
those
people
who
don't
like
to
look
at
the
small
small
letters
on
screens.
All
of
these
is
posted
into
the
office
area.
Working
group
content
thing.
So
what
I
really
want
to
focus
on
in
this
discussion
is
the
is
the
column
here
on
the
left.
I
think
I
have
a
pointer
yeah.
So
what
I
tried
to
do
see
here?
I
can't
I,
know
I'm
supposed
to
stay
in
the
box,
but
let's
see,
if
I
can
do
this
right.
M
So
what
I
try
to
do
is
find
sort
of
things
that
people
care
about,
and
this
is
also
well
fully
and
complete.
But
let's
start
with
the
base
assumption,
which
is:
do
you
get
correct
network
selection
and
you
see
a
bunch
of
them
and
this
presumes
by
the
way
so
for
anima?
There's
our
no
sales
integration,
so
all
of
these,
except
for
my
doped-up,
the
manufacturer,
won't,
will
do
the
job
there.
M
Can
you
on
board
without
internet
access?
Oops
you
see.
This
is
where
brewskis
sort
of
is
is
painful
and
it
finds
its
pain
right.
You
get
proof
of
ownership.
That
is,
can
you
tell
if
the
device
fell
off
the
truck
and
is
a
counterfeit
or
is
otherwise
stolen?
So
brewski
provides
for
some
amount
of
proof
of
sale,
which
is
nice,
but
some
of
the
other
things
don't
you
get
and
similarly
do
you
get
supply
chain
security
they're,
almost
the
exact
same
question:
can
you
do
it
hands-free?
That
is
to
say,
can
you
do
this?
M
When
you
have
sales
sales
integration?
Can
you
just
get
things
to
to
plug
in
and
and
work
and
by
the
way,
when
we
talk
about
wireless,
what
does
plug
in
and
work
me?
It
means
round
robin
until
you
find
the
right
network
that
actually
has
your
credential,
though
that
actually
knows
that
you're
supposed
to
be
on
it.
There
are
some
shortcuts.
You
can
do
in
the
I
Triple
E
space
in
this
case,
where
you
might
be
able
to
find
the
right
network
a
lot
faster
than
going
through
a
neat
transaction,
but
in
enterprise.
M
One
of
the
nice
things
we
like
is
EEP
integration
and
I.
Don't
talk
too
much
about
that
today
and
there's
a
reason?
Why
is
it
well
secured?
We
have
a
couple
of
most
of
the
things
are
well
secured
on
there.
You'll
notice
I
have
simple
serial
number
up
there
as
it
as
an
approach.
That's
for
those
devices
where
they
don't
think
they
can
store
one
bit
more
of
information
to
it.
Through
the
manufacturing
process.
I
took
a
small
crack
at
status
and
in
terms
of
you
know
where
I
thought
things
stood.
M
He
type
is
important
because
you
see
that
x.509
there
o
is
what
I
get
a
reaction
to
from
from
some
manufacturers
or
that's
okay
by
me
by
others.
Again,
it's
really
fragmented
space.
You
see
some
asymmetric
cryptography
in
there
with
MIDI
P
P
as
an
example,
and
what's
not
listed
here
is
the
the
animal
working
group
has
done.
Some
work
on
constrained
vouchers,
which
reduce
some
of
the
complexity
relating
to
x.509
and
Michael.
Richardson
has
done
a
lot
of
work
on
that
space,
so
we
have
different
men
of
varying
amounts
of
manufacturing
complexity.
M
M
Each
of
these
has
different
forms
of
manufacturing
complexities
and
different
manufacturers
might
make
different
decisions
and
then
again
we're
thinking
about
devices
that
range
from
you
know
even
smaller
than
light
bulbs
to
to
stupid
little
sensors
all
the
way
up
to
safe
the
milk
robots,
for
instance,
in
terms
of
how
we
want
to
solve
these,
these
onboarding
problems.
So
next
slide.
So
I
tried
to
take
a
stab
at
how
I
view
the
complexity
curves
on
each
of
these
and
I
was
again
thinking
in
the
context
of
Wi-Fi
right.
M
So
pretty
much
if
you're,
if
you're
playing
wife,
if
you're
doing
something
with
Wi-Fi
your
your
table,
stakes
are
pretty
much
doing
something
with
live
wpa2.
There
are
some
devices
that
don't,
but
you
know
there
are
some
table
stakes
there.
Then
there's
different
forms
of
authentication.
You
know:
do
you
have
any
symmetric
keys?
You
have
certificates
and
going
along
that
line,
it
gets
more
and
more
complex
and
then
similarly
for
manufacturing,
you
know
is
it.
Labels
are
at
least
a
little
bit
of
a
pain,
whereas
back-end
Center
in
sales
integration
can
be
a
major
pain.
M
So
a
couple
of
key
two
observations:
I'm
gonna
log
meant
this.
The
this
slide
in
terms
of
what's
here,
I
think
the
key
thing
that
I'm
trying
to
bring
across
in
this
presentation
is
that
we
have
essentially
is
it's
a
well
structured
bag
of
bits
in
the
form
of
this
voucher,
Max
and
Michael,
and
Kant
did
a
really
good
job.
Actually
it
coming
coming
to
this
point.
Alright,
this
is
really
nice.
M
So
there
there's
there's
room
for
a
lot
of
discussion
about
how
to
take
this
forward.
So
it's
really
good
work
and
then,
of
course,
the
other
aspect
of
this.
And
how
do
you
is
how
you
prove
the
assertion?
And
you
know
the
basic
means
by
which
we're
approving
the
assertion
in
brewski,
for
instance,
is
with
a
with
is
with
a
signature
from
the
manufacturer,
but
if
you're
doing
proof
of
possession-
that's
not
particularly,
that
may
not
be
necessary,
and
so
these
are
some
things
that
I
thought
about.
M
So
I
had
a
couple
of
questions
here
right
which
methods
should
we
standardize
one
of
the
thing
one
of
the
reasons
I
got
into
this
is
because
I'm
seeing
a
lot
of
fragmentation
in
in
terms
of
the
space
and
a
lot
of
IOT
based
manufacturers
are
saying.
Well
what
the
hell
guys.
You
need
to
help
us
with
a
little
bit
more
guidance
about
what
the
right
answers
are,
and
so
then
the
question
is:
what
can
they
reasonably
use?
What
sort
of
support
matrix
should
we
develop
over
time?
M
So
these
are
just
some
of
the
drafts.
I
didn't
mention
draft
IETF
anama
constrained
voucher,
which
is
also
well
on
its
way.
There's
also
some
work
that
Michael
has
done
in
six
Tish,
which
I
haven't
put
on
this
slide,
but
should
be
paid
attention
to
and
with
that
I
think
I've
gone
as
far
as
I
need
to
go
in
this
presentation.
Questions
comments
and
here
comes
Randy
who,
by
the
way,
I
want
you
to
know
Randy
I.
Am
you
instigated
part
of
this
discussion?
Can.
M
P
F
Actually,
would
you
put
slide
15
up,
yeah
I
miss
the
row
two
rows,
which
were
the
two
criteria
I
asked
regarding
Brisky,
which
is
what
happens
to
me
when
the
manufacturer
fails
and
what
happens
to
me
when
I
want
to
sell
that
light,
bulb
or
router
or
whatever
it
is
to
Joe
with
a
non-cooperative
manufacturer.
Okay,.
M
P
M
M
P
I'm
just
going
to
talk
about
a
two
2.11
for
a
minute
which
is
where
are
you
I'm,
usually
based?
That's
why
nobody
recognizes
me:
we've
just
completed
some
work
in
82
11,
which
could
solve
some
of
your
round-robin
issues
about
doing
that.
Initial
detection
of
do
I
want
to
do
SSID
a
or
SSID
B,
so
you
might
want
to
have
a
look
at
the
802
11
aq
amendment
that
was
published
in
September.
It
also
has
a
very
lightweight
version
and
I
say
really
lightweight
version
of
mdns
over
11,
but
without
some
security
constraints.
P
M
Q
Q
So
I
think
that
important
thing
is
because
I
bought
lots
of
used
equipment.
I've
tried
to
get
firmware
updates
from
the
manufacturer
for
used
equipment
had
long
conversation
with
salespeople
about
how
I
didn't
want
to
buy
a
new
piece
of
equipment.
I
would
just
like
to
by
a
service
agreement
to
get
the
equipment
and
I've
mostly
failed
with
most
companies
to
ever
do
that.
This
is
without
brewski,
though
any
kind
of
stuff,
so
I.
Q
Think
that
there
are
ranges
of
values
of
equipment
from
light
bulbs,
where
you
simply
don't
bother
to
sell
them
to
your
friends
and
whether
the
manufacturer
wants
you
to
resell
them
or
not,
is
kind
of
moot
the
values
too
low
they're,
not
we're
not
gonna
we're
not
going
to
get
there.
Then
there
are
values
equipment
where
you
know
what
you
pay
several
million
dollars
for
it
you
buy
used
and
damnit.
Q
The
manufacturer
will
support
you,
or
else
you
will
say
bad
things
about
them
and
that
fact
they
probably
have
a
large
amount
of
use
at
least
etc.
Blah
blah
blah
and
they're
used
to
the
concept
that
you
are
going
to
resell.
The
device
except
tunnel-boring
machines,
apparently
are
left
in
the
tunnel
when
they're,
when
you're
done,
they
don't
merge
unless
you're
in
an
ocean
is
11
movie,
yeah,
I,
guess
so.
Okay,
it's
weird
to
think
about
all
these
boring
machines
that
are
under
cities
that
are
just
sitting
there
right.
Q
Maybe
with
you
know,
gigabytes
of
RAM
in
them
or
something,
but
then
there's
that
paid
space
in
between
right.
You
know
how
many
people
have
picked
up
a
Cisco
6500
15
years
ago
and
done
something
useful
with
it
right
and
and
Cisco
didn't
sell
them.
For
you
know,
I
think
it
was
20
years
since
they
were
sold
right
and
I.
Think
that
is
a
really
important
question
that
we
don't
have
a
good
answer
for,
and
but
what
did
you
do
you
plugged
in
a
serial
port?
Q
You
did
not
get
automatic
enrollment,
you
didn't
expect
to
plugged
in
a
serial
port.
You
did
the
stuff,
and
that
was
it
so
in
that
class
of
equipment
we're
talking
about,
can
I.
Do
it
automatically
or
not.
Rather
than
can
I
do
at
all
with
the
light
bulb,
there's
no
serial
port
I
guess
you
can
get
out,
you
can
get
it
from
screwdrivers
and
maybe
find
a
JTAG
port,
but
basically
you're
tough
right.
So
so
there's
that
category
that
did
not
have
anything
without
brewski
or
some
other
enrollment
process.
Q
You
are
screwed,
you
couldn't
do
it
period
right
and
so
that's
a
category
of
equipment
which
is
different
than
the
category
of
high-end
equipment
that
you
resell,
and
there
is
a
space
in
between
where
there's
some
overlap
between
that
right
can
I
sell
my
vacuum
cleaner.
Well,
it's
a
couple
hundred
dollars.
Maybe
it's
kind
of
worth
reselling:
does
it
have
a
keyboard
in
a
craft
part
and
probably
not
that
I
can
find
easily?
Q
So
that
is
an
issue
and
I
really
think
that
we
should
address
it
and
I
and
I
really
spend
a
lot
of
time.
Dealing
with
this
question
of
us
they're
fundamentally,
the
other
part
is:
do
I
want
to
run
a
vacuum
cleaner
in
my
house
with
10
year
old
firmware
or
the
manufacturers
gone
out
of
business.
I
guess
I
can
be
sure.
It's
not
uploading
my
floor
plans.
If
the
manufacturers
gone
in
a
business
but
I'm
pretty
sure
it's
gonna
spread
dog,
poo
or
old.
My
house,
okay,.
I
Q
M
So,
just
by
what
I
won't
answer
you
point
for
point
there,
but
only
to
say
that,
because
this
is
a
pretty
wide
topic
and
because
we
I
think
we
do
have
a
number
of
questions
to
answer,
because
there
are
some
common
architectural
components
across
all
these
things.
One
of
the
things
I
wanted
to
propose
was
to
try
and
take
it
a
little
bit
more
thoughtfully
in
terms
of
finding
those
common
architectural
components
and
writing
them
down
a
little
bit,
even
if
they're
not
common,
even
if
even
if
we
can't
get
the
common
architectural
components.
M
Maybe
what
we
can
do
is
say
well,
here
are
the
functions
that
we
need
sort
of
like
that
table
I
had
up
here's,
how
people
are
solving
for
them
and
maybe
take
the
next
step
and
see
if
we
can
find
our
common
architecture
their
components
in
that
regard.
To
that
end,
there's
a
side
meeting
right
after
this
meeting
right
here
to
begin
that
discussion,
Dan.
M
J
Which
is
fine,
but
one
of
them
was
the
device
learns
which
network
to
join
and
I.
Think
that
if
you're,
if
you
want
to
do
this
four
things
and
it's
break
so
if
you
wanted
the
things
to
be
communicate
over
Wi-Fi,
it
might
be
better
for
the
network
to
discover
the
device-
and
you
know
turn
this
around.
In
fact,
if
you
go
to
the
a
chart
of
all
the
columns
and
rows,
that's
basically
the
way
DPP
works
is
that
the
person
who's
going
to
be
configurate
configuring.
J
This
device
is
the
one
that
starts
all
this
stuff,
and
so
the
the
the
thing
is
just
sitting
there
unproven
and
if
you
have
possession
of
the
that's
the
way,
the
trust
works
that
it
does
have
proof
of
ownership
by
the
way,
but
the,
if
you
have
possession
of
this
device,
then
that's
the
way.
The
trust
words
have,
even
if
you
have
possession
of
it,
you're
allowed
to
configure
it
yeah.
So.
B
R
J
No
there's
no
requirement
that
it
has
to
find
a
network
or
ask
to
round-robin
networks
or
something
like
that,
and
it's
not
going
to
get
provisioned
by
the
wrong
network.
Unless
you
know
it
did
fall
off
a
truck
and
somebody
has
it
now
and
they
possess
it.
And
you
know
it's
it's
not
quite
the
resurrecting
Duckling
model,
it's
a
little
bit
modified
of
that
because
the
guy
configuring
it
has
to
know
something
specific
about
the
device,
namely
its
public,
key
right.
So
and
he
learns
that
by
having
physical
possession
of
it.
M
So
I
separate
possession
from
ownership
there
they're
slightly
different,
which
is
why
I?
Why
Isan,
though
they're
but
again,
I,
wouldn't
I,
wouldn't
harp
on
the
point,
the
the
point
about
whether
the
device
initiates
communication
or
whether
the
network
and
or
whether
some
network,
provisioning
component
initiates
communication
I
think
there
are
as
I
understand.
The
DPP
is
intended
to
actually
support
both
models,
and
the
issue
is
around
power.
Consumption
on
the
device,
as
I
understand
at
least
one
aspect
of
it
and
the
other
aspect
of
it
from
a
DPP
standpoint.
M
Is
that
I
understand
that
the
intent
at
least
is
to
have
multiple
means
by
which
to
provision
the
the
share,
the
the
public,
the
public
key
into
the
it's
a
network
component,
yes
yeah,
so
I
I
have
some
understanding
of
that.
The
again
that
ordering
issue
that
you
saw
in
the
earlier
earlier
slides
that
is
its
it.
Each
each
of
these
mechanisms
will
will
reorder
those
in
some
in
some
different
ways.
So
you
don't
you're
right.
You
don't
have
to
do
a
round
robin
with
DPP.
J
I
seen
different
employment
from
the
last
discussion
we
had
about
this.
It
seemed
that
the
one
of
the
problems
was
that
these
brewsky
messages
have
to
go
to
the
right.
They
have
to
go
to
the
Massa
from
the
right.
Was
it
the
Registrar?
Yes,
and
if
and
if
they
go
to
the
Massa
from
the
wrong
registrar,
then
you
know
if.
C
R
Wreck
that
shortcoming,
okay,
to
say
on
how
these
things
on
this
Dave
Robin,
with
representing
back
that
mostly
I'm,
getting
beat
up
occasionally
by
customers
to
say
they
want
client
only
devices
and
by
that
they
mean
the
things,
never
listen
at
all,
and
so
in
this
that
that's
why
this
thing
needs
to
the
poor.
Little
light
bulb
needs
to
initiate.
This
needs
to
find
who
to
talk
to
that
kind
of
thing.
It
doesn't
just
sit
there,
wait
and
listen
to
be
provision,
so
it
makes
it
very
awkward.
M
No,
sir,
all
right,
so
then
this
is
the
separate
presentation.
A
bunch
of
idiot
Poole
came
when
I
first
did
mud,
manufacture,
usage
descriptions,
a
bunch
of
people
came
to
me
and
said
Elliott,
I,
sort
of
liked
the
idea
of
having
this
control
function
and
having
all
these
access
lists,
provision
and
what-have-you,
but
I'm
not
going
to
do
that
for
a
really
long
time.
So
what
I
would
really
like
Elliott
is,
if
you
could
provide
me
a
bandwidth
profile
of
each
of
the
components
that
are
touching
my
network.
M
M
First
of
all,
the
it's
not
clear
that
manufacturers
will
be
able
to
pull
this
off
in
terms
of
understanding
how
much
bandwidth
their
devices
are
intending
to
use,
and
secondly,
it's
not
yet
clear
if
deployments
will
be
able
to
have
the
right
infrastructure
for
this,
but
we're
starting
down
that
path,
and
this
is
basically
some
experimental
work
that
that
we're
beginning,
and
so
the
questions
really
is.
If
we
look
at
this
in
order
magnitude,
the
problems
begin
to
become
a
little
bit
more
solvable.
M
All
right
is
this
thing:
gonna
generate
you
know
100
packets
per
second,
or
is
it
gonna,
be
one
packet
per
day,
for
instance,
and
you
know
at
least
order
magnitude,
you
don't
expect
a
fire
smoke
detector
to
be
generating
100
packets
per
second,
presumably
not
even
if
there's
a
fire.
Would
you
expect
that
which
brings
me
to
my
next
point:
I
hate,
which
is
what,
if
there's
a
fire,
you
know
how
what
are
the
exception
conditions
and
how
what
happens
if
the
device
moves
from
nominal
state
to
exception
state
you
see
different
behaviors.
M
The
thing
is
now
spying
on
you,
okay,
so
I
created
a
little
bit
of
a
an
extension
to
mud.
To
do
this,
I'm,
actually
thinking
that
the
extension
needs
to
be
rewritten
slightly.
What
I've
done
is
created
new
Ackles
per
service
and
that's
wait.
That's
way,
wasteful
what
I'm,
probably
gonna
end
up
doing
is
modifying
the
Akal
model
directly
and
just
modifying
each
ace
to
allow
for
some
some
additional
information,
maybe
even
a
new,
a
new
container
to
to
address
these
points
and
it'll
be
a
little
bit
simpler.
M
M
You
get
right
now,
I'm,
looking
at
packets
per
second
bits
per
second,
a
time
frame
like
if
I'm
gonna
see
you
know
so
many
packs
per
second
over
five
minute
period
over
a
five
minute
first
period
or
something
like
that,
and
these
are
sort
of
the
parameters
that
that
I'm
playing
with
I
think
we've
had
one
comment
on
the
list
that
I
should
add
one
or
two
parameters,
but
I'm.
Also
seeking
your
input
on
this
and
again.
This
is
sort
of
experimental
and
I.
M
Think
that
might
be
my
last
open,
oh
yeah,
so
I
think
I've
covered
this
thing
and
I
think
II
thing
is.
It
also
needs
to
integrate
with
the
mud
abstractions,
because
I
might
wanna
send
so
many
packets
to
my
control
it.
So
that
should
be
the
last
slide
and
I'm
hoping
to
get
you
back
on
time.
But
are
there
comments
on
this?
One?
Are
people
interested
in
this
sort
of
bandwidth
profiling
using
the
mud
file.
B
E
S
Yeah
so
I
mean
I.
Think
it's
interesting.
The
the
thing
you
didn't
really
talk
about
in
a
way
that
I
understood
was
how
you
notice
that
how
you
tell
it
that
there's
gonna
be
a
bandwidth
profile
for
say,
firmware
updates,
and
you
know
how
that
how
you
can
differentiate
that
it's
actually
doing
a
firmware,
update
versus
versus
just
sending
data
yeah.
M
Host
or
something
like
that,
but
if
they're
not
I'm,
not
sure
I
want
to
have
indications
about
that
on
the
network
too
much
and
that's
a
it's
an
interesting
discussion
point,
because
we
want
to
be
careful
about
revealing
too
much
about
the
device.
Mudd
is
a
reveal,
there's
no
doubt
about
it,
but
it's
a
reveal
with
a
with
a
very
specific
purpose,
and
so
any
reveal
has
to
be.
There
has
to
be
value
to
the
all
parties
when,
if
that
reveal
happens,
okay,
okay,
thanks
for
your
time.
Okay,.
C
M
Like
to
see
where
people
think
and
and
I
would
like
to
collect
more
comments
and
then
have
the
discussion
with
the
chairs
and
about
what
to
do
with
it.
Next,
if
there's
a
really
a
big
demand
for
this
sort
of
thing,
then
we
can
and
we
can
and
we
can
really
figure
out
how
to
do
it.
Well,
then,
we
can
move
it
from
experimental
into
something
more
okay,.
T
Could
undo
everyone?
This
is
how
your
song
ever
going,
the
presents
are
or
the
updates
of
our
dropped
natural
telemetry
framework.
T
This
strap
has
been
gone
through
several
revisions
right
now.
Is
there
one
working
with
the
people
that,
because
we
just
changed
the
document?
Name
I
just
recaps
the
framework,
because
we
believe
this
for
the
network
telemetry
and
we
need
to
care
about
different
monitoring,
entity
and
objects.
Also,
there
have
a
different
type
of
data
sources:
I
came
from
the
control,
plane,
data,
plane
or
managing
plane,
and
also
for
each
plane.
They
may
use
a
very
different
type
of
data
export
locations
and
a
different
type
of
protocols
to
support
that.
T
So,
therefore,
we
partition
the
telemetry
into
multiple
planes
and
also
includes
the
source
of
the
external
data,
so
for
each
wines
has
own
purpose.
So,
for
example,
for
the
management
plane
is
many
care
about
the
device
configuration
the
operation
status.
We
have
already
have
some
protocol
stack
net
comp
and
G
RPC
for
that
purpose,
and
for
the
control
plane
is
many
care,
abouts
routing
protocols
and
also
the
roadie
information
base
and
use
a
steam
protocol
such
as
a
PMP.
T
So,
for
that
purpose,
and
for
the
data
plane
are
many
care
about
the
user
traffic
right,
IO
am
and
as
flow
may
be
used
for
that
purpose,
so
that
we
want
to
clarify
the
purpose
and
the
scope
of
this
dropped.
The
the
first
we
want
to
show
the
trend
now
is
shifting
from
the
conventional
om
to
the
streaming
telemetry,
and
we
also
want
to
clarify
several
misunderstandings.
T
Because
people
used
to
think
maybe
many
people
think
that's
a
management
plane.
Our
country
is
all
about
streaming
telemetry,
but
our
business,
our
study
really
show
is
also
for
control,
plane
and
a
data
plane,
and
it's
also
not
just
for
the
data
export
right.
It's
also
about
the
data
generation,
processing,
encoding,
storage
and
analysis.
It's
a
complete
system.
T
With
this
framework
we
can
map
existing
protocols
and
the
techniques
and
also
I,
can
help
us
to
identify
challenges
and
the
gaps,
and
we
also
want
to
clarify
that
we
don't
mean
to
duplicate
the
conventional
OEM
techniques
and
the
protocols,
but
to
complement
them,
and
he
uses
both
old
technologies
and
the
streaming
technology.
Limetree
3
has
a
network
of
visibility
and
operation.
T
T
So
the
discussion
as
we
want
to
disagree
we
want
to
discuss
with
you-
is
that
do
you
believe
this
work
is
useful
and
we'd
like
to
collect
feedback
on
what
need
to
be
modified
or
corrected
for
the
content
and
what
else
need
to
be
included
and
there's
a
something
need
to
be
done
about
the
security
consideration.
We
still
need
to
add
a
content
on
that
and,
finally,
we
like
to
call
for
the
working
group
adoption.
T
U
U
So
if
you
look
at
what
we're
using
GN
mi
for
we
already
have
implementations
of
that
that
are
exporting
LSD,
B
state
or,
for
example,
or
other
control,
plane
boy,
you
classify
as
control
plane
status
Irie
to
me,
it
doesn't
seem
useful
to
draw
a
division
down
that
that
line,
because
you
probably
want
to
minimize
the
number
of
different
interfaces
out
of
the
device.
So,
for
example,
you
could
replace-
or
you
could
pretty
much
merge
your
control
management
plane
time-
a
dream,
in
my
opinion,
the
two
as
to
whether
the
work
is
useful.
U
I
think
you
have
a
uphill
struggle
here
to
make
this
work
useful,
because
it's
an
area
where
there's
a
bunch
of
evolution
both
inside
and
outside
of
the
ITF,
where
you
for
this
document
really
to
be
useful
as
a
starting
point.
It
needs
to
be
as
up-to-date
as
possible
if
we
have
a
cut
an
RFC
out
of
it
or
will
be
immediately
outdated.
So
I
think
you
are
not
not
really
convinced,
I
think
also
trying
to
way
too
much
inside
of
one
document.
U
You
have
a
bunch
of
different
discussions
as
to
how
you
might
build
a
system
as
well
as
all
of
the
parts
of
the
system,
as
well
as
the
intro
to
rice,
implementation.
I
think
you
I
think
this
draft
really
needs
some
thought
about
whether
it
actually
adds
clarity
or
whether
it's
it's
actually
for
adding
for
them
further
muddying
the
waters
of
the
different
approaches
that
we
have
yeah.
T
So
so
you
can
mix
them
free
from
different
playing
together
in
one
single
implementation
or
solution,
but
we
believe
is
clearer.
If
you
have
this
separation,
it
can
help
us
to
identify
the
gaps,
because
if
you
look
at
the
using
of
protocols,
the
the
all
cover
different
aspect
of
networks,
so
it's
better
to
have
a
clear
separation.
U
U
It
needs
to
span
at
least
both
at
least
the
top
two
there's,
no
reason
that
it
couldn't
span
into
the
third
one
if
there
was
data
sources
that
that
way,
so
the
the
reality
is
that
there's
going
to
be
blurring
between
these
lines
and
and
operationally
I
don't
want
to
have
any
different
implementations
of
this,
so
I
think
identifying
gaps
is
fine.
Trying
to
put
an
architectural
framework
around
work
is
fine,
but
I.
Think
right
now.
This
draft
mischaracterize
is
how
what
the
reality
of
the
situation
is.
Seeking
an
architectural
approach.
E
Why
are
the
same?
Push
mechanism?
We
could
be
sending
flora
call
information
that
is
same
mechanism
right
so
in
the
end,
the
single
protocol
that
would
be
ideally
based
on
on
yang
information
but
send
by
the
same
telemetry
push
mechanism.
So
yes,
those
three
at
least
for
exporting
with
your
single
telemetry
protocol.
U
Just
to
follow
up
on
this,
this
point
been
I
made
Saurabh
here
again.
I
think
that
that's
actually,
if
you're
going
to
write
a
draft
in
this
area,
would
be
a
useful
breakdown
right.
So
one
thing
that
we
did
when
we
design
GMA
is
we
are
we
really
carefully
made
sure
that
we
weren't
tied
to
what
the
type
of
data
was
and
and
also
or
how
the
schema
of
the
data
was
expressed?
So
he's
we
have
a
very.
U
We
have
a
single
requirement
for
a
schema
that
can
be
exported
by
GMA,
which
is
that
it
must
have
a
path
that
can
be
identified
by
a
combination
or
a
series
of
elements
which,
which
consist
of
a
name
and
a
key
or
a
series
of
keys.
So
the
if
you
were
to
write
a
draft.
This
is
okay.
Here
are
the
different
export
mechanisms
we
have
from
the
device,
here's
what
they
might
be
useful
for
here's,
what
the
the
characteristics
of
them
are.
Then
here's
the
data,
modeling
approaches
we
have
which
of
these
combined.
U
It
might
become
clearer
as
to
if
we're
aiming
for
the
single
approached
from
the
device,
which
I
really
think
is
the
right.
The
right
thing
to
get
to
in
the
end
state,
then
it
might
give
a
view
of
how
we
might
get
there.
This
is
probably
more
forward
looking
work
than
the
kind
of
like
current
snapshot
document.
They're
writing
right
now,.
C
Kind
of
a
chair
comment:
I
had
the
same
some
similar
thoughts,
I'd
read
through
this
document
multiple
times
and
thought,
especially
with
the
closed
loop
in
tenth
thing
that
maybe
there's
elements
of
this
that
belong
in
the
IRT
F
that
belong
looking
at
things
that
that
haven't
really
been
fully
codified.
Yet
the
the
concept
there,
the
the
notion
that
was
just
brought
up
to
kind
of
figure
out
what
the
right
course
of
action
given
specific
types
of
use,
cases
are
or
what
type
of
data
are
looking
at
and
what
what
exports
exist.
C
T
So
I
six,
it's
a
may
be
good
for
the
future
network
architecture,
but
it's
also
addressed
that
today's
natural
measurement
requirements
so
I.
We
think
it's
a
well
drop
in
the
scope
of
this
working
group
and
also
for
the
folder
for
this
plane
partition.
We
find
you
know,
especially
for
the
data
plane.
You
know
it's
not
always
relying
on
the
datum
models,
for
example
for
the
IOM.
It's
a
directly
user
data
plane
as
a
data
source
and
maybe
they're
actually
exports
the
data
from
the
data
plane.
T
60S
address
the
real
problems
in
the
motivation
of
this
draft,
released
several
real
requirement
from
customers
and
then,
with
this
framework,
has
really
I
think
helped
us
to
identify.
The
second
requirement
also
finds
the
protocol
challenges
and
gaps,
so
how
we
can
address
that
really,
no
idea
right.
I
O
Fact,
the
the
you
can
earth,
in
fact
that
we
talk
at
this-
is
aircraft
with
many,
the
customers
from
the
OTT
and
it
operators.
In
fact,
from
their
point,
they
think
this
is
very
useful,
because
at
the
beginning,
they
always
assume
with
that
elementary
uses
super-safe
occurred,
who
are
technologies
such
as
only
as
confined
with
GRCC
or
summer,
but
some
others
of
the
Mesa
understanding.
This
is
the
I
am,
and
also
the
hint
they
also
called
as
in
bandit
elementary,
but
also
some
assume,
that's
the
GRCC
use
at
home
entry.
O
So
after
we
give
this
to
the
co
picture,
understand
the
whole
kicker
and
the
sinker.
This
user
will
be
very
helpful
for
them
to
understanding
these
of
the
whole
work.
So
they
see
you.
They
also
also
the
motivation
for
us
to
do
this
work
in
the
IDF.
What
we
think
this
will
be
helpful
for
the
customers
and
the
operators
to
understand
that
this
is
the
whole
picture
of
that
elementary.
U
Rubbish
Kerrigan
I,
don't
I
it
I'm
certain
that
it
is
useful
to
have
more
material
showing
what's
out
there
and
how
it
might
combine.
I
would
say
that
you
probably
should
put
together
a
presentation
and
go
around
operator
groups
presenting
that
this
is
what
we
have
putting
this
into.
A
draft
is
going
to
like.
If
we
ever
publish
the
RFC,
it
will
be
useless
to
anyone
and
other
than
at
that
point
in
time,
if
you're
going
around
and
have
something
that's
more
a
living
document
or
a
living
presentation.
T
O
Okay,
Arobin
and
then
one
more
comments,
so
this
additional
information
so
I
think
and
in
fact,
that
is
the
match
of
a
worker,
had
been
in
town
under
the
guidance
of
this
the
under
this,
the
draft
yeah,
you
can
see
it.
We
have
to
some
of
the
work
in
the
IPP
I'm
working
group
and
also
in
the
some
decent
net
council.
We
have
some
this
Samata
filter.
This
is
the
work
and
also
the
IP
of
young
work.
So
I
think
this
is
the
euro
experience
I'm,
not
sure
this?
O
Okay,
aside
energy,
or
not
like
this
one,
for
based
on
my
experience
in
yonkers,
feels
so
at
the
beginning.
We
have
I'm
Charlie
requirements
and
I'm
Charles
free
walk
so
that,
after
that,
we
have
this
much
work
to
be
done.
So,
in
fact
that
this
is
a
naughty
little
summary,
and
also
after
this
to
the
cap
analysis
and
also
this
identify
the
cap
under
the
requirements
under
these
the
guidance
that
we
begin
to
other
work.
So
we
think
this
today.
So
we
think
this
is
a
useful
walk.
C
C
U
H
Donors
there
is
valuable
information
in
this.
The
format
of
RFC
is
just
not
suitable
for
this,
and
probably
ATF
is
not
the
right
place
for
distributing
this
information.
Yes,
you
are
talking
about
the
right
things.
The
format
is
not
right
and
the
target
audience
is
probably
not
right
too.
There
are
other
industry
forums
which
would
be
much
much
more
suitable
for
this
I.
T
C
I
think
what
I'm
hearing
from
Ignace
other
is
your
work.
There
is
value
in
the
work.
It
doesn't
necessarily
need
to
be
ratified
as
an
IETF
document
to
an
RFC,
I
myself
and
others.
We've
presented
work
in
the
past
not
to
be
adopted,
but
just
to
bring
forth
to
the
IETF.
This
is
the
work
that
we're
doing
specifically
an
example,
the
yang
catalog.
Perhaps
what
I'm
hearing
is
what
you
should
do
is
what
you've
already
done.
You've
brought
this
to
a
number
of
working
groups.
C
There
might
be
like
I,
said
opportunity,
even
in
the
NMR
G,
to
go
and
present
your
think,
your
thoughts
on
some
intent,
but
to
go
to
other
operators,
other
other
users,
groups
or
operator
groups
and
spread.
This
message
is
a
potential
different,
different
venue
for
this.
What
I'm,
seeing
though
from
the
room
is
while
there
are
some
support,
it's
not
overwhelming
I,
don't
think
we
have
over
we've.
Had
a
number
of
people
read,
it
we've
had
some
strong
objections.
H
T
T
We
see
our
different
carrier
scenarios
all
required
as
a
data
plane
telemetry
from
the
data
center
interconnection
to
the
5g
barrier
network
and
also
the
access
network,
the
because
they
saw
multi
tenant
and
the
multi
service
environment.
The
the
operator
has
a
requirement
to
monitor
the
each
user
traffic's
network
experience
in
the
behavior,
for
example,
if
the
user
traffic
actually
follows
of
the
designated
paths
defined
by
the
service
function,
chaining
R
or
if
the
user
traffic
actually
meets
the
SAR
a
or
if
there
any
problems
in
the
network,
can-can
operator
quickly
identify
the
root
cause.
T
And,
finally,
the
operator
also
needs
to
the
past
optimization
attitude,
traffic
engineering
and
the
load
balancing
based
on
the
real
network
congestion
status.
So
this
all
need
to
do
the
data
plane
monitoring
and
we
already
have
the
Institute
OAM
as
kind
of
a
solution
which
carry
both
the
instruction
and
the
data
with
a
user
packet.
But
this
morning
in
the
IP
p.m.
we
also
talked
about
the
two
other
alternatives.
T
We
call
that
postcard
based
the
telemetry
in
that
the
user
traffic
won't
carry
the
data,
but
the
data
collected
and
each
node
will
be
sent
to
the
collector
directly
through
some
are
independent
data
packets.
So
each
of
this
solution
has
different
trade-offs,
says
has
its
own
pros
and
the
cons,
but
we
believe
it.
It
occupies
its
place
in
the
dmg.
T
Each
each
solution
may
have
its
own
performance
impact
due
to
the
fact
processing
the
header
instruction
processing
and
the
header
data
processing,
also,
as
export
data
may
be
too
much
too
overwhelms
either
export
interface
or
the
data
connector
servers
and
also
the
current
solutions
have
very
limited
data
flexibility
and
the
extensibility.
It's
just.
We
define
a
limited
set
of
data
support
it
also.
There
are
some
real
deployment
issues,
for
example,
for
the
encapsulation
in
IP
network
in
MPLS,
as
there's
no
solution
yet
in
carry,
and
also
in
our
carryin
there's
a
different
tunnel.
T
T
This
framework
contains
four
different
components.
The
first
one
is
a
smart
flow
data
selection,
which
means
we
need
to
have
authorized
to
us
to
decide
which
flow
of
which
packet
need
to
be
enabled
to
collect
the
data,
and
the
second
component
is
export
data
reduction,
which
means
we
don't
want
to
export
all
the
all
the
raw
data.
Rather,
we
want
to
some
pre-processing
in
the
data
plane
and
then
we
can
efficiently
compress
data
and
they
only
exports
the
subscribe.
T
The
data
based
on
the
event
or
policies
through
the
to
the
collector,
and
we
provide
schemes
to
encapsulate
the
the
such
instruction
headers
in
different
transport
protocols
such
as
MPs
layer,
2
network
or
you
an
IP
v4
network,
and
we
also
propose
a
measured
approach
to
make
this
go
through
that
tunnel,
different,
the
cayetano's
and,
finally,
our.
We
propose
to
use
a
10
amp
network
probe
as
a
underlying
technique
to
support
all
these
three
three
above-mentioned
components.
T
T
Now
we
are
actually
demonstrates
the
prototypes
inherent
network
based
on
this
framework,
and
so
what's
the
conceivable
future
working
for
this
document
is
that
we,
we
will
include
content
to
talk
about
how
the
data
will
be
consumed
in
the
you
know,
the
application
layer
and
how
to
support
the
cross
domain
operations,
but
in
this
stage
we
also
want
your
feedback.
We
help
us
to
answer
the
first
two
question.
C
C
T
So
so
some
yeah
yeah,
for
example,
for
the
encapsulation
and
tano's,
it's
a
very
common
requirement.
Today,
most
of
our
customers.
They
use
a
plain
IP
network
and
also
empty
eyes,
and
but
it
lead
fine,
it's
a
very
hard
to
apply
this
in
their
network,
because
there's
no
solution
in
ITF
yet
and
also
the
performance
concerns
is
real
because
they
want
to
monitor
the
user
traffic,
but
they
cannot
afford
to
lose
too
much
supporting
performance.
So
the
usual
here's,
our
very
real.
C
I'm,
thank
you
very
much.
I
would
say
again
take
these
questions
to
the
list
to
get
try
to
drum
up
more
discussion
and
get
more
feedback
for
your
work.
Thank
you
and
with
that
that
is
the
ops
area
working
group
pass
it
over
to
Ignace.
For
the
final
few
minutes,
we've
got.
One
presentation
on
ops
area,
blue
sheets
are
still
going
around
somewhere.
Blue
sheets
are
in
the
back
of
the
room.
Maybe
if
you
haven't
signed
them,
please
do
so.
K
H
H
If
you
still
haven't-
and
we
have
really
short
agenda
this
time-
it's
an
overview
of
the
work
that
is
happening
on
a
broadband
forum
side
related
to
some
development
for
models
for
the
ethics
and
then
one
topic
which
was
mostly
discussed
and
most
answered
about
in
the
working
of
the
oh
look
and
ITF
for
that
as
Devon
development.
So
I'll
spend
one
minute
on
that
and
then
the
rest
of
the
problem
forum
can
continue.
H
So
there
is
an
informal
agreement
with
the
owner
open
network
users
group
that
they
would
aggregate
and
provide
the
requirements
for
the
service
models
border
as
Devon
softly
defined
van.
That
is
work
in
progress
and
the
target
that
they
will
do
something
by
the
December
meeting.
So
we
might
see
some
more
active
work
together.
The
routing
working
group
happening
on
the
service
model
development.
H
K
K
K
So,
for
example,
there's
a
BBF
TR
352
protocol,
ICP
T,
inter
channel
transport
protocol
and
then
there's
so
that's
used
in
ng
Pont
two
systems
for
transporting
dynamic
data.
So
anyway.
The
point
here
is
just
that:
the
raverus
requirements
that
robin
forum
has
so
as
part
of
sort
of
analyzing.
What
should
be
done
because
it's
the
usual
thing?
Is
there
a
model
we
can
use
or
do
we
have
to
define
a
new
one?
So
we've
looked
at
the
existing.
K
We
here,
being
broadband
forum,
have
looked
at
the
existing
IP
fix
peace,
amp
model
which
is
RFC
67
28.
So
that's
a
single
yang
module
that
performs
P,
some
sampling
and
everything's
sort
of
basically
in
the
in
the
same
module,
obviously
only
supports
piece,
amp
meter
and
assumes
support
for
SCTP,
which
is
actually
a
bit
of
a
problem
for
us.
So
it's
actually
challenging
also
to
use
this
model
for
other
IP
IP
fix
applications,
for
example
the
one
I
mentioned
before,
partly
because
of
SCP
TSC
TP,
which
is
not
a
requirement
here.
K
I
mean
the
requirement
is
to
use
TCP
as
a
transport
which
would
require
use
of
young
deviations
if,
if
using
the
current
model,
also
I
guess
there
are
some
technical
issues
to
do
with
the
configuration
of
the
piece
amp
meter,
which
I
went
going
to
and
indeed
couldn't-
and
there
is
also
some
more
general
challenges.
There
are
more
of
these
listed
in
the
ID,
but
one
one
that
I've
called
out
here
is
that
interfaces
are
referenced
using
the
I
of
maybe
I
have
index
rather
than
bar
IIF
interfaces
interface
name.
K
So
this
is
really
just
I
mean
it's
just
because
it's
an
old
model,
obviously
it
predates
interfaces.
How
could
it?
But
you
know
we
would
like
to
the
option
to
be
able
to
probe
and
forum
with
like
the
option
to
be
able
to
use
III
IETF
interfaces.
So
in
conclusion,
we
don't
believe
it's
possible
to
meet
the
requirements
by
augmenting
the
existing
model.
We
prefer
to
develop
a
new
young
model
where
the
functionalities
separated
into
different
modules
so
that
the
functions
can
be
independently
leveraged.
K
All
right,
okay,
so
we
have
a
proposed
new
model
I'm
just
skipping
down.
There
are
three
modules
to
two
of
them.
There
are
draft
versions
of
those
included
in
the
ID,
not
not
for
the
third
one,
so
the
new
model
adheres
to
the
general
principles
of
sixteen
seven
twenty
eight,
but
it
firstly
adopts
the
latest
yang
guidelines,
which
is
sort
of
editorial
I
suppose,
but
that
is
obviously,
if
that's
done,
makes
it
not
not
by
was
compatible
from
from
the
from
notan
right
from
the
onset.
K
Its
adds
support
for
the
eighty
three
forty
three
interface
references.
It
splits
the
model
up
into
three
mod
proposed
three
modules,
so
a
base
module,
which
is
the
IP
fixed,
collector
and
its
water
functions
a
P
some
model,
which
is
the
P
some
functions,
configuring
to
the
sampling
metering
and
then
a
separate
bark
export.
Both
data
export
model.
K
It
also
makes
SCTP
optional
VAR
a
feature
and
in
probably
various
other
features
as
well
and
I.
Guess
I,
don't
understand
what
the
next
bullet
means,
but
it's
transport
sessions.
They
allow
the
transport
session
information
to
be
retrieved
individually,
which
I
guess
it's
not
possible
at
the
moment,
also
adds
some
choice.
K
Statements
for
the
source
and
destination
addresses
so
that
I
guess
there's
future
extensibility
on
how
the
address
on
the
address
types
that
are
supported
and
I
guess
just
the
last
bullet
is
an
illustration
of
how
the
breaking
it
up
into
three
modules,
how
that
modularity
can
be
leveraged.
So,
for
example,
piece
amp
could
only
use
the
first.
Two
statistics
would
only
use
the
first
and
the
third
and
the
TR
352
I
CTP
would
only
use
the
first
and
that's
it
I
think.
E
But
not
lives,
so
yeah
you're
right
this
was
this
is
an
all
module.
It
was
the
first
one
it
was
done
outside
in
that
mud
in
the
ITF.
So,
basically
you
write
with
a
couple
of
things.
We
should
be
updating
that
yang
module
and
obviously
for
a
CTP,
obviously
for
the
interface
by
the
way
we'll
have
to
pay
attention
to.
One
thing
is
that
in
in
IP
fix
we've
got
like
notion
of
ingress
interface
and
egress
interface,
which
has
an
extra
meaning
extra
semantics,
because
its
ingress
or
egress,
while
the
if'
index
is
like
neutral.
E
So
what
else
dividing
in
different
modules,
sure
that
makes
sense
one
for
the
exporter
and
one
for
the
collector,
so
that
all
makes
sense
it
could
be
done
pretty
quickly.
It's
like
phase
one
right,
and
then
there
is
a
phase
two,
which
is
the
idea
of
build
data
export
and
to
come
back
your
presentation
about
telemetry,
it's
yet
another
example
of
different
data
models
going
into
a1
telemetry
protocol,
in
this
case
IP
effects,
but
we're
going
to
see
more
and
more
of
these
combination
of
sources
of
data
models
in
the
future.
E
Now
this
one
we'll
have
to
see
how
it's
done,
because
we
spent
quite
some
time
trying
to
do
this
with
export
variables
into
IP
fix.
So
in
the
end,
we
have
a
nice
back
very
long,
spike
very
difficult
because
there
my
different
use
cases.
There
are
key
fields.
There
are
indices
in
mid
modules
while,
depending
on
what
you
need
to
have,
but
in
terms
of
young
information
in
your
body
that
export
it
might
become
complex,
but
ok,
phase,
one
phase,
two
and
phase
one
is
the
obvious
one.
I.
K
Should
have
made
it
clear
on
so
thanks,
Ben
well,
I
mean
I'm
not
going
to
respond.
I
think
you're
asking
for
a
response
to
any
of
that,
but
thanks
for
that
input,
I
just
realized.
There's
one
thing:
I
should
have
made
clear
that
I
mean
these.
These
are
a
problems
that
have
come
out
of
BB
F
work,
but
this
is
you
know
this
is
not
BB
F
doing
work
in
IDF.
This
is
this
is
just
an
individual
draft
that
happens
to
be
authored
by
people
from
two
member
companies.
I
V
E
E
V
I
M
V
K
Believe
we
need
the
bulk
date
or
export
to
replace
the
functionality
of
six
or
seven
twenty
eight
I
believe
I
believe
that's
that
goes
beyond
right.
One
more
time,
please
all
the
functionality
of
the
bulk
data
export
that
goes
beyond
sixty
seven,
twenty
eight.
It
does
right.
So
that's
another
good
way
of
looking
at
it.
W
Dave
senator
Burton,
but
I'm
also
the
BBF
ITF
liaison
manager,
just
a
clarification
on
the
phases,
because
I
want
to
make
sure
that
there's
no
misconception
here.
My
understanding
from
the
authors
is
that
they
are
planning
to
do
whether
it's
in
the
draft
right
now
or
not
they're
planning
to
do
all
three
of
these
in
one
phase.
One
point:
NRF
Sato
I
just
want
to
make
sure
that
there's
no
business
conception.
W
E
E
Right
so
I
want
to
come
back
quickly
them
on
the
service
models.
I
guess
we're
going
to
see
more
and
more
of
those
service
models.
The
issue
we've
been
having
with
service
models
is
that
by
the
time
we
published
some
of
them,
we
don't
generic
they're
going
to
be
obsolete
all
right.
So
if
we
believe
we're
going
to
get
all
the
requirements
from
people
from
operators
to
work
on
a
service
model,
then
we're
going
to
take
six
months
a
year
to
provide
it
it's
going
to
be
too
late
anyway.
Right.
E
That's
also
why
we
spend
some
time
on
the
catalogue
or
we
could
just
put
the
models
there,
and
if
there
is
some
value,
people
will
pick
them
up.
So
maybe
that's
one
way
of
doing
this
and
were
the
ITF
could
be
focusing
is
like
maybe
a
generic
way
to
do
triple-a.
As
you
mentioned
right,
if
there
are
some
more
extension,
maybe
the
SLA
of
the
service
doing
that
with
yang,
maybe
the
generic
composition,
those
big
items
as
opposed
to
specific
service,
as
d1
number
one
number
two
number
three,
we
know
it
goes
right.
E
H
Yes,
definitely
now
how
precisely
that
can
be
done,
that
it
is
both
extensible
and
generic
enough
and
at
the
same
time
it
is
practically
usable.
So
again,
I
think
you
are
targeting
that
there's
divine
discussion,
defining
a
service
model
for
that
and
trying
to
make
it
generic
enough
to
be
applicable
for
other
use.
Cases
well
might
end
up
in
something
which
is
unusable.