►
From YouTube: IETF115-OPSAWG-20221109-0930
Description
OPSAWG meeting session at IETF115
2022/11/09 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
And
the
note
well,
please
make
sure
you
understand
those
important
legal
issues.
Basically,
all
your
contributions
need
to
follow
the
item.
Rules
and
here
are
some
tips
and
firstly,
please
log
in
the
online
section
and
use
metair
code
to
join
the
the
mic
queue
and
please
wear
your
mask
on
this
activity.
Speaking.
A
Here
are
some
resource
for
idea4115
and
let's
go
to
the
first
session,
welcome
to
the
off
sale,
working
group,
it's
chaired
by
Kieran
and
Joe
and
Hank,
and
before
we
really
start
we
need
the
subscriber
and
the
minutes
taker.
B
Actually,
question
two
I
think
you
Rob
on
I
got
pinged
on
the
TLs
TM.
The
SNMP
transport
model
update
I
just
assumed
that
it's
working
through
your
queue
for
what
will
be
sent
upwards
to
the
isg.
C
Yes,
I
think
I
I'm,
trying
to
think
where
I
am
the
docs
I
think
I've
currently
reviewing
the
yes
from
axis.
One
I
think
so.
I
think
that
one
is
next
on
the
list
after
that,
so
so
it'd
be
after
this.
It
effort
I
get
to
review
it,
but
hopefully
it
shouldn't
be
that
far.
B
D
So
there
are
it's
a
small
in
addition
to
the
drafts
for
Michael,
who
was
asking
for
a
working
group
last
call,
but
we
are
missing
some
of
the
first
early
previews.
There
I
think
we
will
go
through
them
and
then
to
working
Google.
That's
called
on
the
liability
in
this
and
such
later
this
year,
but
that's
all
conditions.
B
On
other
drafts
so
add
encrypted,
DNS
or
add
encrypted
DNS.
This
is
post
technically
I
need
to
close
the
last
call
on
this.
There
was
some
additional
an
additional
draft
of
kind
of
Abyss
to
4.
4014
was
added
here.
A
Agenda,
we
have
a
very
full
agenda,
so
the
speakers
please
control
your
time
and
we
go
the
first
one.
The
model
update.
E
E
E
The
acceptable
URLs
has
been
through
I
think
is
pretty
non-controversial.
It
updates
RFC
8520
because
it
changes
some
of
the
processing
rules
for
at
least
one
of
the
the
attributes
in
the
mud
file
and
there's
a
nice
slide.
That
explains
it
in
one
slide
and
the
document
is
essentially
it's
been
around
for
more
than
a
year.
It's
had
some
various
amounts
of
review,
not
a
lot
of
deep
review
at
this
point,
but
as
as
far
as
I'm
concerned
is
ready
for
working
group
last
call.
E
The
other
document
is
DNS
considerations
for
mud,
and
that
has
had
a
couple
of
well
at
least
one
fairly
deep
review
from
Ben
Schwartz
and
his
opinion.
Is
that
we're
doing
it
all
wrong
and
specifically
we
the
internet,
and
we
should
be
using
socks
V5
so
that
we
can
see
so
that
firewalls
can
see
the
DNS
requests,
the
the
URLs
with
the
DNS
name
in
them
and
therefore
can
apply.
E
Name-Based,
filtering
and
mud
is
name-based
filtering
in
the
end,
so
I
think
that's
an
interesting
suggestion.
I,
don't
have
the
power
to
make
it
so
in
this
document
it
would
revise
8520
and
well
practically
all
the
rfcs
that
we've
published
in
the
past
10
years.
So
I
don't
think
it's
practical
and
given
that
I
don't
find
it
a
very
useful
thing
to
tell
us.
E
So
the
biggest
thing
with
the
DNS
situation
is
that
we
basically
have
to
make
sure
that
iot
devices
don't
bypass
the
local
DNS,
it's
okay
if
they
use
Doh
or
dot
or
whatever
doq.
As
long
as
they
ask
the
same
server
that
the
mud
controller
would
ask
in
the
very
in
the
the
degenerate
case
of
a
home
network
with
a
single
router.
That
means
that
that
essentially
home
devices
should
talk
to
the
home
router
to
ask
for
DNS
questions.
E
They
should
not
talk
to
8844
or
anything
else,
and
the
home
router
enforcing
the
mud
should
have
a
cache
of
DNS
requests
and
should
do
that
and
that's
really
the
advice.
It's
as
simple
as
that
use
local
DNS,
that's
about
it
and
that
that
document
is
has
had
much
more
review
and
much
more
discussion
and
is
also
I.
Think
ready
for
working
group.
Law
School
any
questions.
Sorry
I'll
just
run
away
and
give
you
as
much
time
as
you
like
Doc.
H
Hi
Michael
I,
don't
agree
with
Ben's
comment
that
if
you
have
to
install
root
certificates
on
every
iot
device,
that's
gonna
be
quiet
to
intrusive
I.
Think
DNS
filtering
is
the
right
way
to
do
it
and
we
haven't
figured
out
how
to
do
root,
search
installation
on
home,
iot
devices.
So
it's
pretty
easy
for
us
to
filter
TNS
traffic
and
we
are
already
working
on
deploying
encrypted
DNS
forwarders
on
home,
routers
yeah.
H
So
with
TNR
and
DDR,
it's
pretty
easy
for
endpoints
to
discover
the
encrypted
DNS
forwarders
and
home
routers
right
and
home
routers
can
enforce
filtering
based
on
the
mud
policy.
So
it.
F
H
Life
lot
easier
and
I,
don't
think
the
proxy
approach
is
Deployable,
at
least
in
home
routers
thanks.
E
And
and
I'll
just
say
this
there's
nothing
against
encrypted
DNS.
It's
just
it's
that
in
right
now,
encrypted
DNS
is
associated
with
off-site
DNS
and
there's
no
reason
for
that
to
be
the
case,
except
that
that's
how
it's
been
deployed
so
go.
Do
that
from
Firefox
and
chrome
and
whatever
to
your
heart's
content,
but
don't
don't
have
your
iot
devices
do
that
thanks.
D
So
this
is
a
comment
from
Hank.
As
a
chair,
I
was
mentioning
that
one
of
the
map-based
ideas
that
needed
some
a
little
review
of
the
DNS
consideration.
One
definitely
is
not
the
one
I
think
that
has
passed
actually
a
lot
of
conversations
such
as
timing
thing
a
little
bit
without
any
this
sense,
we
could
go
into
working
last
call
for
that.
We
acceptable
ul's
for
the
one.
Actually,
that
I
think
is.
D
Yeah
but
the
looking
to
get
this
one
and
then
go
from
there.
F
F
We
expanded
the
terminology
section
to
have
a
Consolidated
view
on
on
the
terms
which
we
inhibited
inherited
from
various
rfcs
in
the
active
segment
IPv6
type.
We
added
the
the
segment
routing
policy
as
in
yet
as
another
protocol
and
in
the
operational
consideration
sections
we're
describing
also
now
how
to
deal
with.
F
F
F
F
So
here
just
to
give
context,
so
the
the
SRH
pad
had
a
part.
That's
the
on
the
on
the
picture,
the
the
Violet
part.
F
Basically,
it
complements
the
so-called
provider
data
playing
part
where
we
can
actually
see
to
which
PE,
which
we
are
forwarding,
and
also
the
the
customer
data
playing
part
where
we
actually
see
the
the
communication
on
the
customer
side,
and
here
a
note,
it's
important
that
the
order
matters
since
we
have
two
times
IPv6
and
this
is
described
in
RFC
7011
next
slide,
please,
these
are
the
fields
which
are
in
VPP
now
exposed
next
slide.
F
Please
this
is
the
laptopology
we
used
for
the
interoperability
testing
between
Huawei
and
Cisco,
where
we
have
two
Cisco
PE
devices
and
six
Huawei
Huawei
pmpe
devices
and
with
it
in
probability,
testing
next
slide.
Please
these
are
the
fields
we
are
exposing
in
Huawei
and
they
are,
according
to
the
a12
template
record,
described
in
the
document.
F
Next
slide.
Please-
and
here
an
example-
query
then,
with
the
exposed
data,
so
we
can
actually
now
select
the
the
traffic
engineer
passed
in
the
segment
list
section
we
can
see
or
a
bit
on.
Basically,
thanks
to
the
segments
left
basically
the
order
of
the
forwarding
throughout
the
core,
and
we
can
see
on
each
segment
left
on,
basically,
which
was
the
active
segment.
We
are
forwarding
next
to
next
slide,
please.
F
So
the
the
open
source
running
code
has
been
published
on
GitHub,
the
first
commercial
commercial
implementation
will
be
in
q1
and
Q3
2023,
and
we
are
asking
the
working
group
whatever
they
believe.
The
document
is
in
stable
state
so
that
we
can
request
the
early
code
pointer
location.
B
Yeah,
specifically
Thomas
you
and
I,
we
emailed
back
and
forth
on
that
last
Point.
How
many
people
have
read
this
document?
I
guess
I
could
do
a
poll
that
show
of
hands
were
a
few.
B
It
would
be
good
to
get
I'll
ask
this
question
officially
on
the
list,
because
I
I
do
want
to
follow
up.
You
you've
done
the
implementation
here
in
the
hackathon,
but
we
need
some
feedback
from
the
working
group
as
to
whether
or
not
they
believed
it's
stable,
and
then
we
can
go
to
the
the
80s
and
and
see
if
we
can
request
that
code
point
for
you
so
we'll
do
that
in
short
order,
after
after
1
15.
sure.
I
Class
so
I
think
the
Ayanna
is
one
thing
right
by
the
way
we
validate
it
with
Ayana
that
they're
fine
with
the
latest
version
which
actually
Four
and
actually
this
the
trees
Mansion
by
Thomas.
So
from
a
process
point
of
view,
I'm,
not
sure
what
else
we
could
be
doing
to
interrupt
feedback
from
Ayana
Etc,
so
Ayana
earlier
occasion
is
one
thing,
but
you
know
you
can
ask
a
question
because
it
could
go
to
last
call
directly.
You
know
we
got
feedback
from
the
spring.
B
And-
and
we
can
we,
we
can
put
it
up
for
last
call
as
well.
F
Then,
on
the
second
top
draft
regarding
the
own
past,
delay
measurement
in
ipfix
next
slide,
please
here,
just
as
a
smaller
refresher
ipfix,
currently
is
lacking
the
ability
to
export
on
path,
delay,
measured,
metrics
next
slide,
please,
and
here
just
to
highlight
the
importance
that
not
only
we
need
to
export
the
the
delay
Matrix
itself.
We
also
need
to
give
those
delay
delay
Matrix
context
we
need
to
understand
over
which
interfaces
and
nodes,
and
also
which
forwarding
paths
next
stops
and
so
on
were
being
used.
F
That
gives
us
context
in
terms
of
delay
next
slide,
please!
So
the
current
status
we
received
feedback
in
ITF
114
regarding
the
the
terminology
inbound
versus
on-pass
Telemetry.
So
we
adjusted
that
in
the
draft
and
also
we
received
from
tianagan
some
feedback
up
regarding
the
terminology
using
iom,
transient,
encapsulation
node
versus
Transit
and
encapsulation
node
next
slide.
Please
do
you
still
recognize
the
problem
statement.
We
are
want
to
measure
a
network
operator
want
to
delay
measure
delays.
F
We
want
to
do
that
at
the
highest
scale
for
to
get
a
statistical,
Network
delay
view
the
I
ipfix
entries
defined
in
the
document
of
independent,
how
the
delay
is
being
method
in
the
network,
and
currently
we
have
two
vendors
which
are
validating
technical
feasibilities,
also
showing
interest
and
that
the
next
ITF
hackathon
we
will
show
also
an
implementation
in
fdio
VPP.
B
How
many
people
have
read
in
the
room?
How
many
people
read
this
one?
Oh
well
pretty
much
a
good
set,
so
we
will
conduct
the
call
for
adoption
formally.
I'll.
Add
that
to
the
action
item
list
after
1
15.
we'll
see
what
the
working
group
feels
on
the
list.
Thanks.
J
K
Yeah,
so
the
the
main
issue
here
is
that
the
the
ipfix
registry
is
pointing
to
you
to
an
old
RFC,
which
is
which
is
defined.
The
bitsy
bits
that
was
already
I
would
say,
duplicated
by
by
the
ATF
in
other
recent
RFC.
So
there's
a
deviation
from
the
current
ipfix
registry
versus
the
one
which
is
mentioned
in
my
TCP.
So
this
is
something
which
is
really
I
would
say
problematic
from
the
interoperability
and
the
other
issue
we
have
with
that
RFC.
K
Is
that
the
current
word
you
know
for
in
the
draft
about
some
of
the
result,
which
is
that
the
it
is?
It
is
a
little
bit
weak
and
this
is
really
problematic
in
case
we.
We
have,
for
example,
for
the
the
attack
that
are
using
some
of
the
flag,
Bits
And,
if
you
don't
export
what
you
are
observing.
There
is
a
problem
in
analyzing
the
the
issues
on
the
controller
side
next
slide,
please
so
the
fixes
the
fixes
are
really
straightforward
to
remove
the
any
mention
of
the
rfcs.
K
When
we,
we
are
defining
the
the
distribute
control
bits
just
point
to
the
iterative
registry
for
the
TCP,
and
then
we
are
done
so
we
simplify
the
way.
We
are
maintaining
the
ipvx
themselves
and
the
other
one
is
that
for
the
the
behavior
of
the
reserve,
which
is
that
we
just
we
match
the
exporter
must
export.
What
is
it
is
it
is.
It
is
observing
and
then
apps
to
the
to
TD
when
we
analyze
data
to
to
interpret
it
entreparately
next
slide.
Please.
K
The
next
question
is
why
we
need
NFC
for
this,
especially
given
that
the
ipfix
registry
is
expert
review,
we
can
just
go
to
the
expert
and
say
yeah,
please
modify
the
research
three
and
then
we
are
done.
The
problem
is
that
in
the
rrc
that
rrc
in
this
slide,
we
need
an
ATF
consensus
for
this.
So
that's
why
we
need
again
to
go
for
another
RFC
if
we
want
to
fix
what
we
have
in
the
ipfx
registry.
K
Hence
the
next
slide
image
I
have
I
would
say
many
questions
for
the
year
for
the
working
group.
The
first
one
is
whether
this
is
something
that
you
think
that
we
should
we
should.
We
should
solve
that,
or
we
just
forget
about
it,
and
leave
people
live
with
the
the
entire
property
problems.
And
then,
if
we
decide
to
proceed
with
this,
we
have
some
logistical
aspects.
The
first
one
is
in
which
stream
the
previous
one
I
remember.
K
It
was
sponsored
by
benue
at
the
time
and
I
don't
know
if
we
will
consider
that
that
that
that
that
track
this
this
time,
but
my
favorite
option
is
to
to
adopt
it
here
in
the
Ops
are
working
group
rather
than
going
for
the
it
is
possible,
especially
that
we
have
already
working
on
the
other
ipvx
documents
here
in
the
UPS
are
working.
K
So
that's
that
will
be
just
a
straightforward,
the
other
one
which
track
whether
we
maintain
it
in
the
informational
or
go
to
the
standard
track,
and
so,
let's
open
the
the
third
one
either.
K
We
just
maintain
the
current
approach
we
have
in
the
drafts
as
to
the
all
that
the
new
or
we
go
to
a
clean
version
with
an
abyss
version
of
the
of
the
RFC,
especially
the
Earth,
is
really
a
very
brief
one,
so
it
it
may
make
sense
to
go
with
with
the
base
and
that's
it
for
what
I
have
to
tell
about
this.
This
restaurant.
B
So
I
I
I
launched
a
a
poll
to
get
everyone's
interest.
If
this
there's
three
options
here
you
raise
hand
if
you
think
this
is
a
problem
to
be
worked
on
specifically
here,
don't
raise
your
hand
if
you
don't
have
an
opinion
or
do
not
raise
hand.
If
you
think
no,
this
is
not
a
problem
to
be
worked
on.
B
There's
no
interest
or
choose
to
do
nothing
if
you
don't
have
an
opinion,
as
a
chair,
I
would
personally
and
and
I
know
the
ads
and
I
have
gone
back
and
forth
on
this
I
would
prefer
to
have
things,
go
through
working
group,
consensus
and
working
group
process,
so
I
I
would
like
to
see
if
there
is,
if
the
working
group
wants
to
take
this
on
I'd
like
to
see
it
come
or
give
the
work
group
first
writer
refusal-
and
it
looks
like
what
you
can
see
here.
L
C
I
I
Now
there
is
another
option,
because
actually,
when
I
reviewed
what's
happening
in
the
is
Ayana
registry,
we
might
have
more
occurrences
than
CP
the
TCP
Flags,
where
we
were
too
strict
in
a
description
about
reports
at
that
time
of
creating
those
information
elements
they've
been
evolving,
so
sometimes
they
point
to
the
right
registry
description
is
wrong,
so
if
we
want
to
do
a
real
good
job,
we
should
be
reviewing
all
the
descriptions
there
and
making
sure
they're
pointing
to
the
right
registry.
So
it
might
not
be
just
updating
the
TCP
flux
RFC.
I
It
might
be
okay
if
we
want
to
solve
this
issue
and
that's
why
I
wanted
to
ask
this
question
before
you:
did
the
poll
Joe
because
actually
reviewing
this
registry
for
all
the
type
of
occurrences
that
you've
got
might
be
a
good
work
to
do,
but
to
just.
B
Sorry
hard
to
take
notes
and
comment.
That's
it's
it's
a
good
question,
and
probably
yes,
something
that
needs
review.
I.
Don't
know,
however
Med.
If
that's
the
work
you
want
to
to
take
on
as
part
of
of
this
work,
though
yeah
and
perhaps
that's
something
that
and
I
don't
know
it
could
be
that
that's
something
that
requires
a
set
of
drafts
to
go
after
each
different
area
or
if
it's
something
that
someone
wants
to
take
on
and
one
Fell
Swoop
problem.
C
So
just
confirm
we
said
earlier:
I
have
a
strong
preference
just
trying
to
get
this
sort
of
work
to
go
through
the
working
group,
and
that's
just
because
of
my
workload.
If
you
go
through
ad
sponsored
you
a
you,
get
less
consensus
and
less
sort
of
review,
and
also
it
slows
it
down
because
because
of
actually
how
much
other
work
I
have
to
do
so,
trying
to
get
this
through,
the
working
group
is
definitely
best
from
my
point
of
view.
B
Because
the
I
guess
those
were
both
Benoit,
so
it
sounds
like
there
is
interest
in
in
working
on
this
I
will
or
we
will
take
this
to
the
list
and
see
about
adoption
but
to
benoit's
point.
This
is
something
we'll
have
to
talk
about.
Do
we
and
and
get
what
the
working
group
feels?
Is
this
something
that
we
need
to
do
more
broadly,
and
how
should
we
approach
that
for
right,
now,
I
think
we'll
we'll
look
at
this.
B
Look
at
this
work,
this
particular
draft,
but
if
there's
a
desire-
and
maybe
Benoit
has
that
desire,
we
can.
We
can
push
forward
with
a
broader
look
at
the
registries.
I
A
H
Hello
good
morning,
everyone
I'm
thiru
I'm,
co-author
of
this
craft.
Next
slide.
Please
what
triggered
this
draft
was
comments
raised
during
the
Isaac
review
when
we
were
publishing
encrypted
DNS
results,
discovery
that
was
work
from
at
the
working
group.
H
At
that
time
there
were
various
concerns
raised
with
regard
to
discovering
encrypted
resolvers
when
endpoints
end
up
attaching
to
networks
which,
which
may
not
be
the
legitimate
Network,
that
the
end
user
believes
it
is
attaching
to
these
networks
and
that's
a
typical
problem
today
with
regard
to
dotted
next
not
widely
being
deployed
in
several
networks.
Endpoints,
not
supporting
the
iot
devices,
not
supporting
rotten
X.
H
Evil
twin,
is
a
very
common
attack,
that's
seen
in
various
networks,
because
they
they
all
use
pre-shared
keys,
and
there
are
various
ways:
pre-shade
Keys
could
be
leaked
to
an
attacker.
It
could
happen
in
your
home
networks,
hotels,
coffee
shops,
even
small
office
and
home
office.
Networks
foreign
that
was
happening
in
ad
working
group
was
earlier.
H
There
were
several
endpoints
which
were
using
trusted,
pre-configured
resolvers,
like
cloudflare
or
Google,
and
with
this
the
the
challenge
or
the
security
risk
that
was
seeing
was
endpoints
end
up
connecting
to
attackers
Network
emulating
legitimate
networks,
and
they
would
continue
to
use
encrypted
DNS,
but
the
attacker
who's
hosting
these
networks
would
be
able
to
see
even
modified
DNS
messages,
so
the
purpose
would
be
lost.
That
was
the
concern
that
was
raised
next
slide.
Please.
H
B
H
This
is
the
same
problem
in
any
network
that
use
operationistic
wireless
encryption,
where
there
is
no
no
peer
authentication
happening.
It
could
also
happen
in
mobile
networks,
where
you're
as
part
of
the
supply
chain
attack.
There
is
a
possibility
that
the
the
long-term
secret
that's
stored
on
the
SIM
card
is
stolen
and
you
could
be
connecting
to
a
fake
based
Edition
and
the
fake
base
station
could
be
hosting
an
encrypted
DNS
resolver
next
slide.
H
What
did
we
do
to
solve
the
problem
right?
We
proposed
a
mechanism
where
we
would
use
the
discovered
encrypted
resolver
as
a
fingerprint
to
decide
whether
you're,
indeed
attaching
to
the
same
network
or
not,
because
these
servers
are
resolvers
are
get
PK
validated
certificates,
and
that
gives
us
that
means
to
say
that
the
domain
name
that
these
resolvers
are
using
acts
as
a
fingerprint
to
identify.
H
Next
slide,
so,
if
you
take
scenarios
like
home
network,
which
is
using
probably
WPA2
or
wpa3,
which
is
using
psks-
and
they
don't
want
to
migrate
to
epls,
then
this
is
one
proposal
that
you
have
is
used
Trust
on
first
use,
so
the
endpoint
when
it
connects
to
the
network.
For
the
first
time,
fingerprints,
the
network
basically
takes
the
SSID
hash
of
the
preset
secret
to
make
sure
the
SSID
is
unique,
because
there
is
a
possibility
that
multiple
home
networks
would
have
the
same.
H
Ssid
then
use
the
discovery
mechanism,
that's
being
used
either
DNR
or
DDR,
and
the
identity
of
the
encrypted
DNS
resolver,
which
would
be
domain
name
in
case
of
DNR.
And
if
it's
case
of
TDR,
it's
going
to
be
a
public
IP
address,
which
is
which
will
be
there
in
the
certificate
for
the
end
point
to
validate
next
slide.
H
H
There
is
a
possibility
that,
in
certain
networks,
the
SSID
name
would
match
the
DNS
servers.
Subject:
alt
name
extraction
so
with
that
what
would
happen
is,
for
example,
in
case
of
a
public
Wi-Fi
hotspots.
You
would
have
the
SSID
name
matching.
What
is
what
is
the
identity
of
the
DNS
server
and
and
that
Awards
you
to
avoids
the
endpoints
to
do
tofu
mechanism,
but
that
may
not
be
viable
options
for
several
reasons.
H
Thank
you
yeah.
What's
the
other
alternative,
if,
if
you
don't
have
to
depend
on
tofu
or
depend
or
get
dependent
onto
the
encrypted
universities,
if
you're
using
an
e
method
for
authentication,
especially
epls,
that's
that's
going
to
be
a
lot
more
easier
that
all
that
the
client
has
to
do
is
check
if
the
SSID
name
matches
the
sand
extension
in
the
TLs
certificate.
This
is
going
to
be
pretty
useful
for
endpoints,
which
are
not
managed
by
MDM
networks,
where
client
authentication
is
not
required
and
during
the
device
registration
process.
H
Thank
you.
The
security
threats
that
we
anticipated
was
hey.
Yes,
the
evil
twin
will
not
be
able
to
see
the
DNS
messages,
but
it
will
still
be
able
to
see
the
other
traffic,
but
we
see
that
the
capability
of
the
attacker
will
will
continue
to
decrease
as
more
and
more
protocols
adapt
to
use
encryption.
H
For
instance,
the
work
happening
in
TLS
1.300
encrypted
client,
hello,
so
the
attacker
will
not
be
able
to
see
the
Sni
and
they
will
not
be
able
to
remove
the
DNS
records
with
PCH
keys,
and
that
will
also
give
protection
from
pervasive
monitoring
not
to
identify
what
Target
domain
the
client
is
reaching
by
just
looking
at
the
TLs
traffic
excellent
yeah.
We
would
like
to
have
more
discussion
on
this
and
any
other
mechanisms
that
would
help
to
protect
endpoints
from
connecting
to
these
evil
twin
Networks.
Thank
you.
D
M
Apparently,
I'm
really
short,
so
I
don't
know
if
you
saw
the
ietf
welcome
to
the
meeting
message,
but
the
whole
thing
on
you
might
need
to
forget
your
ietf
SSID
and
that's
because
we're
using
dot
1X
and
it
had
like
cached
the
certificate
and
getting
the
phone
to
forget.
That
was
really
hard,
blah
blah
blah
blah
I
do
think.
We
need
to
be
careful
that
if
people
do
things
like
this,
when
their
DNS
servers
change,
that's
easy
for
them
to
tell
their
device.
M
Yes,
this
is
expected
to
be
different
and
yes,
I
know
like
the
encrypted
DNA
stuff
is
all
different
and
sort
of
that's.
Okay,
especially
if
the
device
is
doing
stuff
like
V6
multi-homing,
you
might
be
using
one
set
of
ISP
at
one
point
and
another
one.
It
might
automatically
change.
So
as
long
as
it's
easy
that
the
user
has
a
way,
you
know
they
don't
get
stuck
locked
into
an
encrypted
DNS
server,
that's
no
longer
the
one
that
they
want
to
be
handing
out.
I
Okay,
so
on
behalf
of
Diego
and
nacho,
from
telefonica,
from
Thomas
from
suscom
Jean
and
myself
from
Huawei
I
want
to
present
the
data
manifest
for
contextualized
Telemetry
data
next
slide.
Please!
So
that's
something!
That's
a
documentary
presenting
a
couple
of
times
and
I
want
to
stress
something,
not
sure
if
you've
witnessed
this.
But
there
were
multiple
background.
There
were
multiple
meetings
and
discussions
about
trying
to
keep
the
semantic
in
the
ITF,
so
specific
Nita
collection.
So
we
had
a
side
meeting
on
getting
Yang
and
sibo
Kafka.
I
I
It
was
presented
also
this
young
and
civil
in
iapg
and
Nigel,
who
I
saw
earlier
presented
like
the
limits
of
modeling,
and
we
start
to
realize
that
we
need
to
keep
the
cementing
absolutely
not
only
in
configuration
but
also
in
the
operational
part,
and
this
is
all
the
topics
that
were
discussed
recently,
because
the
data
without
clear
semantic,
not
only
a
repeating
conflict
but
also
an
operational,
is
not
useful.
We
are
blind.
I
I
What
we're
doing
with
this
draft
is
not
to
create
new
information,
it
seems
simply
to
collect
information.
We
need
to
determine
the
semantic
and
send
it
along
with
the
Yang,
push
the
telemetry
and
even
if
the
source
not
accessible,
because
yes,
information
is
somewhere,
but
just
doing
a
call
on
the
router
to
understand
this.
Maybe
it's
not
the
right
thing
or
maybe,
because
the
router
was
upgraded
or
maybe
because
the
Telemetry
information
was
changed.
I
If
you
know
about
this
slide
about
this
draft,
the
example
I
always
give
is
the
same.
Let's
Assume
My
Time
series
database
looking
at
time.
Series
and
I've
got
one
counter
yesterday
at
time.
T1
and
I've
got
nothing
else
since
yesterday,
so
what's
happening
here.
Is
there
something
abnormal?
Well?
The
first
thing
you
could
be
thinking
if
no
Telemetry
data
there
is
a
Telemetry
issue
or
maybe
the
revolter
is
overloaded
and
can't
send
information.
I
I
You
don't
see
there
so,
depending
on
the
context
you
have,
or
you
don't
have
a
problem
to
act
upon,
and
this
is
the
thing
whenever
we
go
from
the
router
to
The
Collector,
to
Kafka
to
a
Time
series
to
the
analytics
and
those
guys
now
it
takes
their
relation
tests.
I
need
to
find
an
action
there,
so
we
they
can't,
go
and
call
someone
to
say
how
did
you
configure
this
Telemetry,
because
I
only
see
a
single
value
yesterday?
This
is
what
you
want
to
solve
next
slide.
Please.
I
So
the
proposal
is
to
have
two
data
manifests
once
the
platform,
all
the
information
required
to
completely
characterize
the
platform
information
which
platform
it
is.
What
is
the
OS?
You
have
a
specific
license
on
this,
etc,
etc,
because
if
it
changes
well,
the
context
changes
and
the
close
to
action
will
be
different
and
the
other
one
is
the
data
collection
manifest?
How
was
the
metering
process?
I
How
was
the
Telemetry
configured
on
the
device
is
what
the
previous
slide
I
showed
right
with
a
couple
of
different
actions
depending
on
on
the
context,
and
this
information
must
be
streamed
along
with
the
source.
It
does
not
mean
that
we
have
to
set
every
single
time.
We
send
a
Telemetry
message,
but
it
means
that
we
must
be
able
to
find
back
the
information.
So
if
the
data
is
pushed
different
place,
the
context
must
be
following.
I
So
what
is
doing
in
this
draft
and
by
the
way,
if
you
want
to
get
a
details,
there's
backup
slides.
So
we
changed.
It
was
a
proposal
to
change
the
Yang
module
names
to
be
more
obvious.
Okay
done,
the
prefixes
aren't
changed
next,
please.
I
What
is
new
I
would
say.
Is
that
to
make
sure
that
we
understand
each
other,
we
have
a
scenario
in
the
appendix
so
typically,
you've
got
a
device
sending
to
a
model
vent
Telemetry
collector
sent
into
infix
DB.
So
what
you
could
be
doing
is
at
the
top
right
hand,
side.
This
is
typically
what
you
would
be
having
as
a
Time
series
in
inflex,
okay
without
a
timestamp,
because
it's
not
useful
to
replant
them
here
and
with
the
Manifest.
We
have
actually
two
different
pointers
that
are
going
into.
I
First
of
all,
the
platform
manifest
on
the
left
and
then
on
the
right.
We
have
the
subscription
ID
and
the
specific
parts
that
we're
looking
at
and
they're
going
and
pointing
to
the
data
collection
manifest.
So
these
are
possible
ways
of
storing
information
in
fixed
DB,
and
we
thought
that
giving
a
full
example
would
help
understanding
what
you
want
to
do
next
slide.
Please
so
I
have
to
admit
that
we
have
not
updated
the
draft
as
much
as
we
wanted,
so
we
still
have
some
identified
Improvement
that
we
want
to
do.
I
One
is
to
use
the
pen,
the
private
Enterprise
number
from
Ayana
to
identify
the
vendors,
the
second
one
that
Diego
identified
pretty
early.
This
is
data
integrity
and
making
sure
that
we
know
that
the
data
is
not
changed
and
the
context
information
is
not
changed
along
the
along
the
paths.
I
Dan
bognanovic
last
time
to
give
us
a
good
use
case
in
the
world
of
iot,
where
we've
got
different
devices,
different
iot
devices,
with
different
contexts
and
with
different
capabilities.
So
it's
important
something
that
we
want
to
do
is
to
properly
specify
the
device,
and
that
relates
to
the
numerous
inventory
discussion
we've
been
having
recently
and
regardless
of
how
we
do
it.
We
need
a
unique
ID
right
and
that
will
be
the
one
used
as
well
in
the
in
the
platform
manifests.
I
So
we
have
one
extra
question
by
the
way
the
one
at
the
bottom
should
be
include
encoding.
What
you
said
last
time
that
we
don't
want
to
do
that.
It's
not
useful
in
the
platform
or
the
metering,
the
direction
manifest.
So
we've
got
one
open
question
here
which
is
about
the
MDD
subscription.
I
So
that's
the
collection
of
paths
right,
so
you
could
have
one
subscription
with
multi-part
that
you
observe
and
somehow
we
could
even
have
I
observed
that
pass
part
of
that
subscription
with
those
parameters,
but
the
same
pass
could
be
monitored
in
a
different
subscription
with
different
parameters.
Let's
say
one
is
on
change.
One
is
like
a
regular
pushing
and
netcomf
allows
to
have
XML
filters
as
well,
so
in
a
young
push.
So
that's
a
one
thing
that
we
want
you
to
clarify
on
which
key
we
want
to
use.
I
So
maybe
the
last
slide
and
I
see
people
in
the
queue
that's
good.
So
we
had
multiple
presentation,
multiple
version,
new
draft,
thanks
to
feedback
from
mediterion,
nacio
and
Joe,
and
that's
a
question
to
the
chair.
I.
Believe
you
would
like
to
get
a
Google
adoption
if
you
believe
it's
fine.
L
A
L
I
I
agree
with
the
problem
statement.
It's
a
lot
about
what
to
try
to
solve,
but
one
question
that
I
have
is
in
in
Yang
push
you're,
also
included
whether
the
data
model
itself
includes
basically
the
subscription
configuration
which
basically
includes
a
lot
of
the
parameters
that
you
have
in
your
manifest.
So
hence
the
question
is:
what
is
the
difference
between
what
we
are
proposing
here
versus
just
subscribing
to
the
subscription
to
to
get
to
the
subscription
notification?
Doesn't
this
already
give
you
much
of
what
you
need
here.
I
That's
a
good
point
Alex,
so
basically
you're
right
that
if
we,
if
we
have
all
information
from
the
configure
subscription
ID,
we
have
all
information.
The
thing
is
that
I'm
trying
to
say
is
that
whenever
you
move
to,
you
know
time
series
analytics.
If
you
lose
that
information
you,
you
lost
the
context.
So
if
the
device
was
still
alive
and
pingable
and
reachable,
you
could
directly
go
and
get
this
information.
So
somehow
you're
right
we're
sending
the
subscription
ID
information
along
with
with
the
data,
is
this.
Yes,.
L
So
I
so
I'm
not
quite
sure.
So
how
do
you
sorry
I
did
not
fully
understand
that,
but
why
is
this
different
with
a
manifest
because
you
can
always
I
mean?
Obviously,
if
you
lose
the
information
or
as
a
client,
that
is
always
an
issue,
but
it's
irrespective
of
reporting
it,
because
in
this
case,
in
both
case
you're
you're
streaming,
that
information
already
and,
of
course,
as
a
as
a
client,
you
would
be
expected
to
store
that
somehow.
I
L
D
I
C
Rob
Wilson
Cisco
as
a
as
a
participant,
so
I'm
just
trying
to
understand
what
we
have
today
and
what
how
this
differs
in
terms
of
you
can
always
it's
essential
question,
but
you
can
read
gang
library
off
the
device
and
know
what's
there
if
the
right
system
packages,
you
can
do
that,
so
you
can
get
that
information
and
embed.
It
is
the
key
difference
here
trying
to
embed
that
information
into
the
data
flow.
That's
coming
out
of
the
stream
Telemetry.
C
Is
that
the
key
thing
yes
and
the
second
question
related
to
that
is
so
today,
obviously
with
Yang
library,
that
tells
you
what
the
Yang
models
are
and
that
information,
but
the
other
information
you're,
including,
is
sort
of
information
about
the
subscription
the
subscription
parameters,
how
often
you're
polling
that
sort
of
thing
that's
to
give
the
Integrity
of
the
data
is
that
yes,.
I
There
are
two
parts,
so
it's
not
only
about
the
Yang
Library.
It's
also
the
information,
the
platform
right.
Let's
assume
that
there
is
like
a
bug,
and
now
you
upgrade
you
fix
that
bug
right.
You
want
to
get
the
information
about
the
OS
version,
a
simple
example
to
follow
the
information
of
the
data,
because
in
your
time,
series
database,
you
want
to
say:
oh,
this
is
before
the
back
and
after
back
so
I
want
to
learn
my
closed
captioning
not
available.
C
D
Hi
this
is
Hank
no
heads
on
so
with
the
huge
domain
of
metadata,
so
there's
a
huge
amount
of
metadata.
You
are
you're
opening
a
whole
new
world
to
your
manifest
and
you're,
bringing
a
whole
new
world
of
telemetry
to
the
silos.
I
understand
that
your
silos
are
disconnected
and
you
want
to
connect
them.
That's
an
High
School
I,
actually
support
that.
D
You
were
talking
about
platform
and
then
Integrity
with
Integrity.
Then
you
would
use
to
how
the
data
is
Con
conveyed
so
platform
Integrity.
Is
this
whole
own
kind
of
worms?
The
metadata
that
you
described
at
the
moment
is
just
on
aesthetic
and
dynamic
nodes.
It's
just
labeled
data.
It's
calling
that
the
semantic
is
you
use
it
once
in
the
slides,
often
and
the
idea
it
appears
once
and
that's
okay,
because
that's
just
labeling.
So
my
comment
is:
if
you're,
if
you're
going
there,
there
will
be
a
lot
of
extensions
later.
D
All
of
these
extensions
will
be
a
cross
area
and
I
would
prepare.
For
that
moment
when
people
realize
okay,
you're
talking
about
platforms.
But
what
about
my
platform
attestation,
my
Integrity,
my
keys,
my
trespass
in
this,
my
intellectual
security
force
and
all
Impact
your
metadata.
So
while
you
will
create
the
first
Edge
for
siloing
I
mean
there
will
be
a
lot
more
answers.
I
assume,
I,
just
I
assume,
so
that
I
just
want
to
just
carefully
point
out
that
this
is
an
extension
Point
you're
creating
here
and
that
will
be
used
at
some
point
overused.
I
D
Your
statement,
okay,
then
just
make
here,
take
care
of
the
involve
other
dealers
cross
pollinate
via
other
places
here
in
the
ietf,
and
then
maybe
extend
on
that
metadata
scheme
and
really
make
sure
that
this
metadata
scheme
is
expecting
all
these
extensions
that
we
might
be
incoming.
That
would
be
nice.
D
N
It's
it's
precisely
regarding
What
Hank
was
mentioning
just
as
benue
said
is
somehow
my
request
to
have
some
mentions
so
well.
Integrity
I
was
talking
about
provenance,
we
started
talking
about
it,
and
that
includes
timeliness
and
associations
and
everything
we
are
starting
to
scratch.
The
surface
I
I
have
been
talking.
This
is
with
Zhang
about
some
ideas
on
how
we
can
do
it
in
a
in
a
compact
enough
way
to
to
deal
with
this
manifest.
N
That
is
true
that
we
are
yeah
at
the
first
crack
or
something
that
probably
is
going
to
be
so
some
kind
of
a
flood
yeah
well
I,
consider
myself
an
infectious
agent
from
me
when
it
comes
to
these
so
I
I,
guess
that
we
will
be
talking
about
these
in
both
sides,
so
I'm
I'm,
very
much
I
guess.
A
J
J
So
the
the
issue
is
sometimes
we
might
have
a
network
with
several
layers
of
orchestrator
controllers
and
is,
and
if
there
is
a
configuration
going
wrong
at
some
point,
we
might
want
to
be
able
to
trace
where
that
configure.
Where
that
configuration
originates
from
so,
for
instance,
a
configuration
in
any
two
could
be
due
to
some
service
request
in
orchestrator
a,
and
we
want
to
be
able
to
trust
that
back
because
to
know
if
there
is
a
where
the
mistakes
come
from.
J
If
there
is
a
mistake
in
the
service,
for
instance,
or
if
you
have
like
two
controllers
that
are
fighting
over
a
device
they
might
over
overwrite
each
other
or
if
you
have
a
conflicting
interns.
You
can
also
have
this
this
issue
that
actually
it
would
be
the
lowercase
Twitter
in
that
case,
who
are
fighting
each
other
or
just
the
service,
are
not
properly
defined.
So
you
might
want
to
to
fix
that,
and
the
of
course
the
the
goal
of
that
is
to
be
able
to
automatically
resolve
the
issue.
J
J
So
what
we
have
at
the
moment
in
the
devices
is
that
we
have
the
history
and
some
metadata
Associated
to
each
configuration
change,
so
some
configuration
metadata
and
the
so.
The
idea
is
that,
usually
you
have
some
kind
of
identifier
that
you
can
use
to
retrieve
the
time
of
configuration
which
user
did
that
which
protocol
they
used
and
also
the
changes
most
of
the
time.
So
out
of
that,
we
abstract
this
into
a
local
commit
ID,
which
represents
that
single
ID.
J
So
there
was
a
draft
from
janineblatt
in
in
the
net
Comfort
Group,
which
was
kind
of
the
trigger
for
this
work.
J
So
the
idea
of
this
draft
is
quickly
put
that
you
each
time
you
configure
something
via
netconf,
but
the
client
would
push
the
configuration
and
the
server
would
keep
a
common
transaction
ID
that
would
be
Associated
to
certain
nodes
and
then
the
the
the
client
when
he
has
to
sync
with
the
with
the
the
server
or
just
change.
J
The
configuration
can
check
whether
the
the
numbers,
the
transaction
IDs,
that
they
share,
have
changed
or
not,
and
if
they
have
not
changed,
then
you
don't
have
to
think
anything
or
you
can
do
also
configuring
or
Niche
if
the
keys
is
still
valid.
So
this
is
a
way
to
to
speed
up
the
synchronization
and
in
our
case
we
want
to
use
that
in
order
to
see
if
the
the
configuration
that
was
pushed
was
pushed
by
a
particular
request
from
the
client.
J
So
here
there
is
some
names.
Actually
we
we
might
change
that,
because
we
had
some
commands
from
Med
to
use
parent
transaction
and
child
transaction,
so
I'm
still
going
to
use
Northbound
and
southbound
here,
but
it's
the
the
same
ID
so
in
in
the
example
here,
the
text
tx1
would
be
a
self-bond
transaction
for
the
orchestrator
and
it
would
be
a
Northbound
transaction
for
the
controller
and
so
the
the
ideas
right.
J
The
main
idea
of
our
draft
is
to
map
the
local
commit
ID
to
the
corresponding
North,
Bond
and
southbound
transaction
if
they
exist.
So
basically,
in
the
controller,
when
I
receive
the
configuration
from
tx1,
it
will
change
my
configure.
My
local
configuration,
so
I
will
have
a
local
configuration.
Id
I
will
say
this
was
called
by
orchestrator
with
the
X1.
J
So
this
is
what
you
will
remember
and
in
the
controller,
what
you
will
do
is
that
you
will
and
and
then
you
will
store,
also
Associated
to
the
local
commit
ID,
the
information
that
in
turn
it
pushed
the
text
to
index
free.
J
J
And
so
in
in
the
young
model,
without
surprises,
we
have
the
local
configuration
change,
local
commit
ID
as
the
key
and
the
Azure
City
tweets
the
list
of
Northbound
transaction
ID,
not
the
single
transaction
ID
that
cause
this
configuration,
the
idea
of
the
client
and
the
list
of
servant
transactionality
next
slide
please.
J
So
this
is
how
we
could
exploit
the
same
model
so
again.
Without
any
surprise,
it
starts
by
identifying
where
there
was
an
issue
in
the
ne
from
that
we
can
retrieve
the
Northbound
transaction
ID
and
the
Northbound
client
ID,
and
we
can
go
back.
Then
we
know
it's
the
controller,
so
we
can
go
back
to
the
controller.
We
can
say
what
was
the
transaction
for
that
particular
transaction
ID
and
we
can
match
then
to
the
to
the
transaction
ID
between
the
controller
and
the
orchestrator
and
find
back
the
original
service
request.
J
Yes,
perfect,
so
there
are
some
questions
for
this
draft,
so
first
one
is
that
there
was
a
feature
for
the
transaction
ID.
This
request
that
the
client
could
push
the
transaction
ID
and
so
decide
what
transaction
to
use
so
that
the
this
could
simplify
a
lot
our
our
process.
So
what
this
one
moral
question
for
for
Network?
Actually,
so
this
is
something
that
we
would
like
to
add
back.
J
J
So
that's
another
Point
I
think
we
had
some
feedback
from
from
Network,
which
was,
of
course,
if
it
works
on
network.
We
should
work
with
response
as
well,
and
finally,
there
is
a
draft
that
is
solving
the
exact
same
problem
from
Jan
and
Rock
I.
Think
where
their
ideas
to
solve
the
problem
is
to
use
trust.
So
basically
you
send
the
ID,
and
then
you
you
push
the
you.
J
So
is
it
so
thanks
for
the
review
I
made
and
is
it?
Is
it
a
problem
that
we
need
to
solve
and
is
our
solution,
an
approach
that
that
seems
feedback,
Ayana
I
think
you
have
a
question.
B
And
Jan,
while
you're
doing
that
I
put
a
poll
up
on
his
question.
Is
this
a
problem
to
solve
all.
O
Right
yeah,
so
I
definitely
support
this
problem
space,
as
you
understand,
I've
been
involved
with
two
drafts
that
are
trying
to
work
on
this,
so
I
definitely
think
this
is
important,
especially
if
you
want
to
take
this
network
automation
to
the
next
level.
We'll
need
this
sort
of
thing
we
get
hierarchies
of
orchestrators
and
controllers,
and
this
is
becoming
a
more
and
more
acute
problem.
O
We
removed
this
possibility
for
clients
to
set
the
transaction
idea
in
the
transaction
ID
draft,
because
that
was
the
common
consensus
or
the
common
opinion
in
the
net
conf
working
group
at
that
time.
I
personally
still
think
it's
a
very
interesting
thing
to
to
have
there,
and
we
can
have
certainly
discussed
that,
and
maybe
in
the
new
light
of
all
these
other
dresses
are
coming
into
the
net
Comfort
group.
Maybe
they
will
change
their
mind
there?
O
Okay,
when
it
comes
to
net
conference
conf,
yes,
I,
definitely
think
we
should
include
dress
companies
as
well
and
talking
about
this
last
draft
that
is
basically
highly
overlapping.
With
this
work.
O
That's
in
the
field
already,
but
I
would
certainly
be
interested
to
work
continue
to
work
together
with
you
on
this
and
I
think,
even
though
there's
great
overlap
between
this
regardless
Trace
context
extension
and
what
you
have
here,
there
are
some
areas
that
are
not
exactly
the
same
and
some
functionality
that's
missing
in
one
or
the
other,
so
maybe
they
could
complement
each
other.
C
As
robots
and
Cisco,
so
the
good
to
hear
that
you
you
both
sides
are
willing
to
work
together
on
this
problem.
I
think
that's,
obviously
the
right
thing
to
do.
If
you
can
do
that
in
terms
of
where
to
do
this
work,
I
know,
you've
sort
of
been
presented
both
here
and
in
netconf
I.
Think
so.
I
wonder
whether
that
comp
would
be
a
good
place
to
try
and
coordinate
this,
because
that's
also
where
the
transaction
ID
draft
is
and
I
think
they're
all
closely
related.
B
I
do
have
a
comment
not
as
a
chair,
though
so
you
talked
about
collusion
of
transaction
IDs,
Collision
of
client,
IDs
and
I.
Think
client
ID
was
brought
up
in
the
netcomp
working
group.
It
seems
to
me
as
an
arbitrary
string
with
no
coordination.
Clients
could
pick
the
same
ID
and
then
I
wonder
how
volatile
that
data
is
because,
if
a
device
crashes
and
you
want
to
see
why
it
crashed
is
that
is
your
draft
talk
about
Persistence
of
that
data.
J
No,
yes,
we
didn't
open
that
it's
I
would
say
yet
another
inventory
problem
where
you
need
to
have
a
unique
ID
I,
don't
know
how
to
solve
that.
Yet,
except
of
saying
that
every
client
in
the
in
the
network
should
have
a
unique
ID
and
as
you
say
that
is
persistent,
but
I'm
not
sure
whether
it's
really
reasonable,
considering
that
you
might
actually
have
orchestrators,
that
and
controllers
that
don't
belong
to
the
same
are
not
managed
by
the
semantities.
So
in
that
case
it
becomes
it
becomes
harder
to
to
serve
to
serve
that
issue.
C
And
Rubble
Francisco
again
so
in
terms
of
conflicting
client,
IDs
I,
think
I
would
just
push
that
into
the
space
of
whoever
is
do
sending
those
updates
down
to
the
device
and
say
that
they
have
to
coordinate
so
maybe
give
some
advice
on
on
how
they,
how
they
can
achieve
that.
But
I
I
think
keep
being
like
an
open
string
is
probably
the
right
answer
and
just
saying
look.
There
are
ways
this
can
be
avoided
by
putting
like
the
the
name
of
the
controller,
that's
sending
it
down
or
something
in
the
ID.
B
Okay,
as
chair
it
looked
like,
there
was
good
interest,
18
hands
were
raised,
no
hands
were
not
raised,
so
there
does
seem
to
be
support
for
this,
but
I
do
agree
that
I
think
netcomp
might
be
a
better
area
for
some
of
this
work.
B
Yeah,
it's
Camilo
Camilo
will
present
yeah
it's
the
same
presentation:
I,
updated
headstock.
B
L
P
Data
model
for
life
cycle
motivation,
operation,
I'm,
going
to
give
a
bit
of
update
in
the
draft.
My
name
is
Camilo
Cardona
from
NTT
next,
please
so
Marisol
already
provided
an
overview
of
this
draft
in
a
in
a
couple
of
it
itfs
ago,
so
I'm
just
going
to
go
very
quickly.
The
idea
of
the
draft
is,
to
let's
say,
support
the
life
cycle,
management
and
operation
of
assets.
We
have
heavy
scope
on
on
usability
of
the
asset.
P
That
is
the
features
that
the
asset
contain
the
feature
usage
and
the
licenses
that
support
those
feature.
Those
features,
this
draft
is
not
an
inventory
draft.
We
are
ideas
that
we
leverage
other
drafts
that
actually
Define
the
inventory.
It
seems
like
there
are
tons
of
drafts
about
that,
and
we
need
consensus
on
that,
but
we
don't
tackle
that
problem
next,
please
so.
The
difference
from
the
previous
versions.
P
I
mean
this.
The
the
core
of
the
draft
is
a
young
model,
so
we
have
been
trying
to
gather
use
cases
that
basically
try
to
bring
that
model
to
reality
as
much
as
we
can.
This
is
an
ongoing
work.
So
the
more
use
cases
we
We
Gather
the
better
and
we're
trying
to
just
to
tune
the
model
based
on
that,
so
we
have
been
tuning
the
model
a
bit
and
we're
just
on
that
process.
P
So
with
that
I'm
just
going
to
say
a
few
words
about
well,
one
of
the
Scopes
of
the
draft,
which
is
licenses,
feature
and
feature
research
licenses
or
features
are
complex
to
model
just
as
inventories.
So
what
we
are
going
to
try
to
do
or
what
we're
trying
to
do
is
to
try
to
bound
the
scope
of
what
the
model
can
do
or
not.
So
we
can
process
present
that
to
the
group
and
we
all
decide
whether
this
is
worthy
or
not,
based
on,
of
course,
the
limitations
of
a
complex
problem.
P
However,
well
this
is
ongoing
work,
but
I
do
want
to
comment
in
a
few
points,
so
I
mean
just
to
give
you
an
update.
First
of
all,
licenses
are
features.
The
model
will
not
model
a
catalog
of
them,
but
inventory
of
them
inventory
of
features
and
licenses
not
of
inventory
of
assets.
P
What
is
that
a
catalog?
That
is
if
a
company
wants
to
dispose
all
the
all
the
possibilities
of
features
and
licenses
that
they
have
that's
an
extremely
complex
problem.
It
involves
a
lot
of
graph
and
a
lot
of
options,
and
that's
not
what
we
want
to
model
right
now,
so
we
are
not
going
to
model
that
it
will
be
just
inventory
of
feature
analysis.
P
The
second
point
is
that
licenses
are
going
to
be
basically
defined
as
feature
well.
It
will
be
an
upper
bound
on
feature
usage.
If
a
license
is
just
a
way
of
giving
you
permission
to
use
a
feature,
then
that's
fine,
it
will
just
be
a
limited.
Well
if
it's
just
limited
in
time,
then
you
just
say
it,
but
a
lot
of
times
licenses
basically
have
upper
bounds
on
on
usage
such
as
okay.
P
This
can
be
used
just
in
ncpus,
or
this
can
be
used
on
with
M
users
or
with
x
amount
of
flows
or
stuff
like
that.
So
we
will
Define
licenses
as
that
using
the
feature,
usage
upper
bound,
multiple
times
licenses
have
defined
limit
on
multiple
feature,
module,
multiple
properties,
and
we
are
fine
with
that.
P
As
long
as
there
is
no
correlation
or
relationship
between
the
between
them,
so,
for
instance,
I'm
going
to
read
that
because,
if
not
I
forget,
if
I
license
cover
something
like
ncpus,
if
you
have
more
than
five
users-
that's
let's
say
kind
of
complex
to
model
we
can,
but
then
the
model
will
be
very
complex.
So
we
are
not
going
to
cover
something
like
that,
but
we
will
cover
stuff.
Like
let's
say
you
have
an
application,
an
app,
a
DV
database
that
can
be
installed
in
many
devices,
but
only
up
to
ncpus.
P
That's
something
that
we
like
to
cover
right.
So
you
can
Define
this
feature
or
this
database
is
installed
in
and
divide
in
these
devices,
and
this
is
how
many
CPUs
are
being
used
for
that
database
in
total,
and
you
have,
of
course,
your
limit
on
licenses.
So
that's
our
status
right
now.
Next,
please.
P
So
that's
basically
the
the
overview
we
have
a
bi-weekly
call
Marisol
coordinates
that
so,
if
anybody
wants
to
join,
please
send
us
an
email
well
to
marisolar
to
any
of
the
authors.
We
have
some
notes,
I
mean
if
anybody
wants
to
visit
this
drop
does
depend
a
lot
in
the
material
in
inventory
definition,
and
that
seems
to
be
kind
of
I
mean
there
are
a
lot
of
propositions
for
that.
P
Actually
I
heard
of
my
head
of
IT
how
that's
being
handled,
but
it
does
depend
on
that
so
yeah
we
would
like
to
have
some
feedback
on.
How
that
inventory
part
will
be,
will
be
steering
the
working
group
to
try
to
to
be
able
to.
B
There
there
was
a
side
meeting
on
inventory
that
happened
here.
It
was
shared
on
the
on
the
list
I'm
in
interested
and
I.
Think
we
have
the
multiple
participants
in
the
room,
some
feedback
from
that,
because
I'm
very
curious.
Some
of
the
questions
you
asked
about
how
the
authors
of
this
work
want
to
move
forward,
but
oh
God,
I
think.
R
The
first
one
would
be
LMO
like
you
know,
it
is
asset
lifecycle
management
operation.
So
I
personally
find
it
a
little
bit
kind
of
confusing
to
have
life
cycle
management
and
operation
because
it
doesn't
Define
the
scope.
It
could
be
confused
with
another
things
that
have
life
cycle
and
management
operation.
The
second
comment
would
be
I
think
you
lost
one
of
the
modules
in
your
latest
version:
ITF
LMO.
It
was
there
in
version
five,
but
it
disappeared
in
the
latest
version.
So
maybe
just
check
that
which.
P
R
Itf
LMO,
you
have
a
common
and
you
have
the
others,
but
the
the
one
in
between
is
was
there
in
version
five.
It's
not
okay,.
O
R
Anymore
and
and
another
comment
is
about
bi-directional
associations-
maybe
maybe
you
you
can
go
through
another
review
to
see
if
all
of
them
are
necessary,
you
know
or
if
you
could
reduce
their
number
of
bi-directional
Association
stuff.
P
L
Does
Alex
come
yeah
I
have
a
I'm
also
a
little
bit
too
I'm,
not
quite
sure
why
this
is
a
separate
word
from
the
inventory
management
and
Licensing.
Some
of
the
use
cases
that
you
show
here
appear
to
be
things
that
you
would
mostly
aggregate
at
the
OSS
level,
so
not
on
the
individual
device
level,
so
I
think
clearly.
Basically,
the
licensing
is
about
those
types
of
considerations
that
you
mentioned
are
are
certainly
valid,
but
I'm
wondering
how
much
of
that
wouldn't
I
mean.
Wouldn't
most
of
this
occur
at
the
OSS
level?
P
Well,
this
is
not
separate
for
the
inventory.
This
highly
depends
on
the
inventory.
The
the
this
draft
does
not
try
to
tackle
inventory,
that's
a
different
story,
so
we
are.
Hopefully
the
inventory
will
be
defined
and
modeled
in
another
work.
That's
what
we're
saying,
but
we
do
depend
on
that.
A
lot.
That's
that's
the
case.
Okay,.
L
But
a
lot
of
some
of
the
uses
that
you
said
really
aggregate
stuff
across
the
network.
You
say:
okay,
basically,
yeah
I
have
realized
and
I
want
to
have
so
many
users,
so
many
cores
and
so
forth
covered.
What
confuses
me
about
it
is.
This
is
stuff.
Well,
I
think
this.
Clearly
this
is
valid,
but
again
it
would
be
something
that
you'll
Aggregate
and
consolidate
at
the
operation.
L
P
That's
a
general
question:
we
have
whether
this
information
will
be
centralized
not
on
not
on
a
central
point,
not
maybe
on
the
devices.
That's
a
good
question.
I
I
do
not
know
thanks.
C
So
Roblox
and
Cisco
I
think
this
is
like
when
they
ad
hat
on.
So
you
asked
a
question
about
how
does
this
work
progress
and
how
does
the
work
progress
with
the
inventory
models
and
things
so
I
was
there
in
the
side
meeting
here
as
well,
so
he'll
keep
me
honest,
I
think
it's
quite
right
so
Chin's.
Basically,
my
summary
of
that
is
there's
different
groups
of
interest
in
working
on
the
inventory
models
and
I
think
there's
interest
in
trying
to
sort
of
compare
and
contrast
those
and
maybe
bring
those
together.
C
Those
are
currently
a
different
working
groups,
so
some
effort
needs
to
needs
to
happen
to
coordinate
those
I
think
the
next
step
proposed
to
that
is
to
create
at
least
a
mailing
list
to
get
those
different
parties
together
and
talk
together.
We
might
need
some
more
coordination
across
across
the
different
working
groups
in
terms
of
that
I
think
sort
of
different
from
this
model,
because
I
think
this
model
is
all
almost
like:
a
user
of
the
inventory,
rather
than
directly
having
the
inventory
embedded
in
it.
C
So
I
think
that's
sort
of
interesting
to
decouple
those
possibly
and
then
the
last
comment-
and
this
is
more
wider
I-
think
we
had
sort
of
discussions
about
how
these
different
young
models
again
created.
C
So
that's
a
slight
sort
of
side
topic,
but
I
don't
know
if
chin
wants
to
speak
any
more
about
the
meeting,
but
I
will
create
the
mailing
list
and
we
will
go
forward
from
that
point
of
view.
S
Just
to
quickly
respond
to
the
robot
actually
yeah,
we
have
assigned
meeting
yesterday
and
we
I
think
yeah
really
want
to.
You
know
in
a
high
level
reach
agreement
and
for
the
terminology
school
and
we
single
can.
We
can
have
a
synergize
effort
to
work
on
this,
so
we'll
actually
request
the
lady
to
create
a
minister
for
this.
Thank
you,
foreign.
D
No
hats,
unfortunately,
it
was
blocked,
headed
sight
reading
yesterday,
so
I
would
have
loved
to
pretend
that
have
not
having
now
read
anything
about
the
minutes
or
the
notes
about
that.
You're
talking
about
licensees
and
a
lot
of
working
groups.
D
Sorry
communities
out
there
curate
those
lists,
especially
in
the
software
world,
there's
a
list
about
465
licenses
and
then
I
see
that
you
are
talking
about
parameterizing,
those
because
number
of
users
which
again
would
multiply
the
options
how
to
represent
licenses,
and
that's
just
for
software,
the
OSS
that
was
mentioned
by
avex
and
it
might
be
confusing
things-
and
that
is
that
is
my
question.
P
I
might
not
be
able
to
answer
the
question
directly
because
of
defining
licenses
in
general.
Here
we
are.
Maybe
it
has
another
name
right,
maybe
here
what
we
are
defining
is
licenses
in
in
terms
of
your
ability
of
being
able
to
run
a
feature
or
a
product
database.
You
have
a
license
to
run
a
database
in
a
server
and
how
to
define
how
much.
P
How
much
you
can
use
that
feature
in
terms
of
properties,
so
how
many
users
can
use
the
feature?
Not
so
much
of
licenses
of
software
like
MIT
or
not
like
that,
and
it
is
indeed
confusing
to
me,
because
I
cannot
really
Define
what
the
difference
is
and
why
it
has
the
same
word:
I
I,
so
I
I
won't
be
able
to
answer
that
because
it's
over
my
capabilities.
D
T
P
On
their
experience,
that's
what
they
will
think
and
and
and
and
to
be
honest
with
you
I
I.
What
I
I
was
thinking.
Maybe
I
should
say
this,
but
I
was
I.
Maybe
I
will
get
myself
into
trouble,
trying
to
describe
this
in
the
middle
of
the
presentation,
but
it's
very
valid,
and
it
is
definitely
not
what
we're
trying
to
cover,
but
something
else.
So
we
do
need
to
be
more
clear
about
that.
Yes,.
N
Yeah
yeah,
that
sounds
very
accurate.
Well,
this
is
Diego
the
one
that
speaks,
suffer
Hank
normally
and
yeah,
just
just
a
a
reflection
that
is
very
much
to
support
what
Rob
and
dancing
were
mentioning
is
that
we
are.
We
are
reaching
the
point
in
which
we
are
touching,
we're
extending
the
idea
of
that.
N
We
can
read
and
modify
the
configuration
of
a
device,
and
we
are
reaching
the
moment
in
which
everything
that
has
to
do
with
the
operational
environment
of
the
device,
including
entitlements
and
including
the
different
modules
to
be
available
and
the
and
the
and
the
inventories
Etc,
and
we
and
we
are
touching-
we
are
reaching
the
moment
in
which
we
are
interacting
with
other
kind
of
databases.
Another
kind
of
data
I
think
it
is
worth
considering
precisely
to
start
whatever
a
group
in
which
this
is
at
least
coordinated.
N
C
Q
Paul
from
Valley
I
just
have
a
clarification
question
on
this,
because
you
define
the
asset.
It's
also,
it
doesn't
specify
the
scope.
It's
only
see,
there's
could
be
physical,
software
or
true,
so
I'm
not
sure
whether
it
contains
order
like
it
Assets
in
the
Enterprise
Network.
P
How
to
Define
asset,
at
least
we
are
considering
the
scope,
something
that
is
not
physical,
so,
for
instance,
a
VM
can
also
be
an
asset.
So
there's
software
assets,
but
maybe
I,
haven't
thought
how
much
to
Define
it.
So
I
cannot
really
tell
you
whether
that's
a
yes
or
a
no,
but.
A
P
I
I
guess
the
ability
of
a
model
to
be
able
to
also
cover
that
it
shows
how
good
the
model
is.
If
we
have
more
use
cases,
then
we
will,
we
should
be
able
to
Accord
to
correlate
what
you
say
to
see
if
the
model
covers
it
so,
but
right
now,
I
do
not
know.
B
Q
Nope,
hello,
hello,
everyone,
my
name
is
Boho
and
I'm.
Here
present
the
a
network
inventory
model
on
behalf
of
my
co-authors.
Q
Okay,
thanks
next
slide,
please
the
model,
the
problem
this
model
is
trying
to
solve
with
that
in
the
current
Enterprise
Network
the
we
have
different
domains
like
campus
network.
Currently,
we
have
also
like
sd1
Network
to
cover
the
one
connection
and
also
there
could
be
data
center
Network
or
a
cloud
Network,
so
each
this
network
may
have
its
own
Network
inventory
model
to
expose
to
to
the
OSS
system,
but
on
the
right
you
can
see
the
figure
that
we
we
give
here.
Q
Enterprise
Network
abstraction
network
and
security
function,
abstraction
here
that,
in
order
to
do
those
like
security
policies
to
be
consistent
and
also
the
service,
so
policy
could
be
consistent.
We
need,
like
a
end-to-end
point
of
view,
to
like
collected
all
those
all
those
inventory
status,
to
make
it.
Q
Q
Here
I
gave
just
some
concrete
example.
Here,
oh
wait:
wait
in
our
input
implementation.
We
see
that
there's
a
more
iot
Terminals
and
it
OT
sensors
Wi-Fi
bring
your
own
devices
all
those
endpoints.
They
are
moving
in
some
different
way
and
we
also
have
some
remote
worker
endpoints
that
could
be
connected
to
an
Android
device
Network
and
also
there
could
be
some
Cloud
Network
endpoints.
So
here
in
next
slide.
Please.
Q
Oh
I,
I
just
grew
just
recap
what
the
the
problem
is.
We
are
thinking
that
we
need
a
complete
view
of
this
network
and
its
status
and
we
think
the
endpoints
and
network
nodes
some
some
like
some
places
that
we
can
get
all
those
Network
information
and
here
I
give
some
like
Network
inventory
documents
that
may
be
relevant
like
in
this
working
group.
Q
We
also
have
the
service
attachment
points,
but
that
I
think
that
job
is
mailing
for
the
service
provider
domain
and
also
ccamp
has
that
physical
Network
inventory,
but
we
think
our
work
here
is
quite
different
from
that
one,
because
that
inventory
is
just
about
from
the
hardware
inventory
View
and
a
previous
slide
presentation
is
about
asset
Centric
I
mean
life
cycle
management,
so
I
think
these
works
are
quite
relevant,
but
I
I
think
still
there
are
some
parts
missing
there.
So
next
slide.
Please.
Q
So
here
in
in
this,
the
inventory
model
that
we
presented
here,
where
we
we
are
suggesting
we
can
like
augment
current
ietap
Network
model
that
to
adding
a
like
software
or
or
Hardware
components
to
the
current
ietf
Network
notes,
and
also
adding
more
information
about
IP
address,
Mac
address
or
some
software
information,
and
also
endpoints
information
to
the
current
Network
model.
So
in
that
way
we
think
in
this
way
we
can
get
a
better
Network
status
from
this
model.
Q
C
Zadie
I
only
said
quite
made
previously
to
to
coordinate
with
the
other
people
doing
the
same
sort
of
stuff
and
trying
to
get
to
a
common
thing.
Okay,.
S
G
G
Let's
say
that
is
at
the
Enterprise
Network
scenario,
where
one
of
its
employees,
one
of
his
employees,
let's
say
he's
a
Salesman
support
that
and
who
needs
to
usually
travel
a
lot
from
one
branch
to
another
and
work
in
different
branches,
and
such
the
mobile
office
will
make
the
his
IP
addresses
change
very
frequently
but
from
the
others
from
the
company's
perspective
that
such
employee
has
a
quite
stable
role
in
the
company
and
a
unified
permission
control
of
the
network
resources
yeah.
G
Let's
say
that,
for
example,
the
company
would
like
to
restrict
his
employee
to
access
the
YouTube
for
Video
Entertainment
during
the
work
hours
every
workday
and
the
company
would
like
to
release
that
restriction
during
the
work,
hours
and
weekends.
So
in
this
case
the
controller
needs
to
interact
with
the
SL
policy
enforcement
devices
very
frequently
to
modify
the
SL
policies
depending
on
the
IP
addresses
and
the
time
of
the
day.
G
So
we
think
that
these
different
security
policies
need
to
be
applied
to
even
some
user,
but
under
different
circumstances
it
will
be
applied
different
policies
it
also.
This
also
not
only
requires
the
frequent
interaction
between
the
controller
and
the
policy
enforcement
devices,
but
also
will
consume
a
huge
number
of
SEO
entries.
So
next
slide.
Please.
G
G
Yeah,
so
here
is
the
young
modules
which
we
call
the
UCL
extension
to
the
young
to
SL
model,
and
here
we
augmented
the
SL
match
container
with
a
new
Choice
named
user
control
group
and
inside
the
user
control
group.
We
have
the
source
match
and
destination
match
and
inside
each
match
there
could
be
the
user
group
identity
parameter
and
also
could
Define
an
ipv
for
IPv6
prefix
and
also
we
augmented
the
SCE
for
each
SL
for
each
Access
Control
entry.
G
G
So
here
are
we
just
get
a
list?
Two
alternatives
to
realize
that
maybe
one
that
support
that
the
user
needs
to
convert
his
username
and
password
to
the
triple
a
client
who
need
to
oh,
which
gives
a
sense
the
request
to
the
Triple
S
server
and
got
the
user
group
ID.
G
Then
the
triple
a
client
could
maintain
that
mapping
of
the
user
group
and
his
IP
addresses,
and
if
that,
if
that
triple
a
client,
also
collides
with
the
SL
policy
enforcement
point,
then
he
already
got
the
mapping
between
the
group
ID
and
the
IP
address.
So
it's
easy
to
act
on
the
user
group,
best
Access,
Control
policy
and
another
way,
another
alternative.
G
If
we
say
that
the
triple
a
client
is
not
collected
with
the
slpp,
then
in
this
case
then
triple
a
client
could
just
report
his
maybe
information
to
the
controller
and
then
the
SLP
be
good
query
that
map
information
from
the
controller
and
then
got
the
mapping
information
to
the
act.
Action
on
the
access
control
policies,
so
two
alternatives
to
realize
the
group
had
to
address
mapping
yeah
so
next
slide,
please
so
I
I
think
that's
it.
C
So
Robertson
Cisco,
no
hats,
so
the
one
thing
I
have
concern
here
is
the
sort
of
time-based
aspect
of
the
configuration,
and
that's
only
because
it
feels
like
it's
a
very
specific
solution
to
this
particular
thing,
whereas
I
wonder
whether
if
we
want
to
have
time-based
configuration,
we'd
want
to
solve
that
more
generically
and
have
a
more
generic
solution
for
allowing
configuration
to
change
over
time,
although
I
have
to
say
I'm
not
entirely
sure
whether
pushing
that
down
to
the
device
makes
sense
or
whether
it's
better
just
to
have
the
controller
updating
the
configuration
on
time
at
various
points
of
the
day.
C
B
B
And
there
was
that
the
chairs
there
gave
us
kind
of
first
right
of
refusal,
so
I've
got
a
a
poll
here
to
see
if
there's
interest
in
in
working
on
this
problem,
I
promised
chin.
I'd
read
this,
but
in
interest
of
time
I
did
the
interest
of
time.
I
do
have
some
comments,
but
I
will
take
them
to
the
list
and
I
will
relinquish
my
time
to
David
foreign.
U
Like
in
this
scenario,
accessing
YouTube
you,
you
have
user
groups
and
IPS
defined,
but
then
your
example,
YouTube
was
a
domain,
and
so
the
salesman
going
to
different
branch
offices
is
going
to
query
this
domain
and
get
different
IPS,
and
so
is
this
something
that
you're,
assuming
some
other
system
is
tracking.
All
the
different
IPS
YouTube
is
on
from
different
branch
offices
or
I
wasn't
seeing
how
it
covers
the
use
case.
So
I
was
just
curious
how
you
were
framing
that
problem.
S
My
understanding,
actually,
this
has
been
also
discussed
in
an
end
mode.
So
for
your
question,
actually
one
one
of
the
you
know
scenario:
actually
you
may
have
policy
server.
You
need
to.
You
know.
S
Your
your
user
group
for
different
for
your
Department
financial
r
d
department,
so
this
can
be
installed
in
the
policy
server,
and
so
this
policy
will
be
enforced
on
specific
Network
device.
So
you
can
use
this
and
to
restrict
access
for
for
specific
youth
group.
So
yeah.
U
S
Yeah
I
think
you
raised
a
very
good
question.
So
the
idea
is,
you
know,
here's
a
really.
You
know
probably
the
concept
for
the
attribute
based
the
network
access
control,
so
we
can
add
more
attribute
to
to
cover
your
use
cases.
So
yeah,
that's
a
kernel,
whatever
you
thought,
I
think
yeah
could
be
a
good
point
actually
where
you
can
think
about
how
to
resolve
this.
S
Another
I
want
to
respond
to
Robo
yeah.
This
also
be
discussed
in
net
model.
So
there's
one
another
proposal,
ACL
extension
in
nanomotive
so
for
time
related
attribute
could
be,
you
know,
be
generalized
in
ACL
extension
model.
So
we
can
reference
from
there.
Yeah.
E
This
is
the
right
slide,
so
you
see
these
documents
a
bunch
of
times
over
the
to
maybe
two
three
five,
eight
twelve
years
next
slide,
and
we
had
a
bunch
of
conversations.
We
tried
to
adopt
some
of
them
last
year
and
didn't
really
get
adopted
together.
E
It
was
weird,
so
the
major
loudest
suggestion
from
Carson,
vorman
and
I'm,
not
really
sure
if
it
was
consensus
in
the
end,
was
that
this
solution
to
the
problem
of
these
documents,
being
not
exactly
standards
truck
and
not
exactly
really
being
able
to
be
ietf
control,
was
to
extract
the
piece
that
required
a
standards
track,
which
was
the
part
that
creates
the
registry
and
put
in
a
new
document,
and
so
there
it
is
Richardson
Ops,
a
wgb
cap
link
type
next
slide.
E
It's
really
boring
document.
It
consists
of
the
part
on
the
right
for
about
12
Pages
I
talked
to
Ayanna
about
whether
they'd
like
this
an
XML
file
format,
and
they
said.
Oh,
yes,
please,
and
that's
really
all
it
is
part.
An
important
part
on
the
left
that
you
can
see
is
that
there
is
a
ionic
consideration.
Specification
cards
first
come
first
served
and
we
have
some
numbers
as
private
use.
E
E
If
someone
thinks
that
65
000
is
not
enough
for
the
end
of
the
world,
we're
only
at
about
290
right
now,
okay-
and
that
includes
a
whole
generous
amount
of
also
private
uses
in
the
lower
numbers,
plus
local
uses
and
stuff,
and
then
I
would
say
over
half
of
these
are
probably
dead
in
various
formats
forms,
but
it's
impossible
to
really
know
next
slide,
please
yeah,
so
the
the
short
of
it
is.
Please
adopt
this
document,
the
pcap
document,
then
you
could,
we
could
publish
it
in
any
way.
E
We
like,
including
ISE
80,
sponsored
through
the
working
group,
I,
recommend
we
publish
it
as
historic,
okay,
yeah,
there's
lots
and
lots
of
use
of
it,
but
nobody
should
be
writing
new
code
against
it.
The
pcapp
NG
and
gosh
I
hate
the
word
NG
in
everything,
but
that's
where
it
is,
we
could
publish
it
as
informational.
E
It
potentially
could
have
a
2.0
at
some
point,
or
is
that
a
3.0
I
don't
know
or
we
could
do
it
as
informational
in
the
normal,
not
in
our
control
and
both
will
reference
P,
kaplink
type
registration
and
that's
probably
the
last
slide
next
slide.
E
Yeah
and
I
just
said
that,
oh
and
we
had
another
document,
remember
already
removed
a
bunch
of
stuff
out
of
it.
That
was
like
there's
a
systemd
block
info
and
I
said
all
those
things
already,
I
think
that's
it.
C
All
right,
so
what
about
some
so
I
think
this
is
I,
don't
know
what
has
happened.
I
think
this
is
interesting.
Work
I,
think
it'd
be
nice
for
the
idea
to
publish
this
so
I
think
it's
finally,
the
right
way
to
publish
this.
My
preference
we've
tried
to
get
through
a
working
group,
that's
always
good
for
as
an
idea,
because
it's
less
work
I'd.
B
Welcome
to
the
Ops
area
portion
of
your
program
with
your
hosts,
Warren,
Kumari
and
Rob
Wilton
I
will
be
taking
minutes.
C
Able
so
just
while
we're
setting
up
I'll
make
some
quick
comments
just
to
say
that
the
Ops
director
we've
had
a
few
people
that
have
dropped
out
of
that.
The
Ops
directorate
reviews
are
really
helpful
for
Warren
and
I
when
we're
overloaded
with
work,
because
people's
opinions
and
sort
of
comments
on
those
documents
help
tell
us
whether
we
need
to
to
look
at
these
documents
closely
and
review
them
closely
or
whether
we
can
say
no.
Actually,
there
aren't
any
Ops
area
issues
that
we
need
to
worry
about
this.
C
So
if
there's
people
who've
got
a
good
experience
and
are
willing
to
help
join
that
directorate.
That
would
be
great
to
really
appreciate
that,
so
be
really
helpful
and
then
the
other
thing
to
point
out
is
that
the
next
non-com
cycle
is
happening,
and
so
again
we've
got
three
people
up
for
the
Ops
ad
roll
and
again,
if
you
can
provide
comments
back
to
non-com
on
the
different
candidates
that
helps
them
a
lot
in
terms
of
sort
of
choosing
candidates.
So
please,
please
provide
me
feedback
if
you
can.
M
Yeah,
what
Rob
said
also
somebody
can,
let
me
share
slides
that
would
be
awesome.
Yeah
Kyon,
run
I
think
has
the
current
slide
share
of
nut?
Yes,
the
upstart
record
stuff
is
incredibly
helpful
to
us.
It's
also
a
nice
easy
way
to
sort
of
get
your
feet
wet
with
with
something
that's
sort
of
provides
leadership,
type
experience
without
the
scariness
and
is
General
driving
the
slides
or
am
I
driving
this
late.
O
M
You're
sharing,
you
can
do
it
so
I
believe
that
this
is
being
presented
by
tourless.
If
sure
this
is
about.
T
All
right,
thank
you.
Just
a
quick
reach
out
to
the
operator
Community
coming
from
another
area
routing.
This
is
kind
of
I.
Take
it
on
a
draft
that
we
have,
but
next
slide.
This
is
really
going
back
to
the
fact
that
we
did
start
a
deterministic
networking
working
group
in
the
routing
area
to
improve
services
in
networks,
and
it
started
out
really
with
use
cases
where
a
lot
of
operators
and
applications
owners
were
coming
in
very
early
on
that
took
a
couple
of
years.
T
We
got
the
problem
statement,
these
use
cases
which
are
a
good
subset
of
what
we're
now
seeing
and
the
architecture
and
then,
of
course,
a
humongous
number
of
rfcs
to
actually
specify
the
forwarding
plane
in
networks
and
then
recently
this
year
we
started
to
figure
out
that
we
do
see
gaps
in
what
we
have
achieved,
primarily
also
to
critical
things
that
we
were
suggested
not
to
do
for
the
first
few
years.
Right
that
up
to
now
was
you.
T
You
should
really
only
use
in
the
forwarding
plane
what
we
have,
because
changing
forwarding
plane
is
always
difficult
so,
and
that
has
been
added
as
a
potential
option
to
the
Charter
now
and
one
of
the
things
that
we
primarily
identify
next
slide.
T
T
In
my
view,
right
is
any
subset
of
services
for
traffic
for
customers
that
guarantee
bandwidth
for
flows,
which
is
a
per
flow
setup
by
a
controller,
the
maximum
guaranteed
end
latency
of
traffic
flows,
which
can
leverage
you
know
whatever
Qs
can
support
this
at
this
point
in
time,
that's
one
of
the
big
gaps.
T
It
can
only
leverage
technologies
that
are
primarily
driven
from
IEEE
layer
to
TSN
and
then
and
that's
another
of
the
big
components,
a
reduction
of
loss
in
the
network
through
use
of
routing
for
a
diverse
path,
duplicating
traffic
and
merging
the
duplicates
on
the
receiver
side
right.
T
So
these
are
kind
of
the
three
big
building
blocks,
throughput
latency
and
a
reduction
of
loss,
and
then,
of
course,
all
the
components
needed
to
operationalize
that
in
the
network
OEM
and
the
controller
plane
via
young
models
for
these
Services
right
so
now
back
to
next
slide.
What
I
wanted
to
talk
about.
So
where
are
these
gaps?
T
And
obviously
you
know
one
way
is
to
reflect
it
back
to
to
you
and
that's
really
what
what
what
I
hope
to
do
the
Outreach
here
for
when
we
started
to
look
into
it
and
I'm
going
to
go
into
more
detail
from
the
next
slide.
We
felt
that
there
was
a
lot
of
things
that
that
net
can
do
very
nicely
in
the
networks
where
people
who
came
in
had
the
background
from
which
is
industrial
networks,
campus
networks,
where
TSN
is
working
in
where
customers
have
just
been
asking.
T
We
don't
only
want
to
do
layer,
2
switching.
We
also
want
to
have
that
working
on
IP
But.
Ultimately,
you
know
when
we
looked
into
what
are
the
forwarding
planes,
we
have
a
lot
of
components.
We
built
are
only
available
right
now
in
mpls.
In
the
data
plane-
and
there
has
been
much
less
resistance
to
even
do
small
changes,
so
a
good
amount
of
what
we
want
to
achieve
is
not
available
on
the
IP
forwarding
plane.
T
So
that's
one
limit
even
for
that,
but
the
primary
limit
is
that,
especially
us
vendors
were
looking
at
a
lot
of
the
design
and
thinking
this
will
not
scale
to
large
area
networks
in
sorry,
wide
area,
networks
and
high-speed
networks
next
slide,
and
so
that's
how
how
we
came
together.
T
T
It's
really
one
of
the
concerns
where
we
feel
that
we
need
better
scalable
cheaper
to
build
Hardware
infrastructure
and
then,
of
course,
also
the
the
things
where
really
The
Operators
would
would
have
a
lot
more
experience,
which
is
what
is
the
overall
package
that
we
need
to
build
from
that
net
so
that
this
can
be
reasonably
operationalized
and
sold
right.
T
So
we
think
we've
seen
in
the
last
few
years,
quite
a
few
potentially
really
interesting,
high
value
applications
that
could
make
you
know
that
net
the
new
VPN
services,
so
to
speak
at
least
them
are
not
going
to
enumerate
them
all.
But
then
the
question
is
always
what's
the
complete
ecosystem.
What
are
the
kind
of
first
services
that
the
U.S
operators
feel
could
help
you
to
introduce
a
dead
net
hype
services?
T
And
then
you
know,
what
are
you
missing
to
do
that
right
and
so
that's,
basically
the
Outreach
right
come
to
that
net.
The
problem
statement,
the
requirement
draft
that
we
have
I
think
may
be
good
part,
a
good
document
to
start
revisiting
and
and
add,
what's
missing
next
slide.
T
So
what
we
currently
have
is
a
key
aspect,
such
as
reduction
of
the
requirements
for
clock,
synchronization
networks,
whether
to
reduce
the
cost
or
completely
eliminate
that
that's
been
one
of
the
core
problems
that
we've
seen
coming
from
the
TSN
side.
If
you're
in
a
in
a
Rand
you'll
see
that
you
have
a
clock
requirements
in
the
front
hall,
but
luckily
not
in
the
back
hole
and
expansion
of
that
customers,
don't
need
support.
Of
course,
four
wide
area
networks
with
a
large
propagation
of
links
that
is
not
supported
by
the
current
queuing
mechanisms.
T
Then
of
course
the
overall
cost
of
doing
things
in
the
400
gigabit
router,
as
opposed
to
10
gigabit
campus
router
large
number
of
flows,
because
you
have
many
customers,
the
aggregation
needed
for
that,
and
then,
of
course,
also
the
operation
of
a
large
Network,
which
has
a
lot
more
failures.
Interruptions.
T
Recoveries
also
how
to
keep
the
service
easily
running
across
those,
then
at
the
core
of
the
latency,
the
better
scalable
cheaper
to
implement
queuing
mechanisms
and
the
explicit
path
selection,
where
we
have,
of
course
now
since
quite
a
while,
the
segment
routing
architecture
with
mpls
or
isrv6
is
one
of
the
preferred
mechanisms
to
do
that
in
networks.
That
also
given
more
view
in
that
net,
so
that
that
we
can
well
support
them
and
that
list
is
even
incomplete
and
yeah.
So
I
think
we
would
really
love
to
see.
T
You
know
also
an
ability
to
prioritize
these
things
based
on
what
takes
the
longest
to
get
done
in
terms
of
you
know
anything
that
requires
new
hardware
I'd
like
to,
if
you
know,
know
that
early
on,
whereas
everything
that
we're
missing
in
Yang
models
to
operationally
organize
things
may
be
the
most
important
to
you.
But
given
how
you
know,
we
may
have
the
hardware
dependency
first,
we
can
always
you
know,
do
that
more
timely,
then
right.
T
So
that's
a
little
bit
kind
of
my
overview
on
that
next
slide,
yep,
and
so
that's
what
I
was
was
here
for
right.
So
if,
if
you're,
if
you're
thinking
there
could
be
as
an
operator
of
especially
large-scale
network
interest
for
you
and
that
net
again,
given
that
we
have
achieved,
you
know
a
good
round
one
and
are
now
looking
for
things
more
for
your
type
of
networks.
Please
come
to
that
word.
Contact
the
authors
or
the
net
mailing
list,
so
I'd
be
really
happy
to
see.
T
You
know
reinvigorated
participation
from
new
folks
here.
Thank
you
great.
M
And
we
have
about
four
minutes
left
which
I
guess
is
the
Ops
area
open
mic
session?
If
anybody
has
any
UPS
area
open,
mic,
question
statements,
you
wish
to
throw
tomatoes
and
rocks
at
us.
Please
do
so
now.
M
Fruits
and
vegetables-
okay.
Well,
thank
you.
Everyone
very
much
again.
Also
another
reminder:
please
join
the
Ops
directorate.
It's
actually
quite
interesting
and
Incredibly
helpful
and
useful,
and
also
please
feel
free,
feel
free
to
provide
feedback
to
the
nomcom.
There
is
a
large
slate
of
people
running
the
Nom
come
feedback
place.
I
will
put
in
the
chat
many
candidates
running
IAB,
isg,
Etc.