►
From YouTube: IETF111-IPPM-20210728-1900
Description
IPPM meeting session at IETF111
2021/07/28 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
Thanks
all
for
joining,
we
have
a
pretty
pretty
packed
agenda
as
usual,
and
so
we
appreciate
your
involvement
and
participation.
A
Here
is
our
note.
Well,
if
you've
been
in
other
meetings
so
far
this
week,
you've
probably
already
seen
this
I'm
just
pleased
if
you
haven't
seen
it
before
and
take
a
moment
to
familiarize
yourself
with
contents
here.
This
is
our
essentially
our
code
of
content
for
how
we
work
in
the
iitf.
A
A
A
A
B
A
B
C
C
A
Thank
you
very
much
appreciate
it
all
right.
Let's
move
on
as
one
quick
thing
before
we
get
into
the
agenda,
I
sent
out
an
email
already
about
this
to
the
group,
but
since
it's
very
applicable
to
people
in
ippm,
I
just
wanted
to
highlight
that
there
is
a
ib
workshop.
That's
going
to
be
happening
in
september
on
the
measurement
of
network
quality,
specifically
with
a
focus
on
what
that
means
for
end
users.
A
A
All
right
so
looking
at
our
agenda
coming
up,
we
have
for
some
updates
on
working
group
documents
and
then
documents
that
we
have
spent
a
lot
of
time
talking
about
in
the
working
group.
A
Already
a
lot
of
that's
going
to
be
talking
about
the
progress
on
our
iom
drafts
to
begin
with,
some
of
the
other
adopted
work
and
then
some
of
the
work
that
is
developing
in
the
group
and
then
once
we
get
through
that
part
of
the
agenda,
which
will
be
a
little
bit
over
the
first
half
of
the
session,
we
have
a
number
of
proposals
and
lightning
talks
that
we
will
get
to.
A
All
right,
hello,
frank
and
frank:
are
you
fine
with
me
sharing
or
do
you
want
to
share
the
documents.
D
No,
I'm
very
fine
with
you
sharing,
okay,
so
I'm
hoping
for
that.
Apparently,
I'm
not
ready
to
share.
So
this
is
a
joint
presentation
between
towel
and
I
so
I'm
going
to
go
cover
the
first
and
the
last
and
talos
going
to
go
and
cover
the
flax
draft
and
the
direct
export
draft.
So
if
you
flip
to
the
next
slide,
this
one
is
about
the
nc2
oem
iom
deployment
and
next
one.
D
D
The
dash
14
and
the
dash
14
now
also
references
this
deployment
draft,
because
a
lot
of
the
iesg
commons
were
around
deployment
aspects,
and
so
people
found
that
there
is
a
benefit
to
also
have
deployment
considerations
at
least
referred
to
in
the
data
draft.
So
there
is
a
linkage
between
the
two
documents
now,
which
is
why
I
think
the
document
pretty
much
raises
an
importance
from
a
content
perspective.
There
hasn't
been
too
many
updates
between
the
the
last
revision
and
the
reversion
3..
D
It
was
mostly
around
comments
that
we
got
again
from
various
reviews,
including
the
iesg
reviews,
so
that
we
updated
the
the
security
section
and
telco
care
of
that
to
go
and
discuss
mitigating
eavesdropping
attacks
around
time
synchronization,
because
multiple
people
could
go
and
use
different
clocks
on
on
different
devices.
D
That's
been
reflected
in
the
latest
version
of
the
all
three,
and
originally
we
started
that
that
document
in
op
say
wg,
which
is
why
the
title
still
carries
the
the
upside
wgg
title
name
and
or
word
in
the
in
the
in
the
document
title.
D
But
given
that
all
the
work
has
been
happening
around
iuem
really
in
ippm,
and
we
had
the
same
discussion
with
the
v6
aspects
in
a
similar
vein
right.
So
we
moved
the
work
over
into
ippm.
D
We
do
believe
that
the
right
home
for
that
document
would
be
ippm
instead
of
upset
wg,
so
that
we
have
all
the
experts
here.
We
can
do
all
the
reviews
here
and
we
believe
that,
given
also
the
the
linkage
to
the
draft
ippm
iom
data
that
we
do
want
to
go
and
progress,
the
work
here
and
hope
for
working
group.
Adoption
of
that
particular
document.
A
Let's
kind
of
since
these
have
some
questions
here:
let's
take
these
kind
of
one
at
a
time,
so
we
make
sure
we
can
come
back
to
them
so
yeah.
This
sounds
fine
to
me.
I
think,
given
the
isg
review,
it
sounds
like
you
know.
This
needs
to
be
progressed
somewhere.
A
If
that's
not
going
to
happen
in
ops,
then
I
think
this
does
make
sense.
I
guess
I'd
like
to
hear
from
the
working
group
if
anyone
has
objections
to
this
happening
in
ippm
and
I'd
be
also
curious
to
hear
rad's
thoughts
on
this,
given
the
process
of
the
isg
review
and
how
we
want
to
schedule
this.
F
A
Yeah
yeah,
I
mean
that
as
as
well
as
is
this
going
to
end
up
being
like
a
dependency
or
do
we
think,
like
you
know,
the
main
iom
data
document
can
go
through
just
knowing
that
this
will
be
coming
after.
F
I
don't
have
a
great
sense
of
what
ben's
reaction
to
that
would
be.
I
I
I
would
be
in
favor
of
moving
iom
data
forward,
regardless,
even
if
has
to
sit
in
the
rfc
ed
cube
forever.
Okay-
and
to
be
honest,
I
haven't
thought
deeply
my
personal
position
on
this
and
whether
it
needs
to
be
normative
or
informative.
F
If
ben
is
going
to
insist
on
normative,
then
I
think
we
still
drive
forward,
but
that
we,
but
we
get
the
document
done
from
our
perspective,
sounds
good.
A
Ian,
did
you
want
to
say
anything
here?
Are
we
good
all
right,
so
I
think,
given
no
one
else
commenting,
we
will
kick
off
a
adoption,
call
for
this
and
move
forward
with
it.
G
Hi,
okay,
so
we
want
to
talk
a
bit
about
the
flag
draft
and
the
direct
exporting
draft.
So
we'll
start
with
a
few
words
that
are
common
to
both
of
them.
Next
slide,
please.
G
We
discussed
this
a
lot
over
our
meetings
and
we've
added
quite
a
bit
of
text
to
these
two
drafts,
so
we
can
see
the
main
changes
here.
So
we've
already
had
one
iteration
of
comments
about
the
dex
draft
and
we
recently,
in
the
last
few
days,
also
updated
the
flags
draft
to
reflect
very
similar
changes.
G
G
Okay,
so
that
was
the
common
part
that
was
updated
for
both
drafts
and
now
we're
going
to
focus
a
bit
about
the
flags
draft
and
then
we'll
talk
a
bit
about
the
direct
exporting
draft,
so
basically
the
flags
draft,
the
main
changes
we've
had
are
related
to
security.
So
actually
we
haven't
had
many
other
changes
in
the
draft
other
than
the
security
related
issues.
G
We
believe
the
draft
is
pretty
stable,
so
once
we
see
that
the
security
related
changes
are
stable
as
well,
we
once
we
see
there
are
no
further
comments
related
to
this
specific
topic.
G
Okay,
direct
exporting
so
related
to
this
draft.
We
had
two
main
open
issues
that
we've
been
discussing
for
a
while
now
and
we
actually
discussed
them
not
only
in
the
last
idf
itf
meeting,
but
also
in
previous
itf
meetings
before
that,
and
we
haven't
managed
to
resolve
these.
But
we
asked
the
working
group
chairs
for
some
advice
here
and
for
each
of
these
two
open
issues.
We
can
see
the
suggested
resolution
from
the
working
group
chairs.
So
basically
just
a
reminder.
G
The
first
open
issue
was
regarding
the
hop
count
field,
whether
we're
going
to
have
a
an
explicit
hop
count
field
in
the
dex
option,
header
and
right
now.
The
suggested
solution
is
to
avoid
this
field,
basically
to
be
able
to
rely
on
the
existing
up
limit
node
id
data
field,
which
was
already
defined
in
the
data
draft.
G
G
So
there
were
a
few
possible
alternatives
of
how
to
proceed
here,
and
the
suggested
solution
in
this
context
is
to
use
the
flags
in
the
direct
exporting
option
header
in
order
to
indicate
which
optional
fields
exist
in
this
direct
exporting
option.
So
what
we're
going
to
do,
assuming
there
are
no
further
comments
about
that,
will
be.
G
A
F
Yes,
tal
thanks
for
the
changes
I
I
do
think
that's
addressed
the
most
serious
problems
that
I
brought
up
a
couple
meetings
ago.
I
would
not
characterize
these
necessarily
attacks
like
I
think
one
of
the
points
of
my
presentation
was
that
these
things
just
scored
to
happen
by
bad
luck,
although
of
course
it
could
also
be
exploited
as
attacks,
but
that's
a
nit.
I
I
think
I
think
the
drafts
moving
in
the
right
direction.
F
I've
you
know,
like
I,
I'm
still
a
little
tempted
to
retreat
to
my
original
sort
of
general
concern
about
amplification,
but,
like
I
think
I
think
the
new
problems
have
arisen
have
been
addressed
pretty
comprehensively
and
I
would
have
to
think
a
little
bit
more,
but
they've
actually
also
substantially
addressed
the
amplification
issue.
But
at
this
point
I'm
happy
with
how
things
are
progressing.
Thank
you
for
your
work
on
this.
A
Awesome
all
right,
any
other
comments,
thoughts
from
people-
I
guess
yeah,
speak
up
if
you
have
any
objection
to
the
proposed
resolution
for
these
two
open
issues.
Otherwise
I
guess
we'll
look
forward
to
a
updated
document
put
that
in
there
and
then
we
can
kick
this
going
forward.
A
Okay-
that's
surprisingly
easy.
I
wonder
how
many
people
here
are
asleep
all
right.
Should
we
move
on
to
the
integrity
document.
D
Okay,
yeah
thanks
and
then
and
tommy.
You
see
that
people
are
relatively
quiet
on
this,
because
this
has
been
expensively
discussed
in
the
design
team
and
I
believe
we
are
happy
with
the
resolution
that
you
provide,
given
that
we
have
a
resolution
for
especially
the
the
questions
around
the
dexcraft,
so
the
integrity
of
iom
data
fields
has
been
also
discussed
at
length,
and
we
know
that
in
the
past
session
we
had
a
bit
of
a
menu
of
options
that
we
presented
and
the
recommendation
was
to
go
for.
D
If
you
go
to
the
next
slide,
to
go
what
was
originally
method
three
and
that
method.
Three
was
a
method
that
users
used
symmetric
keys,
but
consolidated
the
the
signatures
with
the
hash
or
always
into
the
very
into
the
very
same
field
by
iteratively,
reusing
that
field
and
kind
of
piggybacking.
D
On
top,
one
recommendation
was
to
go
and
use
this
method,
but
extend
this
method
to
not
only
use
symmetric
keys
but
asymmetric
keys
and
well,
basically
move
everything
else
to
back
up
so
that
in
the
second
stage
we
can
move
it
from
back
up
to
the
trash.
Can
that's,
apparently,
what
we've
done
so
the
new
draft
is
focused
on
what
used
to
be
method
three
with
using
both
symmetric,
keys
or
asymmetric
keys.
D
Everything
else
has
been
moved
to
the
appendix
for
now
and
given
that
we
kind
of
agreed-
and
we
hopefully
agree
on
that
and
decision
that
we're
going
forward
with
this
space,
optimized
key-based
signing
method,
we
are
also
in
this
graph
proposing
new
iom
options
that
are
now
integrity
protected
because
they
are
carrying
what
we
call
a
subheader
for
integrity,
protection
and
we're
going
to
go
and
look
at
that
in
a
second,
and
we
also
given
that
we
now
have
this
well
solution
in
place.
We
also
started
to
go
and
update
again.
D
That
was
a
recommendation
in
the
last
session
and
I
think
greg
was
bringing
that
up
to
go
and
expand
a
little
bit
on
the
overhaul
overhead
considerations
for
this
particular
option
and
bringing
in
options
how
to
go
and
drive
down
the
overhead.
D
If
people
have
a
concern
with
like
too
much
processing
on
a
per
packet
basis
that
this
integrity
of
protection
would
would
bring,
and
one
eight
years
obviously
to
go
and
only
apply
this
to
a
subset
of
the
packets-
and
I
think
this
is
also
represented
in
the
draft
now.
So
if
you
go
to
the
next
slide,
we'll
get
a
glimpse
at
the
new
option
types.
D
So
we
have
the
original
iom
option
to
the
right
hand,
side
and
we
have
an
integrity
protection
option
to
the
left
hand,
side
now
so
kind
of
side
by
side.
So
we're
going
to
go
and
create
new
option
types
for
that,
and
if
you
look
at
the
the
suggested
values
for
the
option
types
you'll
notice
that
well,
they
all
carry
the
the
first
bit
as
one.
So
it
would
be
very
easy
if
we
allocate
the
option
type
values.
D
Smartly,
like
we
are
suggesting
here
to
just
look
at
a
single
bit
and
see
whether
the
option
type
header
for
integrity
protection
would
be
there
or
not.
That
sub
header
flip
forward.
One
step
next
slide
and
we'll
see
that
subheader,
so
that
is,
gonna,
go
and
be
appended
to
the
existing
option.
Type
header,
be
it
like
e2e
or
be
it
pot
or
be
one
of
the
trace
option
types.
D
So,
given
that
we'll
have
multiple
ways
to
go
and
use
keys,
so
we'll
always
have
this
pair
of
a
method
to
go
and
hash
and
a
method
to
sign,
and
it
might
be
a
symmetric
method
to
go
and
sign.
It
might
be
an
asymmetric
method
to
sign
and
the
approach
that
we
took
in
order
to
allow
for
future
flexibility
and
not
be
kind
of
prescriptive
here
or
be
too
prescriptive.
D
Is
that
we're
saying
we're
going
to
go
and
have
a
couple
of
sweets
of
a
combination
of
hash
method
and
signing
at
the
method
and
there's
two
proposed
here
to
start
off
with
one
for
asymmetric
one
for
symmetric?
There
could
be
more
in
the
future.
Let's
see
what
what
people
feel
is
the
right
approach.
The
two
are
the
ones
that
we
also
had
as
suggestions
from
from
the
the
o2
version
of
the
draft
and
then
well.
D
All
of
these
methods
need
a
nonce
and
they
need
a
signature
field
and
well,
given
that
the
nons,
depending
on
the
the
method
that
you're
using
can
and
the
signature,
has
various
variable
length,
there
will
be
a
length
field
in
this
whole
thing
and
the
two
go
hand
in
hand
from
a
length
perspective.
So
we
have
a
length
field,
a
nonce
field
and
a
signature
field,
and
if
you
flip
to
the
next
slide,
then
you'll
see
how
this
subheader
tommy.
Could
you
go
to
the
next
slide?
D
Thank
you,
then
you'll
see
how
this
this
subheader
will
extend
the
existing
iom,
option
types,
the
the
trace
option,
type
to
the
left
hand,
side
and,
to
the
right
hand,
side
the
the
pot
option
or
the
e2e
option,
and
so
we're
just
kind
of
appending
that
particular
option
type
header
and
making
it
a
sub
option
header
and
then
making
it
a
new
option
that
way
next
slide.
D
D
D
There
is
a
reference
in
the
ippm
iom
data
14
now
to
this
particular
draft,
because
well
we
don't
really
have
the
integrity
protection
covered
in
in
the
data
draft
in
the
original
version,
but
we'll
have
an
extension
with
additional
options.
Much
like
we're
extending
for
decks
or
other
things.
E
D
The
original
draft
that
covers
integrity,
protection
for
these
options
that
are
defined
there
and
we
are
hoping
that
this
meets
the
needs
and
that
we
can
go
and
also
start
a
working
group.
Adoption
call
for
that
document.
D
And
I
well
appreciate
commons
questions
whether
this
meets
what
people
had
in
mind
because
well
we're
we're
navigating
a
little
bit
the
territory
of
what
people
believe
is
required
here.
Given
that
we
started
with
a
menu
and
we
narrowed
down
the
menu
to
a
solution
now
and
we're
hoping
that
this
solution
meets
what
people
had
in.
A
Mind
all
right,
yeah,
I'm
just
for
myself.
Thank
you
for
doing
this.
I
think
this
does
represent
the
direction
that
I
was
imagining.
We
do
have
some
time
here
for
comments
and
questions.
I
guess
have
people.
A
Comment
if
you've
read
the
most
recent
version,
if
you
think
this
is
the
right
direction,
one
question
I
have
is
you
know,
I
think
at
some
point
we'll
want
to
do
a
sector
review
of
this
to
get
the
input
sounds
like
something
we
probably
want
to
do
early
on
before
we
go
too
far
down.
One
particular
road-
and
I
guess
the
other
question
I'd
have
to
the
authors-
is
how
much
implementation
has
been
done
this
so
far.
Is
it
still
pretty
early
days
on
that.
D
So
this
is
early
days,
given
that
this
was
more
something
that
is
piggybacking
on
top
of
what
we
have
it's
from
a
hardware
perspective.
This
is
really
hard
to
do
from
a
software
perspective,
maybe
but
yeah.
There
is
no
implementation
on
that,
so
the
the
the
open
source
reference
code
in
vpp
doesn't
do
it,
and-
and
I'm
not
sure
whether
we
have
just
in
here
that
that
drives
the
the
implementation
of
iom
in
linux,
maybe
justin.
H
Yeah,
actually
yeah,
so
iom
is
in
the
linux
kernel.
Officially,
it's
a
news
from
two
or
three
or
three
days
and
it's
gonna
be
available
in
the
next
release,
so
it's
5.14,
which
will
be
released,
I
would
say
in
four
five
or
six
weeks,
so
it's
officially
in
inside.
H
Yeah
well,
actually,
I
was
going
step
by
step
because
it's
a
huge
part
to
make
it
inside
the
corner,
so
I
will
have
a
look
at
it:
yeah,
okay,.
D
And
adopt
it
or
do
we
want
to
go
and
leave
it
hanging,
because
I
think
the
the
the
question
that
we
had
and
we
we
you
you've,
seen
the
isg
commons
like
yeah.
It's
referring
to
an
individual
draft.
That's
not
even
a
working
group
draft,
but
we
need
a
working
group
solution
for
this
whole
space
and
I
think
so.
We
need
at
least
a
placeholder
to
go
and
progress.
The
work.
A
Well,
as
implementation
so
yeah,
we
need
it
adopted.
We
need
to
say
yeah
we're
working
on
this,
but
it's
going
to
be
really
important
to
have
the
experience
implementing.
D
A
I
Okay,
great!
Thank
you!
Okay.
So
it's
a
long
time
not
seen.
We
came
back
to
this
document
and
used
the
experience
that
we
got
and
in
stamp
extensions.
Next
slide.
Please.
I
So
from
8972
stamp
extensions
where
we
introduced
their
stem
session
identifier,
and
that
was
an
update
to
8762.
I
So
now
that
was
incorporated
into
other
yang
data
model
and
that
now
becomes
their
key
for
their
stamp
session
list.
Because
the
session
identifier
is
unique
for
the
stem
session
sender
and
in
combination
with
their
source
iep
address.
I
We
remove
the
packet
padding
size
because
their
8762
base
stem
specification
defines
symmetric
packets
of
fixed
size
and
their
definition,
or
ability
to
generate
packets
of
variable
size
provided
by
extra
petting
tov
that
is
defined
in
8972
and
extensions
to
stand.
I
So
we
continue
addressing
their
early
young
doctor
comments,
review
that
we
have
from
a
while
ago
and
edit
references
to
87,
62
and
972,
where
appropriate,
and
did
some
editorial
and
knit
cleaning
next
slide.
Please.
I
So
I
mentioned
that
we
introduced
some
session
identifier
that
was
defined
in
8972,
so
this
is
in
just
a
snapshot
of
the
yang
data
model.
That
is
a
part
now
of
their
document,
and
that
explains
what
the
session
id
is
as
defined
in
rfc
8972
and
how
it's
used
by
providing
their
unique
key
for
a
stem
session
sender,
because
it's
assigned
locally
so
it's
locally,
unique
and
then
in
combination
with
the
source
ap
address.
It
provides
their
unique
key
for
the
session
reflector.
J
I
Yes,
you're
right,
my
my
mistake,
I'll
fix
it.
Thank
you.
J
I
Okay
next
slide,
please
packet,
heading
size
and
stamp
extensions
in
general,
because
base
specification
defines
the
fixed
size
packets
so
that
to
create
a
packets
of
other
length.
I
Extra
padding
tlv
should
be
used,
and
so
hence
the
question,
because
this
is
important
part
of
testing
and
seems
that
it's
logical
to
be
included
in
a
stamp
yank
data
model.
I
So
but
at
the
same
time.
So
that
opens
the
question
for
how
other
extensions
that
define
in
89
72
to
be
reflected
in
a
yang
data
model
should
be
they
part
of
the
same
module
or.
I
Reflected
in
a
separate
models
that
can
be
argumented
to
the
stem
based
yang
data
model,
so
this
is
an
open
question
and
I
would
like
to
get
your
comments
and
thoughts.
J
Hi
greg
so
because
the
extra
padding
is
a
stamp
tlv,
so
it's
integral
part
of
rfc
8972,
so
young
data
model,
for
it
could
say
a
good
give
a
parameter
to
say
the
packet
size,
and
this
will
allow
us
to
test
the
variable.
Various
packet
sizes,
which
is
part
of
stem.
I
Yes,
that
that
was
so
authors
we
talked
about
it
is
yes,
it's
explicitly
does
not
require.
It
only
will
be
a
reference
in
the
data
model,
saying
that
this
uses
extra
pairing
tov,
but
with
that,
what
about
other
extensions
so
should
we
include
them
in
this
base?
J
I
Yes,
that
that
we
agree,
that's
our
thinking
too,
that
for
padding
the
base
the
default
is
null
padding
and
then
there
is
an
option
to
define
additional
padding
through
the
extra
petting
tlv,
but.
I
Class
of
service
testing
that
supports
or
location
information,
so
the
question
we
have
to
the
working
group
is
how
these
tovs
to
be
reflected
in
the
base
stamp
yank
data
model.
I
Would
you
suggest
to
have
it
as
an
integral
part
of
it
and
use
it
as
a
feature?
And
then,
if
it's
enabled,
then
there
will
be
an
element
of
data
model
that
defines
and
allows
to
read
it
or
just
leave
it
outside
and
only
include
support
for
extra
petting
tlv.
I
You
suggest
your
opinion
is
that,
because
we
already
have
rfc
8972
and
since
we
already
reflect
some
elements
of
some
elements
defined
in
8972,
then
we
should
go
and
include
in
this
data
model
all
the
elements
as
optional
extensions.
Just
the
way.
I
Yes,
so
make
them
optional
in
the
data
model,
but
include
them
all.
Yes,
that
makes
sense.
L
L
When
it
originally
went
out,
the
door
was
backwards,
compatible
with
t-wamp
light
and
that
allowed
for
padding
outside
of
the
tlv.
Does
the
yang
model?
I'm
sorry,
I
don't
know
this.
Does
the
yang
model
support?
Did
it
support
a
current
padding
size
beyond
this
tlv
that's
defined
in
8972,
and
are
we
removing
that.
I
Well
again,
that
that
was
how
we
arrived
to
this
question
that,
strictly
speaking,
87
762
does
not
define
how
you
do
padding.
I
But
in
89
72
in
extensions,
we
introduced
the
tov
that
allows
to
not
only
to
do
extra
padding
tod
but
combine
it
with
the
other
tovs
for.
I
T1
polite
because
it
would
not
recognize
their
peri
tovs,
it
will
treat
them
or
we
expect
it
will
treat
them
as
padding.
I
And
in
in
that
aspect,
8972
doesn't
change
what
is
put
in
the
base
in
87
62.
I
Great
okay,
so
thank
you.
Please.
Let's
discuss
this
on
a
mailing
list
if
you
have
other
opinions
in
regard
to
inclusion
of
extensions,
but
our
thinking
was
that,
as
rakesh
and
fooder
suggested
to
make
this
optional
features
and
then
support
them
as
documented
defined
in
89.72,
so
the
next
steps
are
continue
working.
Our
comments
are
welcome
and
we'll
try
to
make
it
ready
for
working
room
plus
call
by
the
next
meeting.
Thank
you.
A
J
It's
stamp.
B
A
B
Okay-
and
you
see
them
yes,
simple
stamp
for
srpm.
B
M
J
All
right,
yeah
hi
everyone,
my
name
is
kandi
and
I'm
presenting
the
stamp
extension
for
sr
on
behalf
of
the
authors
listed
here
and
next,
like.
E
J
Yeah
so
we'll
review
the
updates
in
division,
zero,
zero
and
zero
one
in
the
newly
adopted
document
with
this
highlight
the
stamp
based
work,
that's
happening
in
other
working
groups
as
well,
and
the
next
steps
next
like
this.
J
So,
in
revision,
zero,
zero,
it's
a
newly
adopted
by
the
ippm
working
group.
We
address
various
review
comments
that
we
received
during
the
working
group
adoption.
So
we
updated
the
security
section
and
we
introduced
a
new
error
flag
d
flag
wrong
destination.
There
is
no
address,
tlv
format
has
changed
as
well.
We
clarified
tlb
applicability
to
p2p
versus
p2mp.
J
There
were
many
other
clarifications
as
well
added
in
the
draft.
So
please
have
a
look
and
let
us
know
your
review
feedback
in
revision.
Zero
one.
There
were
few
loose
items
from
remain
in
from
zero
zero
one
was
the
security
section.
Man
in
the
middle
related
in
limited,
limited
domains,
related
comments.
There
was
also
a
comment
about
destination
at
this
till
we
in
some
scenario,
so
it
should
be.
J
J
So
we
we
also
have
stamp
based
work
in
other
working
groups.
So
it's
great
that
we
have
stamp
work
done
in
ippm
and
it's
quite
useful
work,
so
we
see
start
to
see
the
extensions
we
have
in
spring
using
stem
for
pm
there.
J
So
there
was
a
working
group
adoption.
The
draft
is
adopted
in
spring.
Now
we
addressed
various
review
comments
there
as
well.
There
was
discussion
on
whether
it's
informational
or
standard
track
document.
J
We
welcome
your
further
review
comments
and
suggestions
on
that
work
as
well,
and
many
thanks
for
all
the
feedback
we
have
received.
We
also
have
a
new
draft
in
mpls,
slash,
maybe
pals
working
group
and
it's
the
encapsulation
of
stamp
for
pseudo-wires
in
mpls
networks.
J
J
So
at
this
point
we
are
seeking
more
comments,
feedback
suggestions,
more
than
welcome
appreciate
it
thanks.
D
B
B
A
Yes,
we
can
do,
do
you
have
the
slides
for
this.
N
A
It's
just
the
title
all
right.
Let
me
let
me
share
that
then.
N
Yeah,
hello,
everyone,
it's
xiaomi
speaking,
this
presentation
is
on
echo
requester
5
for
enabled
in-situ
om
capabilities.
N
N
During
the
adoption
poll
there
are
two
or
more
discussion
points
raised.
The
first
one
is
the
recommended,
feasible
method
of.
I
am
deployment
to
use
pcecc
sdn,
centralized
controller
in
the
next
revision.
We'll
clarify
that,
in
this
draft,
centralized
controller
means
a
controller
that
owns
the
enabled
ion
capabilities
of
every
iom
device
within
the
network.
N
N
N
N
A
All
right,
thank
you
very
much.
Does
anyone
have
any
questions
about
what
was
presented
here
or
should
we
move.
A
N
But
if
the
controller
has
no
information
about
the
imp
capabilities
of
all
iom
devices,
then
we
need
this
tool
to
paying
for
the
iom
capabilities
of
every
im
device
on
the
path.
D
Yeah,
thank
you,
but,
but
let
me
be
more
specific
right,
so
you
you're,
defining
tlvs
and
sub
tlvs
and
particular
structures
on
how
you
want
to
go
and
retrieve
the
data.
It
would
be
nice
if
we
could
go
and
have
a
proper
data
model.
For
that.
I
think
that's
what
I'm
trying
to
say
and
if
we
can
go
and
sync
that
data
model
with
the
data
model
that
we
use
for
configuration
and
configuration
retrieval
with
what
we
have
in
the
young
documents.
F
Just
to
be
clear,
so
the
purpose
of
this
draft
is
to
have
the
I
want
to
understand,
so
so
the
purpose
this
is
to
have
the
core
to
have
the
core
like
formats
for
reporting
capabilities
in
this
document,
and
then
the
way
that's
encased
in
these
various
signaling
protocols
is
going
to
be
in
the
other
drafts
in
the
other
working
groups.
Is
that
correct.
M
On
I'd
like
to
know
that
the
security
issue,
did
you
just
address
them
like
I,
I
propose
oh.
N
M
N
N
Yes,
we
have
already
adjusted
and
also
I
want
to
note
that,
with
the
new
submitted
drafts
on
specific
extensions,
we
also
will
consider
security
carefully.
Thank
you.
M
O
O
P
O
Okay,
the
split
floor
measurement
short
summary
about
this
new
kind
of
techniques
is
a
technique
that
employs
few
marking
beads
inside.
O
P
O
O
There
is
some
implementation
core
network
props
that
are
already
deployed
in
some
techno
in
united
states
and
so
on.
The
orange
jacket
implementation
there
are
in
the
fmi
production,
cdn
and
coordinator
probes
and
the
u1
the
aka
university
implementation.
They
presented
yesterday
a
paper
in
the
a
nw
about
packet
loss
measurement.
They
compare
the
four
kind
of
bits
for
this
kind
of
measurement,
the
lqr
and
tbs,
with
the
pro
and
cones
for
each
one,
and
also
always
working
on
the
top
next
slide.
Please.
O
O
O
O
The
server
knows
the
maximum
time
that
is
possible
in
this
measurement,
the
t-max.
So
if
two
every
consecutive
delay
samples
are
the
distance
less
than
the
t
max,
the
measurement
is
alright.
If
is
equal
or
greater
than
the
t
max,
the
measurement
is
discarded,
because
the
the
two
the
examples
are
not
consecutive,
but.
O
Okay,
the
improvement
that
we
put
in
this
new
version.
The
draft.
O
Reason
because
the
rtt
value
could
approximate
the
client
server
distance,
so
it's
considered
a
private
simulation
in
certain
world.
There
is
a
simple
way
to
either
tt
and
to
allow
only
observer,
server,
entity
measurement
or
inter
domain
rtd.
Measurement
idea
is
to
slightly
modify
the
light
bit
implementation,
adding
a
fixed
amount
of
milliseconds
to
the
entity
measurement.
O
So,
as
you
can
see
in
the
feature
the
client
will
receive
the
delay
sample
wait
for
an
additional
delay,
so
the
rpt
is
incremented
by
this
additional
delay.
So
so
only
the
right,
rtt
or
the
interdominarity
that
you
can
see
in
the
next
slide
is
correct.
Next
slide,
please.
O
O
So
if
I
measure
the
timestamp,
when
you
pack
a
market
packet,
the
pass-through
and
server
and
each
leather
server
reach,
the
server
come
back
and
so
on
is
possible
to
have
the
entity
between
the
two
observance
and
the
additional
entity
is
not
affect
the
measurement,
so
the
measurement
is
correct.
Next
transparency,
the
slide
please,
okay
in
this
table.
Let's
summarize
the
the
pros
and
cons
of
the
three
techniques
about
the
rtt
measurement
spin
bit.
O
That
is
very
high,
the
number
of
measurement,
because
every
rtt
there
is
a
measurement,
but
the
impairment.
Resiliency
is
quite
low
because
in
case
of
losses,
or
in
case
of
auto
sequence,
the
measurements
aren't
correct
the
standard
that
they
beat
the
normally
that
we
presented
in
the
last
version.
The
draft
is
very
precise,
but
the
number
one
measurement
is
only
medium
because
when
there
is
a
application
delay
greater
than
one
millisecond
on
the
server
on
the
client,
the
measurement
are
discarded.
O
O
O
The
last
the
best
option
are
the
use
of
the
delay.
It
is
possible
to
use
the
delay
beat
or
the
even
a
bit,
because
it
is
only
a
different
implementation,
but
all
the
characteristics
is
the
same
about
the
possibility
to
eat
wide
rtt.
So
it's
possible
to
use
a
little
bit
with
in
the
two
version,
normal.
O
Next
transparency,
okay,
spg
flow
measurements
are
gaining
interest
for
encrypted
transport
protocols
already
discussed
in
many
groups:
quick
working
group,
yes
wg
working
group
and
so
on.
There
are
some
implementation
from
many
companies
that
come
tested
in
the
iit
flag
account,
and
there
is
a
thread.
E
O
A
F
F
Yeah
hi
mauricio.
Thank
you
this.
I
guess
my
I'm
not
looked
been
following
this
closely
since,
since
we
decided
to
spin
a
bit
all
those
years
ago,
there's
like
a
lot
of
options
here.
I
don't
know.
If
there's
I
mean
I've
not
to
be
honest,
I've
not
read
the
draft
to
know
if
it's
then
a
little
more
clearly
there,
but
it
just
it.
F
I
I
think
it's
I
think,
like
many
drafts,
including
some
that
I've
written
like
there's
a
lot
of
sort
of
crept
into
all
these
different
use
cases,
and
I
think
some
like
ability
to
maybe
have
a
recommended
choice
or
something
would
be
helpful
here.
O
But
for
the,
in
our
opinion,
the
light
beat
in
the
version
can
preserve
the
privacy
of
the
client,
because
the
distance
masked,
because
we
had
an
additional
delay-
and
in
this
case
it
can
be
in
our
obvious
possible
that
respect
has
been
beat
more.
Companies
decided
to
implement
it,
but
is
only
our
idea.
Is
I'm
very
curious
if
other
people,
what
I
think
about
this
idea.
O
If
the
trends
from
privacy
problems,
the
delay
beating
the
810.
A
Yeah,
so
I
think
we're
out
of
time
for
this
right
now,
but
this
does
sound
like
something
that
would
be
good
to
spin
up
a
thread
on
and
include
quick
on
as
well.
So
maybe
the
authors
could
try
to
kick
something
off
for
that.
A
A
I
I
So
this
is
update
on
the
hybrid
two-step
telemetry
collection
method
draft,
and
can
we
go
next
slide?
Please
what
we
updated?
We
added
max
length
field
and
defined
it's
a
result
from
our
discussion
with
prank
on
full
identification.
Examples
provided
more
specifics
in
some
environments
like
in
sfc
nsh
and
when
iom,
and
resulting
from
a
discussion
in
raw,
we
added
mode
for
hybrid,
two
step
that
we
can
refer
as
upstreaming,
and
that
was
result.
I
Discussion
with
pascal
and
pascal
agreed
to
join
in
the
work
as
a
offer.
So
welcome
pascal
and
next
slide.
Please,
let's
go
in
specifics
of
updates.
So
again,
as
mentioned
max
length
field
was
added
in
discussion
with
authors
and
some
others
of
the
list.
We
realized
that
the
transit
node
may
not
know
their
that
mtu,
that
their
packet
hts
follow-up
packet
traverses,
so
to
identify
whether
it
needs
to
generate
originate
a
new
next
in
sequence,
hts,
follow-up
packet.
I
It
needs
to
have
this
information
that
information
has
to
be
explicit.
So
thus
we
added
hds
max
length
filled
as
32
unsigned
to
reflect
the
maximum
length
in
octets.
I
I
Probably
on
a
mailing
list:
okay,
next
slide,
please.
I
So
up
streaming,
it
was
very
interesting
to
learn
in
the
discussion
of
oem
in
constrained
environments
like
deterministic,
networking
or
reliable
available
wireless.
That.
I
Their
originally
defined
the
mode
for
collecting
telemetry
can
be
characterized
or
referred
to
as
downstreaming,
so
that
usually
our
packets
that
go
unidirectional
path
from
ingress
to
egress,
which
is
a
downstream
and
follow-up
packets.
They
that's
the
name
they
follow
the
trigger
packet
and
especially
in
raw.
I
There
was
an
interest
in
allowing
to
collect
their
telemetry
information
and
make
the
ingress
node
aware
of
experience
that
data
packets,
so
the
three
how
they
were
treated
by
the
network,
because,
especially
in
the
wireless
there's
node,
can
adjust
how
it
uses
available
resources
in
terms
of
frequency
and
other
parameters,
so
to
optimize
the
quality
of
the
service.
I
Of
course,
it
does
not
exclude
collecting
information
for
analytics
elsewhere
for
orchestrator
or
central
controller,
but
they
have
an
option
to
do
this
for
the
ingress
that
was
interesting
and
beneficial.
I
So
thus
we
introduced
what
now
we
refer
to
as
upstreaming
hybrid,
two
step
where
the
egress
can
construct
the
follow-up
packet
without
the
trigger
packet
and
using
the
path.
Engineering
techniques
define
the
nodes
that
would
be
traversed
by
this
packet,
so
that
packet
will
follow
the
same
core
routed
path
as
followed
by
the
data
packets
that
present
their
monitored
flow
and
collect
the
information,
and
then
that
will
be
deliberate
and
consumed
by
the
ingress
node.
I
I
Any
questions
about
this
scenario.
I
Okay,
so
we
probably
can
discuss
it
on
the
mailing
list
and
the
next
slide.
I
So
the
characteristic
information
we
had
a
discussion
with
frank
about
what
characteristic
information
can
be
used
by
the
follow-up
packet
and
by
hds
method.
So
one
of
their
method,
it's
basically
environment,
specific
now
for
segment
routing.
It
could
be
a
list
of
sids
for.
I
Service
function,
chaining
that
uses
network
service
header,
it
would
be
a
base
header
or
service
header
and
context
headers,
as
they
are
present.
If
the
context
header
are
present
in
a
date
of
flow
that
being
monitored.
I
And
in
iam
it
could
be.
I
am
trace
option
so,
but
their
intention
is
the
plan.
Is
that
once
we
have
a
stable
base
specification,
that
applicability
to
different
environments
will
be
defined
in
separate
documents.
I
So
with
that,
we
welcome
your
comments,
suggestions
and
discussion,
and
we
believe
that
the
document
is
stable
and
especially
since
now
we
have
additional
use
case.
That
is
interesting
for
environments
that
can
be
characterized
as
a
resource
constrained
that
net
and
raw.
I
A
A
Thank
you
all
right.
So
now
we
are
on
to
some
of
our
quick
lightning
talks
in
order
to
get
through
a
lot
of
them.
I
would
ask
that
people
can
stick
to
the
five
minute
time.
A
So,
let's
start
out
with
leani's.
Let's
find
that.
A
A
I
hope
we
lost
it
all
right.
Let
me
let
me
just
see
if
I
can
share
the
slides
myself.
Q
M
A
Come
in
yeah,
let's
come
back!
You
drop
a
note
in
this
in
the
chat
when
you're
ready.
Okay,
let's
switch
over
to.
A
R
While
this
is
coming
up
how's,
my
audio.
R
So
I'll
I'll
just
start
talking
the
yeah,
I
can
see
it
now
thanks,
so
we
we
managed
to
get
the
one-way
ip
capacity
measurement
draft
approved
and
and
it's
even
at
the
auth
48,
but
it
really
requires
a
protocol.
The
way
we
described
the
method,
and
so
you
know
we're
trying
to
standardize
that
now
it
was
helpful
to
be
able
to
separate
functions
into
the
protocol
on
the
method
too.
R
So
we
we
know
the
answers
to
the
the
two
exciting
boxes
at
the
top
there
or
smashes
at
the
top.
We
know
how
to
begin
things.
We
know
what
information
is
communicated.
R
R
There
we
go
so
so.
We've
basically
got
three
phases
here:
the
and
you
can
see
them.
You
know
the
the
client
and
the
server
are
illustrated
here.
You
can
see
them
going
down
the
page,
the
setup
exchange,
the
test
activation
exchange
and
the
test
stream
and
feedback
exchanges
take
take
place
after
that,
and
you
know
we
start
out
communicating
with
a
well-known
port
and
we
authenticate,
and
the
response
to
that
is.
It
includes
an
ephemeral
port
which
is
probably
the
most
critical
information
in
the
reply.
R
You
know
other
than
accepting
the
test
and
so
forth,
because
the
ephemeral
port
is
the
newport
that
we're
going
to
use
in
all
for
future
communication,
and
all
of
this
is
on
udp
all
right.
So
so
then,
the
test
activation
exchange
is
basically
the
offered
testing
parameters
and
we're
gonna
confirm
or
replace
those
parameters
when
we
get
them
at
the
server
and
then
the
interesting
stuff
starts
where
we
actually
make
the
test
measurements
with
the
load
at
pdus.
R
R
R
Right
now,
in
the
running
code,
we've
got
an
unauthenticated
mode,
basically
for
all
phases
and
we've
got
an
optional
authenticated
setup
only,
and
so
those
are
our
kind
of
modes
a
and
b
combined.
It
would
be
fairly
simple
to
to
encrypt
the
setup
and
test
activation
phases.
R
That
would
be
you
know,
option
c
or
mode
c,
and
because
there's
you
know,
there's
only
four
packets
in
the
total
group
there,
even
though
it's
two
phases
and
they're,
you
know
low
rate
very
easy
to
do,
but
it
gets
challenging
when
we
go
to
the
test
stream
and
the
feedback
streams,
we
think
the
next
most
likely
or
possible
stream
that
we
could
encrypt
would
be
the
feedback
messages
and
that's
where
we're
protecting
the
the
messages
that
have
the
measurements
in
them,
but
also
the
commands
for
new
rates.
R
So
this
is,
you
know,
a
likely
high
hitter
for
for
something
where
we
want
to
encrypt
and
then
integrity,
protection
on
the
test,
packets
and
then
finally
encrypted
test
packets.
But
I
mean
the
anything
we
do
with
the
test.
Pack
is
going
to
be
really
challenging.
We're
gonna
be
over
80
000
packets
per
second
at
one
gig
and
a
lot
of
little
boxes
and-
and
you
know,
cpe
isn't
aren't
going
to
be
able
to
do
it.
So
you
know
we're
interested
in
feedback
on
on
number
one.
R
Whether
these
are
the
right
modes
and
we
you
know,
we
think
it's
a
pretty
good
guess
at
this
point.
But
if
we
want
to
add
or
subtract
a
few,
we
could
do
that
and
then
and
then.
The
last
thing
we
want
to
know
is:
what's
the
bulletproof
solution
for
security
that
isn't
going
to
get
us
into
any
trouble
at
all
during
iesgu
review?
R
A
Thank
you
so
much
al
thanks
for
sharing
this
with
us.
If
you
have
questions
go
in
the
chat
and
we
can
carry
this
on
on
lists
too,
all
right
lenny,
you
think
you're
good
now.
A
Okay,
I
think
we're
gonna
need
to
come
back
to
you
again.
Apologies
for
that
everyone.
A
Can
me
just
pull
these
up
what's
going
on,
is
that
some
of
the
slides
that
were
updated
more
recently,
dude
are
not
showing
up
in
meet
echo,
so
I'm
needing
to
upload
those
again.
A
S
S
S
Extension
to
o1,
t1
and
stamp,
and
after
the
discussion
on
the
malignant
we
received
some
suggestions
from
the
manila
list.
To
you
know
it's
better
to
you
know,
split
the
track
into
two
drafts.
The
first
one
is
just
focus
on
the
stamp,
a
relevant
extension
and
the
second
one
is
focus
on
the
o1
and
t1
relevant
extensions.
S
So
here's
the
motivation
for
this
work
so
as
we
know
that
link
aggregation
group
is
what
they
used
in
the
field
and
the
it
can
combine.
Multi
physic
links
into
a
single
logic
link,
so
it
can
provide
higher
bandwidths
and
better
resilience,
resilience
and
but
the
current
you
know
active
ip
performance
measurement
tools,
only
view
of
lag
as
a
single
logic
link.
S
That
means
the
measure
metrics
only
reflect
the
performance
of
one
member
link
or
the
average
of
all
member
links
of
the
lag,
but
in
some
cases
the
delay
of
the
member
link
of
a
lag
are
different
because
the
ambulance,
the
member
links,
traverse
different
transport
paths,
but
there's
requirement
you
know
to
provide
low
delay
services
to
time
sensitive
traffic
traffic,
so
it's
necessary
to
know
the
length
delay
of
each
member
link
and
then
we
can
still
traffic
accordingly
and
this.
S
S
So
here's
a
extensions
to
the
stamp
so
for
this
extension
there's
no
changes
to
the
base
test
packet
format.
We
just
define
a
new
tier
v,
which
is
called
lag
member
link
idtrv.
S
S
You
know
just
establish
three
micro
session
on
the
lab
on
a
lag
that
means
for
the
one
micro
session,
one
for
member
link,
one
and
two
four,
two,
three
four
three,
and
when
starting
the
the
stamp
test
packet
house,
I
send
a
test
packet
of
member
link
1
and
with
the
sender
member
link
id
and
to
the
reflector
and
the
host
bay
associated
test
packet
with
a
microstation
based
on
the
for
topo
and
the
plastic
member
link
that
receiving
member
link
to
correct
to
correlate
from
which
microstation
the
packet
is
received.
S
From
and
after
process
b,
send
the
reflected
test
packet
over
the
member
link,
1
back
to
host
a
and
with
the
sender
member
link
id
copied
from
the
previous
received
test
packet
and
also
set
relevant
reflector
mobilink
id
to
host
the
a
and
in
the
in
subsequent
test
packet
host.
A
can,
you
know,
can
set
the
value.
Consider
value
of
the
reflect
member
link
id
then
b
can
use
that
that
id
to
to
to
validate
whether
the
packet
is
received
from
the
right
member
link.
J
Questions,
may
I
ask
one
question
so
only
question
I
have
is
that,
instead
of
creating
a
micro
session,
why
not
just
create
a
stamp
session
for
the
member
link,
and
then
you
know
from
the
session
id.
It
is
for
the
link,
one
two
or
three.
S
You
can
do
that,
but
you
have
to
you
know,
configure
you
know
one
by
one
right.
You
need
to
configure
for
a
single
physic
link
to
you
know
to
to
establish
your
stamp
session,
but
with
this
one
or
just
you
know
to
enable
you
know
the
it's
just
to
simplify
the
configuration.
It's
a,
I
think
in
my
personal
opinion,
I
think
it's
a
better
way
to
operate
operators.
You
know
to
enable
this
function.
I
Simplifies
configuration
and
it's
similar
to
micro,
bfd
7130,
where
it
presented
as
a
single
session
on
constituent
links,
but
in
effect
as
rakesh,
you
suggested
it
works
as
a
separate
sessions
with
the
different
seats,
but
so
additional
to
be
introduced.
Here.
It's
just
a
way
of
instrument
of
ensuring
that
exchange
occurs
on
appropriate
member
links.
J
A
Thank
you
guys
appreciate
it
all
right
for
this
next
one
giuseppe
yeah.
Thank
you.
J
T
T
That
is
used
for
to
measure
packet
loss,
latency
and
jitter,
and
also
the
extension
for
multi-point
unicast,
that
is
the
rfc
8889.
However,
there
are
some
pending
points
to
explore.
Since
now
we
are
moving
to
the
standard
to
the
standard
document
for
for
these
experimental
rfcs
in
particular,
for
ipv6,
and
so
we
met
some,
let's
say
deployment
issues.
T
That's
why
we
come
back
to
ippm
to
discuss
how
to
enhance
this
methodology,
in
particular
from
the
deployment
experience.
We
learned
that
we
need
some
from
monitor
identification.
T
T
Yeah,
this
is
a
recap
about
what
is
the
current
standard
data
fields
for
ipv6,
so
we
defined
and
the
ultimate
marking
option
that
is
expected
to
be
encapsulated
as
a
biop
option
or
destination
option
adder.
T
T
For
it
from
for
this
reason,
we
try
to
enhance
the
methodology
by
extend
through
the
the
next
letter
by
adding
new
fields
in
order
to
allow
advanced
applications,
for
example
additional
20
bit
to
extend
the
entropy
in
case.
You
have
to
do
large
scale
measurement
if
needed.
T
Additional
flags
for
special
purpose
usage
or
other
metadata
to
that
can
be
attached
for
enhanced
functions
next
slide
yeah.
This
is
just
to
mention
possible
application
possible
possible
usage
scenarios
for
these
enhanced
capabilities.
For
example,
we
can
have
shortest
market
periods,
so
we
can
reduce
the
marking
period,
also,
the
accuracy
of
the
methodology
we
can
have
more
dense,
delay
measurements,
then
double
marking
method.
We
can
also
increase
the
entropy
of
the
flow
monitor
identification.
T
We
can
also
automatically
set
up
the
backward
direction
and
so
on
so
further
extension
may
be
considered,
maybe
explored
with
this
with
this
enhanced
capabilities.
So
next
slide,
I
think,
is
the
last
one
yeah.
So
we
hope
to
have
some
comments.
As
I
said,
the
the
work
in
six
months
in
itf
last
call
so
and
we
and
it's
also
to
discuss
this
enhanced
activity
also
in
ipps.
So,
thank
you.
A
All
right,
thank
you
very
much.
We
are
out
of
time.
T
A
A
Q
Okay,
thanks,
okay,
so
so
yeah
next
slide.
Please.
Q
Okay,
so
basically,
this
is
an
extension
to
a
pdm
rfc
8250,
because
we
need
the
performance
data,
especially
at
enterprises
and
because
pdm
is
not
limited
to
an
administrative
domain.
Then
we
have
more
sensitivity
to
potential
misuse
of
the
data
and
the
metadata.
So
we
need
encryption
and
so
what
we're
get?
We
propose
a
lightweight.
What
we
believe
is
a
lightweight
and
scalable
methodology,
and
maybe
other
folks
want
to
use
it
too.
Okay,
next
slide.
Q
So
how
can
you
misuse
pdm?
Well,
you
can
learn
the
possible
weak
points.
You
know,
because
we've
got
good
performance
data,
I
mean
that's
the
idea
right
and,
and
you
know,
trigger
inappropriate
network
management.
Okay,
next
slide.
Q
So
so,
basically,
what
we
have
is
a
registration
phase
and
then
a
data
transfer
phase
registration
phase
you
do
beforehand
and
the
and
of
course
you
can
go
encrypted
as
well
as
unencrypted
the
registration
phase.
Is
you
create
a
shared
secret
and
you
do
it
just
one
time?
Q
And
then
you
don't
so
you're
not
doing
that
during
the
course
of
the
you
know
of
the
data
transfer,
because
otherwise
you
get
into
a
whole
bootstrapping
problem,
and
so
every
once
in
a
while
there'll
be
an
occasional
key
derivation
to
redo
the
keys.
Okay
next
slide.
Q
So,
okay,
so
this
is
it's
a
little
hairy
and
you
know
we
talk
about
it
a
bunch.
Basically,
the
idea
is
the
green
paths,
that's
the
data
transfer
and
that's
all
encrypted.
That
should
be
as
fast
as
possible
and
the
way
we
make
it
fast
is
we
have
these
shared
secrets
and
we
have
the
idea
of
a
primary
writer
and
a
primary
reader.
Q
You
know
for
both
the
clients
and
the
servers
and
all
that
stuff
is
done
well
beforehand
and
everybody
you
know,
gets
their
their
little
secret
to
hold
on
to
you
know
before
all
this
stuff
starts,
and
then
all
you
have
to
do
is
just
re-key
once
in
a
while
so
yeah.
So
that's
kind
of
the
idea
and
as
I
say,
we
we
had
a
whole
big
long
session.
Q
Q
So
why
are
we
doing?
This
is
because
usually
at
the
enterprise,
because
enterprises
are
huge
end
user
sites,
because
that's
what
this
is
all
aimed
at
pdm
is
aimed
at
end
user
organizations,
not
really
the
folks
in
the
middle,
and
we
have
lots
and
lots
of
servers,
lots
and
lots
of
clients
and
in
maybe
a
lot
of
different
locations,
and
you
want
to
keep
the
complexity
and
overhead
down.
Q
Otherwise,
you
get
there's
a
ton
of
keys
to
keep
track
of,
and
and
and
also
remember.
This
is
this
is,
how
do
I
say
this
isn't
the
ip
layer,
and
so
so
so
you
want
to
be
real
careful
about
how
much
you
burden
the
ip
layer
with
anything.
Okay,
next
slide.
Q
So
we're
using
hpke
and
again
you
can
see
like
the
heavyweight
stuff
is
done
in
registration
and
then
every
you
know
at
a
max
every
two
to
the
15
packets.
We
re
key
and
then
so
online.
So
you
just
have
to
do
encryption
and
decryption
with
every
packet,
and
we
there's
a
bunch
of
discussion
in
the
side
meeting
about
how
often
should
you
do
it?
Q
How
often
should
you
re-key
and
and
so
forth,
and
of
course
that's
and
you
know
what
kind
of
shared
secret
and
that's
all
it's
all
underway,
and
and
we
will
revise
according
to
the
the
feedback
that
we
got:
okey,
dokey,
okay,
so
next
slide:
okay,
hey
huzzah,
yeah
and
so
so
do
do,
send
questions
on
the
on
the
list
and
we
hope
to
have
an
implementation
by
madrid
and
if
it's
live
then
we'll
show
it
to
you
live
otherwise.
Q
You
know
we'll
show
it
to
you,
we'll
we'll
post
demos
on
the
list,
and
I
think
I
have
six
seconds
so.
Thank
you
guys
all
so
much
and
thank
the
lord.
My
mic
worked.
Q
Yeah
thanks
guys.
A
Yeah
and
for
people
who
are
interested
yeah,
please,
I
guess
check
out
the
recording
of
the
earlier
meeting
that
was
referenced
there
and
comment
on
the
list.
All
right,
we
are
out
of
time
for
this
session.
For
the
there
were
a
couple
lightning
talks
we
didn't
get
to.
People
can
still
learn
more
about
those
by
looking
at
the
slides
that
are
posted
in
the
materials
section
for
the
meeting,
as
well
as
asking
questions
on
the
list,
which
is
always
the
right
place
to
go
to
all
right.
A
Does
anyone
have
anything
else
they'd
like
to
cover
or
if
not
all
right?
Thank
you
so
much
everyone.
We
will
see
you
on
the
list
we'll
get
some
adoption
calls
coming
out
soon
and
we
will
see
you
next
time
take
care.