►
From YouTube: IETF113-OPSAWG-20220324-1330
Description
OPSAWG meeting session at IETF113
2022/03/24 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
All
right
welcome
to
chapter
113
of
the
ops
area
working
group,
a
joint
meeting
with
ops
area
hank
and
I
joe
clark
will
be
your
host.
We
have
ken
wren
joining
us
from
remote
and
we
have
quite
a
few
other
people,
so
welcome
out
there
and
meet
echoland
everyone
who
is
joining
us
for
the
ops
area
working
group.
B
As
a
reminder,
this
is
an
ietf
meeting
and,
as
such,
the
note
well
applies,
I'm
sure
you've
all
seen
it
and
read
it.
But
there
we
go
my
private.
My
confidence
monitor,
went
off,
but
as
a
reminder,
all
of
your
contributions,
everything
you
see
at
the
mic
is,
is
public
and
subject
to
the
the
ietf
processes
and
policies.
B
B
B
You
can
either
choose
to
join
that
with
the
the
meat
echo
app.
So
you
can
see
a
qr
code
if
you're
here
in
the
room,
if
you
scan
that
on
your
phone
or
mobile
device,
you'll
have
the
meat
echo
light
version.
If
you
are
presenting
with
that,
you
can
use
it
to
adjust
the
slides,
but
it
looks
like
we
have
a
clicker.
B
Actually,
I
don't
think
that
clicker
will
work,
so
we
can
also
move
the
slides
for
you
and
if
you
wish,
you
can
join
the
meet
echo
heavy
by
clicking
on
the
video
icon
in
the
data
tracker
agenda
and
you
can
follow
along
for
remote
participants.
This
worked
just
like
before,
hopefully
you're
all
signed
in
to
meet
echo
and,
like
I
said,
I
see
a
number
of
people
there,
so
it
looks
like
that's
all
being
very
successful.
B
What
we're
going
to
do
is
go
through
our
agenda
first
and
hopefully,
by
this
time.
You've
had
all
the
information
you
need,
so
you
can.
You
can
look
at
that
there.
As
I
mentioned,
I'm
joe
clark,
we
have
hank
joining
me
here
in
the
room
and
we
have
10
remote,
eliot
lear
has
via
email.
I
have
a
paper
trail
to
prove
it.
I
see
him
online
graciously
agreed
to
scribe
for
us,
and
I
know
rob
wilton
has
done
so
in
the
past
very
well.
I
might
add
so.
B
Where
do
we
stand?
We
have
some
great
news.
Actually,
we've
got
three
new
rfcs
published
since
our
last
meeting
in
112..
We
have
the
first
two
of
the
layer,
the
ln
or
lxnm
models.
So
we
have
the
common
and
the
l3.
B
You
can
see
if
you
read
down
a
little
that
the
l2
is
in
with
the
isg
and
waiting
a
revised
id,
and
we
had
21
2160
published
on
export
of
mpls
segment,
routing
label,
type
information,
ipflow
information
export,
so
great
work
so
far
and
we've
got
a
lot
of
drafts
progressing.
So
we
have
one
in
the
rfc
editor
queue.
That's
the
network,
telemetry
framework.
B
I
have
been
a
bad
chair
and
I
need
to
close
this
working
group
last
call
on
vpn
service
performance
monitoring.
We
got
some
good
comments
on
that
and
there
was
a
revised.
I
believe,
a
revised
a
id
just
came
through,
and
we
have
a
few
close
to
last
call
we'll
we'll
start
that
after
these
proceedings
at
some
point,
some
of
the
mud
s-bomb
and
the
service
attachment
points
which
we'll
hear
from
today
hank
or
tian
ram.
Is
there
any
thing
you'd
like
to
add
to
status.
B
Okay,
moving
right
along,
so
you
are
right
here
right
now
in
our
administrivia
section,
and
then
we
have
I'm
not
going
to
read
every
agenda
item
you
can
see.
We
have,
as
usual,
a
quite
packed
agenda
for
ops,
og,
our
ops
area
working
group,
and
then
we
will
hand
things
over
to
our
illustrious
ads
and
they
will
do
an
open
mic.
And
I
know
warren
has
something
to
say.
B
B
I
can
load
those
up
for
you
you're
doing.
Sadly
it
didn't
come
in
order,
but
I
think
I've
got
you
right
here.
C
Okay,
thank
you.
Thank
you,
joe,
so
the
yeah,
so
the
this
will
be
a
short
update
of
the
service
attachment
points
to
report
with
rd.
I
would
say
the
the
recent
changes
to
made
for
this
in
this
specification
in
next
slide.
Please
yeah!
So
this
is.
This
is
just
to
to
remind
the
I
would
say
the
the
context
to
this
is
the
structure
we
presented
last
time,
so
the
for
disabled
attention
points.
Thanks
are
really
simple.
C
We
have,
I
would
say,
a
new
structure
that
we
enhanced
the
service
at
at
the
node
level.
We
model
just
just
to
have
a
list
of
services
points
that
are,
I
would
say,
identified
with
the
notifier
and
we
down
the
list
of
services
to
to
that
one.
So
the
the
document
wasn't
in
the
last
call
sorry
in
the
production
call
for
adoption
in
which
we
received.
C
They
would
tell
a
lot
of
useful
comments
from
the
from
the
working
group
and
that
revealed,
I
would
say,
a
lot
of
issues
that
are
listed
in
the
in
the
next
slide.
C
As
we
we
are,
I
would
say,
assigning
the
or
associating
multiple
services
to
to
the
same
service
attachment
points.
There
is
a
need
to
to
to
amaze
to
display
and
to
use
filters
just
to
specifically
have
a
topology
for
a
given
service
and
not
for
all
of
them
with
the
old
version
we
have
with
the
model
that
was
really
difficult
to
do
so.
The
this
was
one
of
the,
I
would
say,
important
feedback
we
received
from
from
the
working
group.
C
There's
also
another
comment
from
the
from
dhruv.
Then
this
one
is
also
important
is
how
to
associate
between
the
the
service
attachment,
topology
and
the
the
the
physical
one.
So
we
need
to
have
a
glue
somewhere
in
the
model
to
to
to.
Let
us,
I
would
say,
easily
graft
the
distilled
attachment
point
topology
into
the
the
physical
one.
C
There
are
also
various
issues
that
was
really,
I
would
say,
for
example,
if
you
want
to
cover
not
only
the
the
user
to
the
network
interface,
but
also
for
the
services
that
are,
I
would
say,
requested
from
a
pure
network,
and
for
that
one
we
need
to
have.
I
would
say
some
discussion
about
the
the
network
network
network
interface
and
there
are
also
a
lack
of
examples
to
illustrate
how
the
model
can
be
put
in
into
practice.
C
So,
in
order
to
to
address
all
of
these
issues,
we
we
have
updated
and
proceeded
with
many
revisions
of
the
specification
that
can
be
shown
in
the
next
slide
so
rather
than
index
in
the
the
serious
attachment
points
by
its
id.
We
are
we
we
are
now
having
something
which
is
structured
based
on
the
service
itself
and
under
that
the
service
we
have
added,
multiple
leaves
and
parameters
there.
C
In
order
to
to
address
all
of
the
issues
that
were,
I
would
say,
listed
in
the
in
the
previous
slide.
We
also
added
a
lot
of
examples
as
appendixes
to
really
illustrate
how
the
model
can
be
used
in
various
contexts
we
used
vpn
for
here
for
for
that
purpose,
because
the
the
working
of
is
working
on,
I
would
say
in
ill
two
and
three,
eight
three
services,
but
the
the
same
exercise
can
be
done
for
other
services.
C
We
use
also
to
have
one
comment
from
from
joe
about
the
the
mapping,
and
for
that
also
we
have.
We
have
added
multiple
examples
like
next
to
to
to
explain
how
we
can
we
can
we
can.
We
can
manipulate
the
model
in
order
to
use
the
map
in
between
the
service
and
the
service
attachment
topology
next
one,
please.
C
We
also
receive
the
the
yank
docker
reviews,
there's
nothing
I
would
say
major
there.
There
is
only
comments,
some
nits
about
renaming
some
some
leaves
and
so
on,
and
it
was
really
straightforward,
but
but
but
that's
still
a
good,
a
good
review
from
for
from
martin
either.
For
that
we
don't.
We
don't
have
any
any
other
appendance
on
this
document
that
we
think
that
we
are.
C
We
are
ready
for
the
working
of
last
call
and
know
that
that
venue
is
is
currently
a
review
and
the,
I
would
say,
the
draft
to
to
check
the
the
mapping
we
I
mentioned
earlier,
but
this
can
can
be
handled
as
part
of
the
working
of
classical
if
the
worker
decides
so.
B
All
right
any
comments
or
questions
on
service
attachment
points.
B
I
I
didn't
know,
I
appreciate
the
revision
and
I
noticed
benoit
had
I
didn't
get
to
read
it
yet.
Just
before
I
came
here
and
like
I
mentioned,
med
will
looks
like
scott's
joining
the
queue
and
you're
here
scott
go
ahead.
D
B
Hello
there
we
go
there,
you
go.
I
was
triply,
muted
apologize,
so,
okay,
so
can
you
go
back
to
the
tree?
I
just
have
a
simple
question.
I
hope
it's
simple
right
there
this
tree,
so
I
what
I'm
seeing
here
is
that
you
have
a
node
and
then
you
have
a
service
with
a
service
type,
but
service
type
is
a
key,
an
identity
re.
So
is
that
really
a
type
or
is
that
an
a
pointer
to
an
instance
of
a
service
because
the
way
I'm
looking
at
this,
you
could
only
have
one
service.
B
C
Yeah
that
that
that's
a
good
observation,
actually,
you
can
have
multiple
services
under
the
same
node
and
the
the
multiplexing
will
be
done
by
the
attachment
interface
itself,
in
which
you,
for
example,
you
can
have
multiple
sub
interfaces
that
can
be
associated
with
the
same
service,
and
you
can
use
that
as
a
demultiplexer.
If
you
need
that.
E
Robertson,
cisco,
as
a
contributor.
In
that
scenario,
though,
wouldn't
you
end
up
finding
the
sub
interface
as
the
service
interface,
the
circuit
interface.
C
The
sub
does
not
always
require
a
sub
interface
to
be
present,
but
it,
but
I'm
not
sure
the
cd
and
the
case
you
are
you
are
referring
to
is
so.
If
you
can
just,
I
would
say,
clarify
for
that
would
be
great
if.
E
You
yeah,
if
you
had
multiple
pseudo-wires
point-to-point,
survivors
or
vps
surfaces,
then
they
would
all
be
terminating
for
the
same
pe
device
and
each
of
those
would
have
a
separate
sub-interface
on
that
on
a
given
pe
interface
to
each
of
those
different
services.
I
just
wanted
to
check
that
that
could
be
modeled
here.
Basically
on
on
the
back
of
scott's
comment,.
C
Yeah
yeah:
I
need
to
check
this
one
for
the
specific
specific
case.
C
G
Last
question:
thanks
drove
here,
one
question
met
in
the
document.
We
say
that
this
model
can
be
seen
as
an
inventory
model,
and
I
have
a
little
query
on
that.
Like
you
know,
because
I
I
also
noticed
that
in
c
camp
there
is
a
document
and
they
are
also
asking
for
feedback
on
where
to
do
the
network
inventory
model,
and
I
all
my
first
question
is:
is:
can
really
this
model
be
seen
as
an
inventory
model?
G
C
Yeah
that
that
that's
a
good
question
for
me,
it's
still
an
inventory
model
but
yeah
it's
up
to
the
working
group
to
I
would
say,
to
check
the
other
work
and
to
see
if
there
is
something
to
be
here
to
be
said.
There.
H
B
Okay,
next
up
bow.
I
Hello,
everyone:
this
is
paul,
I'm
going
to
present
this
young
model
for
network
and
vpn
service
performance
monitoring
drug
on
behalf
of
all
the
authors.
I
I
I
So
now
we'll
talk
in
the
next
slide
and
we
also
in
the
github
hacked
all
the
issues
that
we
all
and
we
also
addressed
all
those
issues.
So
thank
you
next,
please,
and
here
is
the
the
comments
that
I
just
mentioned.
I
Like
this
there's
three
version,
we
have
only
the
tunnel
we
put
in
a
blue
color
that
in
the
overlay
vpn
topology
their
workflow
link
between
this
virtual
node
that
represent
a
qpe
there,
and
but
we
we
don't
have
that
we
don't
have
exact
volume
method
to
measure
the
virtual
link
oem.
So
we
use
the
tunnel
performance
monitor
metric
to
represent
that
virtual
link,
om
statistics.
I
So
there's
the
comments
is
about
that.
It
also
should
be
allowed
that,
like,
inter
vpn
access
interface,
that
that,
because
they
are,
there
are
already
some
common
praxis
there.
That
used
like
t-ramp
and
other
oem
method
can
be
used
to
measure
that
per
vpn
performance
monitoring.
So
so,
in
the
the
first
revision,
four,
we
add
a
a
new
node.
I
We
call
it
vpn
performance
type
and
we
also
use
the
choice
definition.
So
the
reason
why
we
choose
type
choice
is
that
we
think
the
inter
vpn
access
interface
performance
monitor,
can
cover
the
like
the
the
tunnel
part
measurement.
So
we
think
so.
These
methods,
two
measures
on
either
of
them,
can
be
used
to
represent
vpn
performance
monitoring
that
abstract
link
performance
monitoring.
So
that's
the
reason
we
choose
choice,
so
we
like
to
hear
if
there
are
other
comments
on
this
so.
I
So
since
we
think
they
have
addressed
all
the
issues,
so
the
next
step
is
the
the
author's
impress
iesd
publication.
B
Comments
bo
on
the
on
this
choice.
I
B
Do
you
think
you
have
enough
so
last
hall
is
is
like
I
mentioned
wound
down.
Do
you
have
enough
input
here?
Is
there
others
in
particular,
that
you
would
like
to
get
insight
or
or
thoughts
on
before
handing
this
up
to
the
iesg.
I
Right
now
we
we
have
published
revision4
to
like
already
add
this
choice,
so
I
don't
know
if
that
make
our
working
group
labs
call
like
their
other
is
need.
Another
last
call
you.
B
I
don't
know
listening
to
you
talk
it
sounded
like
there
might
need
to
be
some
other
eyes
on
this.
It
seems
like
a
substantive
change
that
just
snuck
in
once
the
window
opened
it
might
benefit
from
another
week
or
so
once
things
settle
down.
B
I
I'd
like
to
understand
how
what
you
feel
you
you
feel
comfortable
with
given,
given
what
you've
just
stated
here.
I
Oh,
I'm
I'm
fine
with
you,
I
mean
we
definitely
we
discussed
this
is
to
like
we.
We
hope
that
a
working
group
can
have
more
review
on
this,
because
in
that
way,
that
will
be
more
the
text
and
also
the
model
will
be
refined.
So
I
think
from
my
viewer
I'm
buying
this.
So
if
matt
and
other
authors
don't
have
other
like
they
don't
have
other
opinions
on
filemakers.
B
D
So,
okay,
we
produced
new
versions
of
this.
This
work
I'm
going
to
be
quick
here
and
again
by
you
some
minutes,
so
the
next
slides
I've
got
one
intro
on
what
this
work
is
about.
I
printed
multiple
times.
I
don't
plan
to
go
through
it.
If
it's
new
to
you
quickly
review
the
the
slides
now
on
the
next
slide,
joe,
we
added
in
in
the
version
two
of
the
draft
we
added
information
about
circular
dependencies.
D
There
were
discussions
with
edius
lear
and
rob
so
we
added
that
in
this
latest
version
we
added
a
specific
example
of
you
know
how
to
prevent
circular
dependencies.
D
Okay
in
the
next
slide,
please
what
we've
been
adding
also
and
that
came
from
our
prototype-
is
that
whenever
we
have
like
the
health
score
for
a
subservice,
sometimes
we
don't
have
it
yet,
because
we're
busy
calculating
in
the
prototype
you're
reporting
zero
as
a
health,
and
somehow
it
was
a
mistake.
It
was
just
missing
right.
It
was
selling
the
wrong
information.
D
D
D
B
As
a
contributor,
I
I
responded
to
john
today.
I
yes,
okay,
the
version
I'm
not
in
love
with
it,
but
whatever
the
the
example
that
the
like
implementation
suggestion,
I
think,
would
also
be
a
useful
addition.
Just
for
others
who
might
want
to
understand
how
best
to
to
implement
some
of
the
the
health
and
weighting.
B
Wow
cranking
right
along
thomas.
M
M
Okay,
perfect,
so
I'm
thomas
from
swisscom,
so
this
is
about
export
of
segment.
Routing
ipv6
information
in
ipfix
next
slide,
please
so
just
to
give
some
background,
so
segment
routing
can
be
leveraged
in
the
ampeles
data
plane
and
also
in
the
ipv6
data
plane.
So
we
have
with
rfc9160.
M
The
extensions
needed
for
adopting
it
on
ampullar
segment,
routing
just
in
a
nutshell,
to
describe
basically
the
ipfix
entity
70
describes
the
mpls
top
label
stack
section
which
basically
describes
the
label,
the
the
the
experimental
bit
and
the
bottom
of
the
stack
bit
while
the
basically
the
rest
of
the
amplis
label
stack
is
decomposed
in
ibifix
entity
71
to
79
separately.
M
The
ibfx
entity
47
basically
exposes
the
ample
stop
label
ipv4
address,
while
ib
entity
for
46,
basically
from
which
routing
protocol
that
prefix
and
label
has
been
coming
from,
and
since
this
was
the
only
change
between
emperors
and
mpls
segment
routing.
So
basically,
there
were
new
routing
protocols
such
as
ospf
isis
and
also
pgp
and
pc
being
introduced.
M
We
are
updating
the
the
ipfix
top
label
type
registry
next
slide.
Please.
M
So,
in
order
to
bring
data
plane,
visibility
in
srv6,
basically
in
a
nutshell,
we
are
so
in
so
currently,
sov6
is
already
deployed
in
service
provider
networks.
We
have
the
first
few
cases
which
are
actually
providers
are
migrating
from
mpls
towards
sov6
and
we
believe
as
autos.
It's
currently
data
plane.
Visibility
is
missing,
especially
in
such
migration
scenarios.
M
It's
very
beneficial
that
we
can
see
actually
how
much
traffic
is
being
forwarded
or
dropped
towards
a
seat,
so
in
order
to
gain
visibility
into
srv6.
Basically,
the
segment
routing
header
needs
to
be
exposed.
M
The
segment
routing
has
described
in
section
2
of
rfc
8754
next
slide,
please,
and
when
being
decomposed
in
in
ipfix,
we
have
the
ipv6
srh
segments
left,
basically
describing
at
which
point
we
are
in
the
in
the
segment
list,
while
the
ipv6
srh
tech
and
sfvsh
flex,
basically
exposing
the
text
and
the
flex
from
the
srh
header
and
the
ipv6
srh
segment
type
basically
describes
which
routing
protocol
that
the
city
is
coming
from
next
slide.
M
M
So
there
is
two
ways
how
we
are
able
to
expose
the
the
the
seat
list,
either
as
a
as
a
basic
list
as
all
the
basic
list
or
as
an
entire
list
section.
M
M
Basically,
it
has
no
direct
impact
because
the
c
the
the
cc
container
is
still
a
128
bit
long
ipv6
address,
but
it
contains
basically
multiple
seats
in
in
a
cc
container
and
they
are
mutually
exclusive.
M
It
probably
makes
sense
that
we
are
adding
in
the
draft
document
an
operational
consideration,
consideration
section
to
describe
what
needs
to
be
done
on
the
iphix
data
collection
site
to
distinguish
between
an
ipv6
sheet
and
sees
it
container
from
what
we,
as
authors,
understood
it
most
likely
doesn't
bring
much
added
value
if
we
are
actually
decomposing.
M
So
the
current
draft
status
we
already
received
feedback
from
spring
ops,
awg
and
the
ipfix
doctor
for
the
feedback.
We
introduced,
the
ipv6
srh
section
and
soh
section
segment
list
section
and
we
added
the
ipv6
sfh
segments
left
so
that
we
can
express
at
which
position
of
the
segment
list.
The
forwarding
is
happening
and
that's
useful
for
detecting
forwarding
loops.
M
M
M
Next
slide,
please
next
step.
So
do
you
recognize
the
problem
statement
that
data
plane
visibility
is
missing
in
srv6
we
as
authors
believe
that
this
document
should
progress
quickly
through
itf
to
void
that
private
enterprise
code
points
are
being
used
for
srv
six
deployments
and
therefore
we
would
like
to
call
for
adoption
at
ops
awg.
N
Hi
thomas
thomas
just.
M
P
My
question
was:
just
you
know,
people
who
are
implementing.
B
Q
Hello,
thank
you
cheers
for
having
the
luxury
to
present
here
in
itf,
first
time
presenting
live
previous
time.
We
were
presenting
the
mlmo,
a
data
model,
life
cycle
management
and
operations,
the
version
2.
We
are
running
actually
version
4,
which
is
uploaded
already
on
the
data
tracker,
the
authors.
We
have
been
adding
developers
who
is
also
here
on
the
list
of
authors,
and
we
can
go
to
the
next
slide.
Q
Q
If
we
go
to
the
next
slide,
please,
if
you
can
see
and
compare
with
the
previous
version,
everything
that
is
in
yellow
is
new.
We
have
been
adding
on
this
flexibility
and
consistency
on
the
structure
where
we
have
been
defining
instances
and
every
one
of
the
modules
that
we
were
defining
in
previous
version
is
called
an
instance
now
where
they
are
called
based
on
the
idf
lmo
module.
Q
Q
Q
Including
the
on
this
structure,
how
we
call
and
how
we
reference
in
previous
version,
we
were
defining
assets
and
sub-assets
as
part
of
a
container
same
thing
for
licenses
and
sub
licenses
features
and
sub
features.
Here
on
this
structure,
we
either
adding
and
complimenting
on
how
we
address
different
reference
from
one
to
many.
In
this
case,
access
to
features,
we
can
have
many
features
in
there,
users
to
organization.
Q
If
we
go
to
the
next
slide,
another
example
of
what
the
extension
we
have
done
with
the
flexibility
and
consistency.
It
is
how
we
call
this
combo
structure
where
we
can
reference
a
previous
instance.
In
this
case
licenses.
We
can
represent
in
a
better
way
that
it
was
done
before
on
the
on
this
example
that
you
have
here
on
the
licensing
on
the
next
slide.
Q
For
organizations,
here's
an
example,
but
it
has
it,
it
applies
to
the
other
data
sets
as
well.
We
have
this
hierarchy
represented
with
a
parent
and
child
structure
and
an
organization.
You
can
see
clearly
an
example
how
to
use
it,
and
we
can
call
organizations
within
organizations
as
part
of
this
hierarchy
structure
and
in
the
department
on
it.
Q
Q
Our
asks
and
next
steps
we
welcome
and
appreciate
feedback.
We
have
been
setting
up
these
site
meetings
where
we
have
collaboration
from
huawei
from
benue
from
telefonica
as
well
from
luis,
and
we
are
open
to
get
more
feedback
on
it.
We
have
this
meeting
set
up
every
two
weeks.
We
will
be
extending
it
to
be
every
month
just
to
make
sure
that
the
good
work
is
addressed
on
the
side
meetings
and
as
part
of
the
next
steps
we
understand,
and
this
has
been
discussed
and
we
can
ask
the
alias
the
actually.
Q
The
the
working
group
here
we
have
been
discussing.
The
licenses
is
a
complex
issue
and
we
understand
is
a
complex
issue.
We
are
working
to
evaluate
how
to
tackle
licensing
and
we
are
working
camilla
specifically
together
with
sweeta,
are
addressing
this
licensing
concept
and
we
are
addressing
as
well
and
for
the
next
revision.
Q
We
have
to
really
work
on
that,
how
to
iterate,
through
the
young
modules,
going
to
more
specifics
on
how
we
define
the
type
of
attributes
going
to
the
anoms
against
identities
and
also
some
of
the
attributes
that
are
stuck
tackled
as
mandatory,
and
there
are
some
specifics
on
how
we
define
addresses
as
well
as
part
of
the
assets.
But
those
are
specifics
that
we
can
discuss
further
as
well.
Now
we
are
open
to
questions
and
welcome
your
feedback
on
what
has
been
done.
E
So
I
spoke
to
you
earlier
about
this
and
I
just
wanted
to
share
some
comments.
I've
made
to
you
here.
I
think
this
is
a
very
interesting
problem
to
be
approaching,
and
I
think
it
has
a
lot
of
potential
value.
The
tricky
things
to
solve
is
making
sure
it
has
both
enough
flexibility
to
be
widely
applicable
to
different
vendors
and
things
and,
at
the
same
time,
having
enough
commonality
that
you
can
then
correlate
that
data
together
and
make
use
of
it.
It's
not
sort
of
too
different.
E
E
In
a
very
specific
case,
it's
not
exactly
the
same
and
they've
and
the
way
that
they've
built
their
flexibility
is
to
allow
this
sort
of
arbitrary
parent
child
hierarchy
to
be
set
up
and
then
flattened
into
a
list,
and
you
have
similar
sorts
of
things
with
this
sort
of
parent
point
or
maybe
children
pointers.
So
I
think
that's
a
good
thing
and
then
they're
using
identities
to
identify
particular
properties
or
sub
properties
and
extending
it
that
way.
So
I
think
identities
is
probably
better
choice,
mostly
than
enumerations,
because
it
allows
more
flexibility.
E
I
also
think
that
trying
to
concentrate
on
the
core
subset
of
the
functionality
that
is
widely
applicable
would
be
a
good
starting
point
and
then
to
try
and
build
extra
functionality.
Honors
augmentation
young
models
or
a
separate
draft
might
be
a
good
way
of
trying
to
get
a
good
common
core
that
people
can
work
on.
Q
Yes,
thank
you
rob.
I
I
think
we,
as
you
mentioned
before
we
were
discussing
on
this.
It
will
be
good
to
get
the
review
on
those
specifics
as
well
answering
on
the
on
the
list,
just
to
make
sure
that
we
have
a
good
review
but
agree
agree
with
with
all
the
comments,
and
we
could
even
reduce
the
modules
just
making
sure
that
is
common
to
more
vendors
right,
and
this
is
kind
of
the
exercise
that
we
want
to
do
on
the
iteration
going
forward.
Q
I
Can
you
hear
me
yeah
yeah?
I
have
a
clarification
question
on
this,
so
this
model
is
the
device
model
or
like
a
noise
bond
interface
model
of
like
network
controller.
Q
I
So
this
is
not
device
model
from
your.
Q
D
So
bernoullis,
so
I
want
to
address
two
points
so,
first
of
all
the
inventory,
because
we've
seen
that
it
was
discussed
multiple
times,
we
even
learned
today
that
there's
a
c
camp
inventory
model.
So
there
are
multiple
definitions
of
inventory.
D
There
is
like
the
the
inventory
like
the
entity
map
in
the
past,
and
you
got
the
young
male
for
that.
There
is
like
the
inventory
for
what
is,
in
the
end,
a
platform
or
device
so
to
make
the
link
with
what
beau
was
mentioning.
There
is
like
device,
but
whether
you
see
this
on
top
of
a
controller,
they
still
need
to
have
the
same
characteristic
device.
It's
like
an
id.
It's
like
a
vendor.
It's
like
an
os,
it's
like
a
type
and
all
this,
and
we
start
to
have
this
in
many
different
places.
D
Okay,
maybe
I'm
dreaming
of
a
grouping,
a
grouping
where
we've
got
the
same,
the
same
thing
in
yang
right,
but
that's
something
we
have
to
pay
attention
to
to
not
redefine
the
same
thing
over
and
over.
That's
one
point
and
the
second
one
is
about
licensing.
So
you
you
mentioned,
I
was
attending
the
course
yes
and
my
main
feedback
was
that
licensing
is
very
complex.
D
Q
And
we
have
also
addressed
on
that
question
or
comment.
It
is
complex.
Q
We
want
to
see
how
far
we
could
get
on
the
use
cases
that
we
are
operating
and
we
are
working
on
that
and
camilo
and
sweeta
are
the
main
people
looking
at
that
at
the
moment,
and
we
will
be
following
up
on
the
side
meetings
from
that
on
the
inventory.
We
have
been
also
discussed
previously
to
this
meeting
on
how
to
address
that.
Q
I
would
say
that
it's
not
a
use
case
specifically
from
this
dml
mmo
having
inventory,
but
we
have
to
define
somehow
those
entities
that
we
are
addressing,
what
we
call
assets
and
there
are
some
attributes
already
defined.
If
the
working
group
decide
to
go
to
an
inventory
approach,
we
will
be
helping
and
supporting
on
that
idea
as
well.
B
Thanks
marcel,
I
ran
a
poll,
while
you
were
talking
of
the
participants.
20
decided
to
either
raise
or
not
raise
their
hand.
There
were
14
in
support
of
the
work,
and
I
was
curious
as
chair
you're
not
asking
for
adoption,
but
there
does
seem
to
be
a
lot
of
people
working
on
this.
So
I
I
think
we
do
have
to
address
some
of
the
questions
that
that
have
been
raised
and
see
how
we
want
to
proceed.
B
O
Yes,
thank
you,
and
this
is
a
already
adopted
work
item.
I
asked
to
go
a
little
bit
later
because
I
had
a
conflicting
meeting
earlier
so
yeah
just
an
overview
as
we
are
looking
to
update
the
tls
transport
model
of
snmp
v3.
O
So
the
effort
was
approved
after
ietf112,
we've
updated
the
fingerprint
algorithm.
The
big
challenge
there
is
that
the
existing
algorithm
references,
tls
1.2
hashing
table
that
hashing
table
will
no
longer
be
maintained.
Now
that
they've
migrated
to
1.3
and
that
that's
a
hash
of
the
x.509
cert,
the
we've
received
comments.
We've
addressed
all
of
those
comments.
We've
posted
a
new
draft,
so
I
think
we've
resolved
everything
now
and
if
you
go
on
next
slide,
the
big
change
is
that
we
figured
out
how
to
handle
this
hashing
table.
O
Initially,
we
thought
thought
about
the
concept
for
replacing
the
fingerprint
algorithm
that
results
in
changing
all
of
the
mid
op
objects
and
uses
the
new
identifier
table.
That's
a
major
overhaul
to
the
nib,
so
we
wanted
to
avoid
that.
O
O
The
good
news
is
that
we
determined
that
we
could
actually
just
revise
the
definition
of
our
fingerprint
algorithm
to
use
a
duplicated
table
if
you
will
so
take
the
tls
1.2
table
as
it
exists
today.
That
is
not
going
to
change
copy,
that
to
a
new
table,
revise
the
definition
of
our
fingerprint
algorithm
to
point
to
this
new
table,
and
now
we
can
extend
that
table
as
we
need
to.
O
It
seemed
to
have
timed
out
for
some
reason
and
flipped
me
on
mute,
okay,
so
the
bit,
but
we
determined
by
consulting
with
nib
experts,
that
we
would
be
able
to
make
this
change
without
having
to
go
back
and
revise
all
of
our
table
structure
within
the
nip.
So
this
is
a
fairly
easy
fix,
and
that
is
what
the
most
recent
draft
reflects.
O
There
were
some
other
items
that
we've
updated
compared
to
the
current
rfc.
We've
clarified
that
authentication
and
privacy
are
always
provided.
That's
just
the
natural
part
of
tls
1.3.
O
We
remind
your
readers
of
the
updates
in
8996,
which
prohibits
tls
versions
prior
to
1.2.
We
are
prohibiting
the
use
of
the
zero
rtt
feature
of
1.3,
clarifying
tls
compliance
requirements
and
updating.
We
made
some
minor
edits
to
capitalize
some
keywords
to
be
conformant
with
bs
bcp14.
O
O
So
there
are
some
edits
that
I've
discovered
since
the
last
draft
that
will
be
in
an
upcoming
draft
shortly.
O
O
We
should
remove
the
double
quotes
that
are
within
the
description
clause
of
s
mp,
tls
fingerprint
just
some
other
nets,
removing
references
that
are
not
used
in
this
document.
Removing
the
appendix
examples,
because
they're
just
identical
to
the
existing
rfc
and
the
the
final
change
or
a
question
I
have,
I
think,
is
whether
we
should
change
the
name
of
the
proposed
table.
O
O
O
So
that's
pretty
much
where
we
are,
I
think,
with
those
final
edits,
we
should
be
pretty
close.
We
will
send
it
out
for
a
final
review
and
comment
and
then
we
can
start
the
last
call
process.
I
think-
and
we
will
also
make
sure
we
distribute
this
to
the
tls
reflectors
as
well,
since
it
can
impact
them.
S
Without
hats,
so
sorry
no
had
no
chair
head
on.
So
I
guess
that
also
in
in
cozy
they're
working
on
hashing
algorithm
index,
it's
probably
worth
a
look.
S
They
want
to
do
that.
So,
if,
if
there's
overlap,
just
swing
just
make
sure
that
the
indices
are
equivalent,
I
think
that's
the
most
important
thing.
I
think
the
tls
might
have
a
different
subset
than
the
thing
cozy
wants
to
do.
But
again
there
are
indices
in
there
today.
So
if
three
would
mean
the
same,
three,
the
confusion
would
be
way
less.
So
I
think
that
would
be
interesting
to
think.
That's
just
from
my
side.
B
I
was
gonna
say
something
maybe
similar
as
a
contributor.
I
I
honestly,
I
feel
my
gut.
My
initial
reaction
was,
it
might
want
to
stay.
Snmp
is
the
name
of
the
registry
just
because
of
what
we
ran
into
with
tls,
where,
if,
if
it
does
cause
some
sort
of
semantic
change
down
the
road,
if
others
want
to
add
things
to
it,
that
essent
that
this
wouldn't
support,
but
hank
brings
up
a
good
point
if
there
are
overlap
that
that
aligns.
Maybe
then
that
that
can
help
inform
your
decision,
can.
O
Okay,
I
I
think
we
would
want
to
avoid
any
changes
to
the
existing
tls
1.2
table.
Any
reassignment
of
those
numbers.
N
O
A
simple
basis
that
if
we
did
it
would
break
backwards,
credibility
but
but
but
any
if
there
are
additional
items
that
aren't
in
that
table.
Yet
we
can
certainly
add
those.
E
Just
to
sort
of
I've
not
read
this
latest
version
of
the
draft,
so
my
one
question
is,
and
you
may
already
cover
this-
is
if
new
items
were
added
into
the
existing
tls
1.2
io
registry,
what
process
would
be
involved
to
make
sure
they
also
updated
into
this
new
registry?
O
I
it,
I
think,
so
I
think
it's
just.
How
do
we
add
a
reg,
a
new
registered
item?
I
would
assume
that
ayanna
has
formal
processes
for
that.
I'm
not
sure
that
we
need
anything
in
our
text,
but
I'm
happy
to
just
happen
to
hear
your
comments
so.
E
B
B
So
adding
1.3
algorithms
to
here
with
a
one
byte
registry
value
would
imply
that
they
work
with
tls
1.2
when
they
don't
my
under
again.
My
understanding
is
that
there
will
not
be
any
more
additions
to
this
registry,
and
that
is
why
they
recommended
we
fork
our
own.
E
Okay,
so
I'll
phrase,
my
questions
like
different
ways.
If
this
is
an
snnp
specific
registry,
then
it'll
pick
up
some
default
values
to
start
off
with.
How
does
it
need
to
make
sure
that
if
there's
new
entries
added
to
tls1.3,
they
also
get
updated
into
this
snmp
registry?
And
if
so,
we
want
to
make
sure,
there's
text
to
make
sure
that
happens
automatically
and
not
having
to
be
a
manual
step.
That's
the
thing
I'm
trying
to
get
it!
No.
P
P
Okay,
so
what
they're
saying
is?
Are
they
shutting
down,
so
somebody
should
take
an
action
if
they
think
that
this
is
going
to
be
a
problem
like
they
should
take
a
standards
action
to
shut
down
new
entries.
Otherwise,
you
know
it's
up
to
the
experts
right
and
the
the
experts
are
meant
to
be
guided
by
you
know,
whatever
their
their
best.
Knowledge
is
so
it
doesn't
sound
like
you
can
absolutely
affirmatively
say
that
there
will
be
no
new
entries.
B
That's
fair
point
again:
I
was
going
off
the
what
the
those
experts
replied
to
us
with,
but
that
that
is
a
fair
point,
and
in
that
case
the
text
would
probably
need
to
cover
the
addition
to
either
the
tls
1,
2
or
1
3
and
registries.
R
D
All
right,
so
I
want
to
present
a
draft
which
is
about
data
manifest
for
streaming
telemetry.
We
changed
the
title.
We
improved
it
thanks
matt
for
that.
This
is
actually
data
manifest
for
contextualized
streaming
data
and
we
posted
a
version
two
this
week
with
a
couple
of
updates.
So
let
me
go
to
the
next
slides.
D
D
So
on
one
side
we
have
the
product
capabilities
which
mean
that
I
could
tell
if
a
specific
yang
object,
supported
unchanged
or
not,
though
so
I
could
configure
it.
But
what
we
don't
have
is
that
I
don't
know-
or
it
was
actually
metered
right
and
under
which
circumstances
specifically
whenever
the
device
is
not
there
any
longer
so
on
the
next
slide.
D
Let's
take
an
example,
we
see
this
from
a
data
collection.
Vantage
point
on
the
left:
we've
got
time,
one
with
a
counter
which
is
value
is
42.
It's
always
42
right
and
the
status
is
up
now,
I'm
in
time,
which
is
now,
and
there
are
no
updates-
and
I
see
this
from
a
pure
data
collection
point
of
view,
so
what's
happening
well,
there
is
a
problem
because
my
telemetry
has
an
issue
or
there
is
a
bug
or
the
sender.
D
The
router
is
overloaded,
so
can't
send
anything
or
there
is
no
problem,
because
there
is
just
a
long
cadence
in
my
telemetry
or
there
is
no
problem
because
it's
unchanged
it
has
not
changed
or
maybe
there
is
this
feature
in
my
company,
which
is
super
redundancy,
which
means
if
they
haven't
changed,
don't
say
it
to
me,
and
I've
got
no
way
to
know
this
from
a
pure
data
collection.
Point
of
view
right
so
I
will
be.
I
might
be
drawing
the
wrong
conclusion
in
terms
of
anomaly
and
the
connection.
D
We
want
to
propose
data
manifest,
so
basically
context
information
and
there
are
two
of
them.
The
first
one
is
the
platform
manifest
right,
characterizes
the
platform
producing
the
data,
and
you
see
it
could
be
perceived
as
inventory.
This
was
the
camera
was
making
before
the
source
router
the
source
device
and
the
other
one
is
like
the
data
collection
manifest
characterizes
how
and
when
the
telemetry
was
metered.
D
Okay,
the
principles
here
is
that
whenever
you
stream
telemetry,
this
contact
information
must
follow
the
data
right
and
if
the
data
are
moved
to
a
different
place,
there
still
must
follow
the
data,
because
without
the
context
we
have
data-
and
we
can't
take
much
information
about
it,
much
actions
about
it.
Sorry
next
slide.
D
So
that's
the
typical
p
yang
tree
and
we've
been
adding
at
the
top
like
the
vendor
and
by
the
way
we
added
a
nacio
from
the
madrid
university
as
an
author.
This
was
his
feedback
and
this
is
aligned
with
the
again
the
platform
information
coming
from
the
young
catalog,
because
we
always
deal
with
the
same
type
of
tuples
right.
D
We
also
included
the
the
full
yang
library
to
get
information
about
the
data
store.
We
corrected
a
small
mistake
that
this
young
module
was
read
right.
No,
it's
not
it's
only
read-only,
along
with
the
data
you've
got
this
contact
information
you're
not
supposed
to
change
it.
It's
from
the
source
right
and
the
package
sets
so
on.
The
next
slide.
D
This
is
information
about
the
data
collection,
manifest
right,
we're
telling
like
well
per
subscription
id
well,
what
is
the
requested
period,
the
actual
period,
the
unchain
yes
or
no
su
presidency,
and
we
added
also
from
widget.com.
There
are
some
potential
interesting
use
cases
there,
comparing
what
is
in
intended
or
candidates.
D
On
the
next
slide,
we
could
ask
ourselves:
how
frequently
do
you
do
we
update
those
two
manifests
the
platform
one.
It's
only
one
ever
get
a
platform
change,
typically
a
reboot
chain
of
os,
okay,
so
not
very
frequently
now
for
a
data
collection,
one
we
update
it
whenever
the
collection
condition
changed.
Typically,
I
change
the
cadence.
I've
got
the
new
subscription
orders.
The
correction
third
is
adjusted
based
on
cpu
all
right
on
the
next
slide,
we're
thinking.
Well,
we
should
be
using
telemetry
information.
D
D
So
we
identified
a
couple
of
improvements
right
and
that's
where,
if
you
want
go
to
the
mic
at
the
end
and
discuss
this
well,
one
of
them
was
about
the
source
of
data
and
the
self-assertiveness.
D
How
do
I
know
that?
Actually,
if
you
are
a
vnf
or
router
well,
can
I
trust
you
right
and
there's
also
the
issue
of
data
integrity?
What
if
someone
would
change
this
information
now?
What
we
need
to
do
here
is
actually
analyze
the
threat
model
right,
which
is
basically
management
traffic
inside
your
domain,
but
we
have
any
way
to
do
it
right.
D
Personally,
I
always
believe
pragmatically
that
if
someone
is
changing
just
this
source
of
data
he's
able
to
attack
you
on
the
front,
maybe
you
have
bigger
problem
than
just
changing
the
contact
information,
but
you
know
we'll
have
to
pass
security
80s
at
some
point
in
time.
So,
let's
analyze
the
third
model,
open
questions.
D
Well,
we
could
do
that
for
other
types
of
information.
The
context
right
for
snmp
for
ip
fix.
Well,
ipfx,
if
you
do
sampling,
you
want
to
know
you're
doing
something
to
the
same
complex
information
type
same
type.
D
R
E
Yeah
rob
is
a
participant
thanks
ben
well,
I
think
to
recognize
the
problem.
So
absolutely.
I
definitely
think
this
is
a
very
interesting
problem.
I
think
it's
very
hard
one
to
solve
and
I
think
one
of
the
key
questions
it
looks
like
you
are
returning
the
metadata
per
subscription.
Is
that
correct,
which
I
understand?
E
Why
you're
doing
that,
because
otherwise
it's
going
to
be
too
much
data,
but
I
wonder
actually
whether
to
really
solve
this,
you
almost
need
the
metadata
per
leaf
field,
that's
being
pushed
off
the
box,
because
if,
for
example,
you've
got
a
subscription,
an
interest
goes
away
and
it
stops
returning
data
that
interface,
I'm
not
sure
whether
you
would
spot
that.
But
if
you
do
it
per
the
leaf
node,
then
you
end
up
with
too
much
data.
So
I
think
it's
an
interesting
problem
to
solve.
D
It's
tricky
it's
tricky.
There
was
an
mrg
like
a
comment
about
digital
twin
right,
and
the
gentleman
there
mentioned
that
somehow
we
start
to
be
in
the
world
of
data.
Oh
forget
it
now:
data
driven
ai,
which
is
actually
trying
to
find
out
because
all
it
is
sometimes
they
want
to
have
all
the
data
right.
We
have
to
be
slightly
pragmatic,
specifically
whenever
we
speak
operators,
so
this
is
trying
to
find
out
how
much
data
do
we
need
at
the
minimum
to
be
able
to
solve
the
problem?
D
Ideally,
everything
per
node
all
the
time,
every
single
flow
data
plane
in
practice.
There
is
like
middle
ground,
so
I
agree
with
you
with
your
statement
and
with
the
subscription
id
we
could
find
that
find
out
which
notes
are
in
there
and
that's
a
compromise.
E
But
but
in
terms
of
wanting
to
know
both
when
a
value
was
was
actually
written
and
how
fresh
it
is,
those
two
properties,
I
think,
are
important.
So
I
think
that
is,
I
think
it's
interesting
problem.
S
So
hi
this
is
hank
again
with
no
heads
on
so
so
your
this
manifests.
How
I
understand
it
is
combining
quite
a
few
of
different
types
of
information,
so
it's
all
from
the
subscription
side.
So
the
subscription
also
deals
with
the
same
problem.
At
the
beginning.
You
sell
everything.
Whatever
you
subscribe
to,
you
don't
know
what
the
receiver
knows.
So
you
get
a
full
iframe
so
to
speak,
and
that's
the
same
with
metadata.
S
You
would
give
the
full
meta
that
I
want,
but
that
can
be
slimmed
down
later
and
then
outside
of
the
subscription
context.
As
like
integrity,
I
heard,
and
when
I
hear
integrity
sometimes
I
always
always
think
remote
attestation
trustworthiness.
So
I
might
have
some
future
comments
on
that
because
I
think
that's
also
metadata
that
will
change,
because,
especially
if
the
identity
of
the
composite
system
changes
due
to
vital
elements
changing
and
then
for
its
expressiveness
and
trustworthiness
changes.
H
No,
no,
it's
just
what
just
say
that
developers
developers.
Yes!
Thank
you.
No,
it's
precisely
this!
We.
We
are
right
now
very
much
involved
in
projects
that
are
related
to
this
too,
not
the
data,
the
metadata,
because
we
are
right
now,
when
you
analyze
how
the
network
is
behaving,
we
are
feeling
the
deluge
and
we
need-
and
this
this
kind
of
initiative
is
something
that
is
of
extremely
extreme
interest
to
us
just
to
as
a
as
a
node.
T
Oh,
oh,
okay,
that's
great!
Okay!
I
thank
you,
so
I'm
misha
wang
from
china
chinamobile,
so
I
will
present
this
work.
In-Band
flow
learning
framework,
also
on
behalf
of
louie
and
friend
the
courses.
So,
okay,
next
slide,
please
so
the
network
telemetry
is
provides
a
network
visibility
and
tools
to
the
state
and
behavior
of
a
network.
So
it
is
a
crucial
to
network
operations
and
load
supervisions.
T
So
from
our
operator's
perspective,
it
is
important
to
monitor
the
live
traffic,
including
the
delay
and
packet
loss,
and
previously
we
have
presented
the
problem
statement
of
the
event
flow
telemetry
deployment
on
the
last
itf
committee,
so
just
mention
that
we
really
have
a
large
scale
of
5g
backhaul
networks
like
like
40
400,
000
network
nodes
and
already
have
fifty
hundred
thousand
base
stations.
T
So
so
this
issue
is
really
important
issue
in
our
large-scale
network
and
in
this
draft
we
are
going
to
propose
a
framework
of
the
indent
and
flow
based
information
learning
mechanism
to
try
to
solve
the
problems
in
our
deployment
of
the
television
okay
next
piece
also.
First,
the
framework
of
the
in-band
flow
learning
includes
three
components
of
service
discovery
and
telemetry
deployment
and
telemetry
adjustments.
T
So
for
each
components
there's
many
functions.
I
like
in
service
discovery.
The
main
function
is
to
do
flow
characteristic
acquisitions
and
in
commentary
deployment.
The
main
functions
are
to
figure
the
telemetry
type
policy
and
instance,
and
for
the
adjustments
the
most
important
function
is
for
aging,
so
there
are
still
methods
to
do
those
functions,
so
the
differences
between
the
methods
we
listed
here
and
then
the
controller
trigger
or
deploy
all
the
device
deploy
or
trigger,
and
sometimes
they
work
together
to
to
complete
a
function.
T
So,
okay,
next,
please
and
here
for
the
service
discovery
we
consider
is
a
process
of
sampling
to
the
service
flow
which
is
being
transmitted
in
the
network
and
in
order
to
further
determine
which
flow
should
be
monitored
and
depends
on
the
characteristic
of
the
service
flow
like
ip
source
address,
ip
destination,
address,
tcp,
udp,
port
numbers,
vrf
interface,
network
nodes
and
also
can
be
mac
address
or
the
combinations
of
these
characteristics
and
to
target
the
service.
Discovery
is
to
obtain
these
flow
characteristics
from
the
traffic
and
it
can
be
configuration
triggers.
T
You
can,
based
on
the
database
of
a
planned
service
flow
information
which
is
stored
on
the
central
controller
and
we
can
obtain
it
from
the
network
operations
so
such
as
a
table
of
services
between
the
base
station
and
co
network
equipment
in
our
5g
backhoe
scenario,
and
we
also
can
do
device
triggers
like
live
traffic
sampling
and
to
relies
on
the
capability
of
forwarding
plane
of
a
network.
Node.
T
The
parametric
deployment
functions
are
type
policy
and
deployment,
so
first
type
we
should
consider,
is
end-to-end
type
or
hope
I
hope
type
for
end-to-end.
You
can
just
got
the
report
from
the
endpoint
and
egress
node
and
for
hobart
hub
each
node
on
the
path
should
report.
The
performance
monitoring,
yeah
and
for
the
telemetry
policy
is
to
determine
which
flow
should
be
monitored.
T
T
And
for
adjustment
there's
two
scenarios:
first,
is
the
route
convergency,
so
when
the
service
flow
switch
to
the
other
forwarding
nodes
like
in
some
protection
or
rock
commodity
scenario,
to
monitor
the
same
flow
information,
a
new
telemetry
instance
is
required
to
add
on
the
new
transit
or
e-grass
node,
depending
on
the
service
telemetry
type
and
for
aging,
so
regarding
iv
or
event,
or
a
performance
monitoring
running
on
the
fourth
pass,
or
there
is
no
flow
that
that
meets
the
policy
during
a
period.
T
T
Oh
okay,
I
think
we
can
so
for
the
next
step.
We
will
update
the
draft
according
to
the
feedbacks,
and
we
are
warmly
welcome
any
comments
or
contributions
to
this
one.
Okay,
that's
all
thank
you.
P
Good
evening,
thank
you
for
your
draft,
the
I
I
have
to
say
in
your
presentation.
It
was
just
a
little
too
high
level
for
me,
that
is
to
say
what
are
the
triggers.
What
do
these
triggers
look
like
what
functioning
what
functions
are
intended
to
be
triggered?
P
I
guess
the
next
step
might
be
for
everybody
to
go,
read
the
draft,
or
at
least
for
me
too,
but
what
I'm
looking
for
I'll
tell
you
what
I'm
looking
for
will
be
a
little
bit
more
meat
in
terms
of
the
technical
steps
that
would
lead
to
interoperability.
Thank
you.
T
Okay,
I
see,
I
will
write
it
down
and
I
will
do
to
to
specif
specify
the
methods
and
the
functions
with
the
colossus.
Okay,.
U
Yeah
hi,
this
is
charles
eckel
and
I
have
to
confess
I
haven't
read
the
draft
yet,
but
I
appreciated
your
presentation,
and
one
thing
I
was
wondering
is:
do
you
envision
some
of
these
flows
just
being
configured
like
where
the
application
or
an
operator
or
someone
who
knows
certain
traffic
is
expected
to
be
on
their
network?
They
they
might
actually
want
to
just
configure
or
let
you
know
about
ones
that
exist
and
could
that
happen
in
parallel
to
learning
the
flows
as
well?.
T
Question
is
that
so
we
can
configure
the
flow
learning
and
the
same
time
the
customers
can
can,
you
know,
can
start
flow.
Learnings
themselves.
Is
that
in
that
question,.
T
Oh
yeah,
that's
a
good
vision.
I
think
I'll
never
thought
about
that
before
because
for
the
fight
back
home
is
more
like
the
operator's
privacy
networks
and
it's
not
open
to
the
real
customers.
Now
it's
just
connecting
the
base
stations
and
and
our
code
networks
yeah,
and
maybe
if
it
is.
T
In
the
near
future,
if
there
is
some
enterprise
customers
connecting
in
our
networks-
and
we
can
do
that-
yeah,
okay,
thank
you.
B
Okay,
rob
make
a
quick
you're
cutting
into
your
time
now.
E
Fine,
okay,
so
I
just
wanted
to
basically
and
say
thank
you
for
watf
and
I
may
haven't
read
the
draft
on
all
I
only
skimmed
it.
E
I
think
my
one
question
concern
I
have
is
this
work
looks
like
it
might
overlap
quite
heavily
with
the
ippm
working
group
and
I
definitely
think
it
would
be
useful
for
you
to
present
there
and
get
their
feedback
on
this,
because
I
don't
I'm
not
sure
we
should
do
much
with
it
in
upc
if
ippm
aren't
supportive,
and
so
I
think,
I'd
like
to
understand
exactly
what
the
scope
is
of
here
and
how
that
relates
to
the
ipp
and
working
group.
That
makes
sense.
T
This
question,
so
we
have
proposed
the
problem
statement
in
both
ippm
and
ops
awg
and
we
think
so.
This
work
is
not
so
technical
to
how
to
do
the
performance
monitoring
but
more
related
to
how
to
manage
or
how
to
deploy
the
large
scale
network
to
support
the
performance
mandatory.
So
so,
last
in
the
112th
ietf
meeting
we
discussed
with
drill,
and
so
I
think
it
is.
O
E
B
Thank
you
germain.
V
Can
you
hear
me
we
can
hello?
Okay,
let
me
present
this
chapter
problem
statement
and
the
use
cases
of
adaptive
traffic
that
collection
next
slide.
Please.
V
V
V
V
V
Problem
statement
iv
network
is
of
traffic-based
calculation,
but
a
long-time
operates
highly
up
telling
the
traffic
visibility
for
lateral
management
system,
which
cannot
reflect
like
this
kind
of
baseline
catalyst.
Speakers.
V
First,
the
observed
average
network
traffic
mask
the
characteristics
of
chico
best
give
diet.
Snt
is
widely
employed
to
collect
collected
electrical
traffic
at
five
minutes
intervals.
Second,
in
spite
of
low
low
link
usage
such
as
setting
to
14
percent
evaluate
bandwidth
utilization,
mailing
claims
have
still
been
received
about
four
per
year.
In
theory.
Applications
with
this
sensitivity
of
this
delay
and
loss.
V
Large
quantity
of
operation
of
relationship
indicate
that
that
based
alumni
layers
a
case
frequently
in
of
race
car
really
workers
such
as
lighting
rain
and
repair
country,
natural
quality
network,
backbone
network
and
in
the
data
center
by
means
of
telemetry
techniques.
We
can
capture
the
complete
aspects
of
mac
based
traffic
harvey.
V
V
V
As
long
as
that's
your
traffic
data
connections,
not
amazingly
a
real-time
portrait
of
interface,
traffic
included
categories
takers
of
telling
the
all
holistic
and
genuine
characteristics
of
intel
interface
traffic
is
the
basic
requirement
for
this
statistical
multiplex
model
of
it
network,
which
is
of
great
significance
of
war
traffic
prediction,
network
planning,
network
capacity,
expansion
and
network
of
optimization
and
so
on,
and
the
longer
long
congested
little
conditions
which
high
face
at
the
time
of
55
percent
above
millions
level.
70
cycle
is
enough,
but
we
are
detecting
a
congestion
state
or
trend.
V
P
Hi
xiaoming
thanks
very
much
for
your
presentation,
two
comments.
The
first
is,
you
may
be
able
to
do
a
fair
amount.
You
may
be
able
to
get
a
fair
amount
of
information
if
you're
interested
in
particular
thresholding
activities
by
using
the
event
map
which
is
already
defined
in
the
itfs.
You
might
want
to
take
a
look
at
that.
V
P
My
apologies,
there
exists
a
mib,
a
management
information
base
called
the
event
mib
and
the
event.
O
P
It
allows
for
threshold
configuration
so
that
when
say
a
certain
rate
based
counter
exceeds
something
or
a
queue,
depth
exceeds
something
you
might
decide
to
do
additional
reporting
through
that
event
map
this
already
exists
in
the
ietf
and
may
help
you.
I
don't
know
if
it
solves
completely
your
problem
statement,
but
it
may
help
you
address
at
least
part
of
your
problem
statement.
P
The
second
point
I
was
making
is
that
there
was
a
an
applied
network
research
award
presentation
that
talked
about
ab
comparisons
for
traffic
treatment
done
by
a
a
woman
who
was
at
least
doing
some
work
with
netflix,
and
I
thought
it
was
a
very
useful
way
to
avoid
buy
a
thing
of
results,
something
you
also
may
wish
to
to
just
have
a
gander
at
a
look
at
excuse
me.
V
But
my
my
easily
ability
is
available.
Please
sometimes
please
send
your
comments
and
the
question
to
me
by
email.
Thank
you.
B
B
W
Yeah,
okay,
so
hello,
everyone
we
have
our
also
on
the
call.
So
this
presentation
is
about
a
young
model
for
data
export
over
ipfix
next
slide,
please,
so
we
have
an
existing
model.
W
So
sorry,
first
of
all,
we
are
looking
at
ipfix
as
the
one
of
the
options
for
bulk
data
export
and
one
of
the
main
options,
so
mainly
in
the
broadband
access
nodes,
where
there
is
a
great
need
to
export
a
lot
of
data
to
the
to
a
centralized
location,
and
there
is
also
one
more
application
where
there
is
a
need
for
exchanging
data
internally
within
the
node.
So
that
is
the
ictp
case,
where
data
for
two
channel
terminations
are
exchanged
between
the
two
ng
point
or
ng.
W
Point
of
boots
are
within
the
same
board,
so
that
is
one
more
application.
Next
slide.
Please
we
have
an
existing
yang
model,
which
was
written
by
benbow,
but
it
it
was
in
the
early
days
of
netconf,
yang
and
and
meanwhile,
netconfian
has
evolved
a
lot
and
even
the
application
of
ipfix
has
also
evolved
from
just
packet
sampling
towards
bulk
data
export.
So
we
have,
we
see
quite
a
lot
of
limitations.
W
There,
where
it
is
closely
related
to
packet
sampling,
closely
tied
to
package
sampling,
and
there
is
a
mandatory
requirement
to
support
a
ctp,
but
satp
is
not
used
widely
and
we
don't
see
a
hope,
I
mean
or
see
a
adoption
in
the
future
or
two
a
wide
adoption
in
the
future
too.
Apart
from
that,
we
also
had
I
mean,
have
some
outdated
references
to
interfaces
and
statements,
which
I
mean
leaves
which
are
not
no
longer
valid
in
the
net
confiyang
world
next
site.
Please.
W
So,
okay,
we
already
had
three
divisions
of
the
previous
draft,
so
the
draft
underwent
a
name
change
because
of
the
change
in
authors.
So
the
previous
draft,
which
we
did
had
envisioned
a
replacement
for
the
existing
6728
model.
W
So
we
had
tried
to
update
all
the
entire
yang
that
was
that
in
6728,
split
them
into
three
different
models
to
for
the
ease
of
use
in
the
deployment,
so
iet
ipfix
had
exporter
and
collector
psamp
had
the
peace
and
specific
functions
and
bulk
data
export
focused
on
the
cache
and
the
bulk
data,
export
related
parameters
so-
and
we
also
made
https
optional
instead
of
mandatory
to
allow
for
deployments
that
use
tcp,
mainly
with
tls,
and
also
updated
the
referencing
to
reflect
the
current
reference
interface
references
and
addresses.
W
So
we
received
a
lot
of
comments
on
the
model,
one
of
the
main
comment
being
that
it
is
too
long,
and
it
is
covering
a
lot
of
things
that
needle
quite
an
extensive
review.
So
based
on
the
comments
we
have
revised
the
model.
So
the
new
draft
name
on
the
new
draft
model
is
an
updated
version
where
we
have
removed
the
psamp
and
the
collecting
process,
and
we
have
tried
to
focus
only
on
the
bulk
data
export
part
of
it
so
which
has
the
ipfix
exporting
process
and.
W
Ipfix
exporting
process
and
the
bulk
data
export
part
of
it,
so
this
is
a
shorter
version
of
it
plus
we
have
stuck
to
only
tcp
as
a
transport
protocol
and
removed
the
file
operations
and
the
file
and
http
and
udp
so
which
udp
is
not
secure
enough.
So
we
have
stuck
to
http
sorry
tcp
here
next
slide.
Please.
W
W
So,
okay,
we
we
understand
that
this
needs
to
be
an
ad
document,
but
after
the
comments
were
addressed
and
we
called
for
an
adoption
in
the
mail
mailing
list,
but
we
have
not
received
any
feedback
on
that
yet
so
we
would
like
to
know
the
comments
and
if
there
are
any
challenges
in
moving
towards
wg
adoption
for
this
draft,
I
think
the
next
slide
also
summarizes
the
same.
Maybe
one
more
point
to
add
is
that
there
is
an
open
liaison
request
from
bbf
and
the
link
to
that
is
shared
here.
W
So
bbf
is
actively
looking
towards
this
draft,
getting
adopted
as
an
rfc
yeah.
B
We
have
a
couple
minutes
for
comments.
I
tried
to
run
a
poll,
but
it
wasn't
asynchronous.
I
was
trying
to
see
who
had
potentially
read
this
new
version
of
the
people
who
were
able
to
respond
five
out
of
the
13
and
out
of
the
18
participants
said
they
had
so
that
doesn't
leave
a
lot
of
people
who
maybe
read
it
rob.
E
Yes,
so
thank
you
for
thank
you
for
persevering,
because
I
know
this
has
been
quite
a
long
and
quite
hard
process
for
you
to
try
and
get
this
work
progressing.
So,
as
I
understand
it
before,
I
was
an
aed.
The
previous
ops
management
lady
agreed
to
ad
sponsor
it,
but
it
hadn't
progressed
at
that
time,
and
there
was
concern
raised
that
the
previous
version.
This
was
trying
to
obsolete
the
previous
standard
track
rfc,
and
I
was
thought
that
was
inappropriate
to
do
that
through
sponsored.
E
I
personally
I
mean
I
don't
have
that
much
experience
with
ipfix
myself
and
I'm
keen
to
try
and
get
these
things
through
the
working
group
as
much
as
possible.
I'm
really
pleased
that
you've
cut
down
the
size
of
the
draft.
I
think
the
previous
150
pages
down
to
50
pages,
which
mostly
just
yang
now
with
a
bit
more.
E
So
I
would
please
ask
the
working
group
if
they
can
help
give
this
attention
and
try
and
get
this
one
through,
because
I
think
it's
important
that
we
actually
help
the
bbf
who
are
trying
to
do
the
right
thing
here
and
I
would
rather
try
and
get
it
through
the
working
group
and
get
more
eyes
on
it
and
get
a
good
document.
Then
they
gave
our
the
ad
sponsor
path,
which
I
don't
think
would
get
quite
a
good
result.
B
Sorry,
real
quick
and
I
think,
given
his
as
chair,
I
think,
given
the
restructuring,
we
could
do
another
call
and
see
if
there
is
renewed
interest
in
picking
up
this
work.
W
Yeah,
just
to
reiterate,
we
are
no
longer
obsoleting
rfc
6728.
So
it's
an
entirely
new
draft
that
we
are
proposing
now.
B
P
Yeah,
you
are
a
little
faint
joe,
I
I
don't
know
what's
going
on,
but
my
suggestion
here
to
the
working
group.
I
like
the
idea
of
the
call
for
adoption.
I
would
delay
it
by
a
month
and
then
maybe
the
chairs
can
harass
us
a
little
bit
on
ops
area
working
group
to
make
sure
that
we're
reading,
because
it
it
does
sound
like
it's
it
anytime.
P
We
see
something
that
that
you
know
there's
clearly
some
value
in
the
concept
clear
if
bbf
is
asking
for
it,
that's
even
more
important-
and
you
know
to
at
least
pay
a
little
attention
to
it,
and
you
know
I.
I
think,
though,
that
the
small
number
of
people
who
read
it
as
indicated
on
the
in
the
poll
is
a
little
bit
concerning
so
just
a
little
harassment
from
the
chairs
and
giving
a
little
extra
time
to
read
it.
S
So
we
had
some
documents
in
the
early
agenda
stage
that
might
could
we
could
be
in
the
candidate
state
for
last
call
at
least
for
review.
I
think
they
were
mud
related,
I
guess,
and
and
so
we
didn't
they
didn't
come
up
today.
We
will
take
care
of
that.
If
we
press
some
review
buttons
here,
we
will
confirm
the
editors
and
then
go
from
there.
B
Thanks
and
with
that
rob
and
warren,
would
you
like
to
take
us
home.
J
E
This
is
this
is,
for
the
first
time
I've
formally
been
standing
in
front
of
you
as
an
ad,
which
is
sort
of
quite
nice
and
the
first
time.
So
I
think
it's
really,
if
you've
got
any
questions
for
us,
it'd
be
lovely
to
hear
them.
Normally,
when
we
ask
this
sort
of
question,
we
get
no
response,
even
in
the
plenary
yesterday,
there
was
no
questions
to
the
isg,
so
probably
the
opportunity
to
have
no
questions
here,
but
we
would
invite
them
we'd,
also
invite
any
feedback
and
comments
back
to
warren.
E
I
that's
also
something
we
actively
like
and
look
for,
and
the
last
point
from
my
side
is
that,
if
there's
folks
that
are
interested
in
stepping
up
and
helping
doing
like
doc,
sheparding
or
they're
interested
in
like
working
with
chair
roles,
that
sort
of
thing
then
do
email,
warren,
and
I
contact
us
and
we'll
see
what
we
can
do
to
help
facilitate
that
sort
of
path
in
the
itf.
Y
And
my
turn
so,
as
you
all
probably
know,
I've
been
doing
this
a.d
thing
for
a
while
now
and
I
am
still
enjoying
it
and
it's
still
fun,
but
at
the
end
of
this
year,
slash
march
of
next
year
I
would
have
been.
I
could
have
finished
my
third
term,
and
I
think
it
would
be
good
if
there
were
other
candidates
for
the
nomcom
to
choose
between
and
for
the
community
to
select
from.
So
I
don't
yet
know
whether
our
toss
might
happen
in
the
ring.
Again.
Y
It's
a
nice
hat,
though
you
must
admit,
but
you
know
I
would
like
to
chat
with
some
people
about
what
it's
like
being
an
ad,
how
much
time
it
takes
the
fun
bits,
the
not
so
fun
bits.
So
if
you
think
that
you
might
be
willing
to
run
for
op
cd,
please
let
me
know-
and
I
think
it's
always
good
for
there
to
be
some
new
blood
and
changeover.
Y
So
you
know
this
is
sort
of
a
plea
for
people
to
step
up
and
be
willing
to
serve.
It
is
fun
I
mean
you
do
have
to
work
with
rob,
but
other
than
that,
it's
fun
crappy's
right
behind
me.
Y
No,
I
mean
it's
a
fun
job.
One
of
the
nice
things
is
you're
expected
to
read
all
of
the
new
drafts
and
so
yep.
We
all
know
how
that
goes,
but
you
know
if
you're
forced
to
read
them.
You
actually
end
up
learning
a
bunch
of
interesting
things.
You're
like
wow.
I
would
never
have
read
that
if
I
wasn't
forced
to
and
it's
actually
it
really
is
one
of
the
better
parts
of
it,
maybe
not
at
the
time,
but
it's
a
reasonable
time
investment.
Y
But
you
know
the
first:
what
year
is
fairly
unpleasant,
while
you're
trying
to
figure
out
what
you
actually
have
to
pay
attention
to?
After
that
it
becomes
a
lot
easier
when
you're
like
this,
I
don't
care
about
this.
I
don't
care
about
that.
I'm
gonna
work
on
you
know,
build
up
a
structure
and
a
system
and
yeah.
Once
again,
you
know
please
consider
doing
this.
Y
Z
Okay,
hi,
I'm
trying.
I
was
trying
to
turn
on
my
video
here,
but
I
think
I
did
the
wrong
thing
all
right
here
we
go
there.
We
go
hi
hi,
so
here's
the
question
and
and
it's
one
that
folks
who
have
been
following
the
upstairs
mailing
list,
probably
have
some
inkling
about.
Z
I
was
the
stuckey
reviewing
the
the
quick
manageability
draft
and
in
that
draft
I
happen
to
find
that
there
were
statements
where
essentially
the
the
authors
and
then
ultimately,
we
found
out
that
it
was
a
strong
working
group
consensus
that
they
wanted
to
at
least
recommend
network
admission
settings
where
we
as
operators,
network
operators,
where
we
would
not
look
at
the
version
number
and
consider
that,
as
as
part
of
admission
control,
and
that
struck
me,
as
maybe
out
of
bounds
for
for
a
draft
to
specify
or
a
future
rfc
to
specify
because
admission
control
is
enforcement
of
policy.
Z
So
I'm
wondering
if
other
operators
agree
and
if
the
ops
area
in
general
agrees
and
it's
going
to
take
that
kind
of
consensus.
I
believe
to
do
something
about
this,
because,
in
my
comments
back
what
I've
heard
you
know
from
the
authors
who
are-
I
consider
both
friends
of
mine
and
other
folks
from
the
working
group
who
are
friends
that
this
is.
This
is
working
group
consensus
and
we
can't
do
anything
about
it,
so
it's
ultimately
going
to
come
to
a
head
somewhere.
Z
I'm
not
getting
much
satisfaction
with
that
particular
point,
but
that's
the
one
I
wanted
to
raise
here
today.
Thank
you.
P
It's
a
clarifying
question,
so
hey
how
you
doing
al
my
my
my
clarifying
question
is
is
the
is:
is
that
in
the
text,
because
the
information
might
be
unreliable
or
is
it
in
the
text?
Why
is
the
recommendation
made
because
it
it
may
be
that
they're
saying
this?
This
is
something
that
operators
should
not
rely
on
for
policy
because
it
may
it
could
be
completely
bogus
or
or
whatever
the
case
may
be.
Z
Well,
I've
heard
lots
of
feedback
on
that.
Some
of
it
is
that
the
version
numbers
will
change
fast,
that
there
will
be
additional
work
on
this
and
and
a
new
version
fairly
soon
and
the
the
underlying
sentiment
that
seems
to
come
through
is
you
know,
treating
operators
like
they
were
back
in
1998
where
there
was.
Z
You
know,
you
know
very
infrequent
changes
of
network
policy
and
they
like
to
relegate
operators
to
you
know
the
fact
that
their
only
role
is
is
ossification
and-
and
I
think
that's
a
you
know-
it's
a
it's
a
very
much
a
convenient
view
for
the
the
particular
working
group
to
take,
but
I
I
would
contend
that
it's
very
much
of
a
view
from
the
past.
Thank
you.
Y
So
so
I
mean
this
is
warren.
I
mean
it
is
somewhat
of
a
difficult
question,
because
I
think
some
of
it
is
also
the
belief
that,
seeing
as
you
can't
really
tell
what's
in
the
stream
you're
potentially
blocking
or
you
know
doing,
admission
control
on
something
which
is
somewhat
arbitrary
right,
like
whether
it's
version
x
or
version
y,
you
still
don't
really
know,
what's
in
the
rest
of
it,
and
so
what
are
you
making
this
decision
on
and
then
there's
also
the
sort
of
what?
Y
If
we
try
and
deploy
this
and
realize
that
we
get
stuck,
because
somebody
has
done
admission
control
in
this,
and
now
we
can't
deploy
a
new
version.
So
I
don't
actually
know
what
the
right
answer
is.
I
mean
I
think
it's
perfectly
fine
to
raise
it
as
a
concern,
and
after
a
few
back
and
forths,
you
know
you
could
only
just
throw
your
hands
up
and
be
like
well.
Y
This
is
what
I
as
an
operator
and
other
operators.
Think
and
let
us
know-
and
you
know
rob
and
I
can
try
and
do
something
like
put
a
discuss
on
it
or
something
right
if
they
end
up
in
the
position
where
you
express
you
do
upstair
review,
it's
incredibly
helpful
if
you
try
and
push
the
position
and
get
too
consensus.
Y
But
if
you
can't,
you
know,
let
us
know,
and
we
can
try
and
do
the
this
is
what
the
operators
are
saying
and
it's
a
valid
concern
and
it
needs
to
be
addressed.
You
know
we'd
prefer
not
to
be
left
kind
of
holding
the
bag,
but
that's
kind
of
what
we're
here
for
and
then
I'd
prefer.
If
rob
does
it
because,
after
all,
say,
wg
is
his
side.
Z
So
one
follow
up
to
that
quickly,
warren!
I
I'm
raising
it
here
that
the
the
question
in
the
topic-
because
I
mean
right
now-
it's
my
opinion
as
an
operator
I'm
trying
to
find
out
as
if,
as
you
said,
are
there
more
operators
that
share
this
opinion
and
we
have
some
time
to
figure
that
out
and
then
and
then
the
other.
The
other
side
of
this
is,
I,
I
think
it's
a
perfectly
reasonable
policy
for
operators
to
decide
on
that.
Z
And
then
I
don't
you
know,
and
then,
if
I
want
to
see
what's
inside,
I
can
do
active
testing.
I
don't
have
to
do.
I
mean
the
other,
the
other
point
of
view
that
that
was
inherent
in
this
in
this
draft
as
it
moved
forward,
but
was
an
implicit
part
of
the
scope
and
we've
discovered
this
in
the
comments
is
that
they
really
felt
all
that
operators
would
do
would
be
the
passive
on
the
wire
monitoring,
and
that's
not
that's
no
longer
true
and
and
it's
it's
not
it's
particularly
untrue.
Z
In
this
case
I
mean
you
know:
we've
been
challenged
to
find
new
methods
to
manage
our
traffic
and
and
one
of
those
methods
is
apparently
you're
going
to
have
to
be
setting
up
our
own
endpoints
and
terminating
the
traffic
ourselves
and
trying
to
figure
out
what's
wrong
with
it
all
this,
and
this
is
all
under
the
assumption
that
the
operator
wants
to
support
quick,
and
that
seems
to
be
anathema
to
this
working
group
as
well.
Y
Yeah,
I
mean,
I
think,
you've
identified
sort
of
one
of
the
key
bits
here,
which
is
there's
definitely
a
tension
between
some
of
the
views
in
you
know.
Certain
working
groups
like
quick
and
some
of
the
views
of
operators
like
there's
a
tension
of
a
belief
that
operators
are
out
to
be
difficult
and
no
information
should
ever
be
exposed
to
them
ever
because
they
will
just
do
bad
things
versus
the
operator
view
of
like.
Well.
If
you
want
to
pass
the
traffic
over
my
network,
I
kind
of
need
to
know
what
it
is.
Y
So
I
can
protect
my
network
from
it,
and
you
know
that
was
somewhat
discussed,
discussed
and
kathleen's
effect
and
crypt
and
a
few
other
ones,
and
it's
definitely
the
tension,
is
definitely
stronger
in
certain
groups
and
areas
than
others.
But
yeah
I
mean
I,
I
think
it's
perfectly
reasonable
for
operators
to
want
to
be
able
to
force
policy
on
whatever
they
like.
Y
I
guess
one
thing
that
I'll
note
is:
even
if
the
rfc
says
you
know
you
can't
do
this.
If
your
box
has
the
knob
your
box
has
the
knob.
This
sounds
very
much
like
the
nuclear
option
of
like
I
don't
really
care
what
urfc
says.
I'm
gonna
do
x,
which
definitely
doesn't
help
repair
any
of
the
tension,
but
yeah
like
I'd
like
to
know
what
other
operators
think
on
this
topic.
If
they've
been
following
the
discussion
etc-
and
I
think
I
stepped
in
front
of
rob.
E
Yes,
I
was
just
going
to
continue
from
a
different
perspective.
I
think
that
one
thing's
important
they're
saying
that
this
has
working
group
consensus
on
this
decision,
but
the
documents
that
we
publish
have
to
have
itf
rough
consensus.
So
I
don't
think
that
that
alone
is
sufficient
to
say
you
can't
discuss.
E
This
has
already
been
decided,
that's
definitely
not
in
scope
and,
as
warren
says,
we
will
help
support
you
in
that
the
the
the
side
of
it
that
the
ops,
the
ir
reviews,
are
really
important
from
us,
because
you
help
offload
a
bit
of
the
work
from
warren,
and
I
that
we've
had
an
opt-I
review.
It
means
that
we
don't
have
to
necessarily
spend
quite
so
much
time
reviewing
those
documents
and
when
we
have
400
pages
of
documents
to
review
along
with
everything
else,
that's
really
helpful,
so
so
abd
all
the
ops.
E
Dr
reviews
are
great
and
really
helpful.
On
this
particular
point,
I
think
the
other
thing
that
might
be
worth
pushing
back
on
is
saying:
can
this
be
expressed
in
a
different
way?
So,
rather
than
saying
you
should
not
do
this
field,
you
should
shouldn't.
Do
this
filtering
say
these
are
the
problems
that
can
arise
when
this?
If
you
do
this
filtering
and
then
so,
it's
not
enforcing
a
policy.
Z
Yeah
and
I
tried
some
alternate
text
and-
and
it
was
rejected-
I
don't
you
know
the
answer
was
I
I
don't
want
to
change
the
consensus
text
there.
You
go.
Y
Sorry,
and
just
one
quick
note-
I
mean
yes,
as
rob
said,
you
know
upstairs
really
helpful
if
you
run
into
issues
like
this.
It's
also
extra
helpful
to
just
drop
rob,
and
I
a
note
so
that
we
know
to
be
paying
attention
earlier
and
more
attention
and
not
just
sort
of
look
at
the
upstairs
thing
and
be
like
well.
There
was
some
discussion
and
it
got
resolved
so
yeah.
H
Well,
just
a
couple
of
things:
oh
hello:
this
is
diego
hi.
Z
H
Well,
no,
yes,
you
were
asking
for
for
the
opinion
of
more
operators
and
for
us
it's
a
it's
a
concern,
and
you
know
it's
a
concern
and
we
have
been
talking
about
this
quite
often,
precisely
probably
I
remember
some
time
ago
there
was
in
the
in
the
transfer
group.
There
was
a
draft
that
was
promoted
by
gauri
fanhurst
from
the
university
of
edinburgh.
H
That
was
very
much
involved
in
this
precisely
about
the
operational
implications
of
the
use
of
transport
transfer,
pervasive
encryption
and
all
the
like,
and
my
impression
is
precisely
they
don't.
They
don't
fly
as
they
should.
But
probably
this
group
is
one
two.
This
is
one
that
is
very
adequate
to
raise
these
concerns,
because
it's
about
we're
talking
about
operations,
we're
not
talking
about
anything
else,
we're
not
questioning
at
all
the
right
of
everyone
to
have
a
privacy
in
the
communications
or
whatever.
H
It
is
about
well,
but
we
want
to
run
properly
the
damn
networks-
and
this
is
something
something
again
that
I
had
tried
to
raise
these
going
in
some
conversations
with
people
from
icehock
is
about
the
implication
this
would
have
in
the
sustainability
in
the
economic
sustainability
of
the
internet
ecosystem,
not
when
talking
about
sustainability,
I'm
not
talking
about
green
things
or
whatever.
That
is
important
as
well,
but
it's
about
that.
There
is
a
group
of
different
entities
that
have
been
making
money
and
earning
earning
a
decent
life
from
from
operating
the
internet.
H
If
we
push
in
in
a
single
direction,
this
would
be
would
make
the
internet
unsustainable
in
the
current
terms
and,
for
example,
the
basic
network
service
would
become,
I
mean
the
only
way
if
the.
If
we
go
in
that
direction,
it
will
become
as
a
state
monopoly,
and
I
think
that
very
few
people
would
like
to
see
this
happening
here
and
in
many
other
places
in
the
at
least
in
the
western
world.