►
From YouTube: IETF110-IPSECME-20210308-1200
Description
IPSECME meeting session at IETF110
2021/03/08 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
C
Hello,
so
I
think
it's
whatever
time
of
two
o'clock
in
helsinki
time.
I
don't
know
what
it
is.
I
think
it's.
C
C
That
is
the
first
session
of
the
itif
110
disciplisec
maintenance
and
ib
security,
maintenance
and
extensors
working
group,
and
if
you
are
in
the
wrong
room,
you
can
go
now
out,
like
everybody
normally
goes
this
time
and
noticing.
Oh
I'm
reading
email
in
program.
C
C
Okay,
so
we
don't
have
blue
streaks.
We
are
taking
the
minutes,
the
attendancy.
I
think
it
gets
filled
in
by
automatically
by
the
data
tracker
or
something
like
that.
We
want
to
have
a
note
takers.
I
there
is
already
pre-filled
stuff
in
the
etherpad
nodes.
Actually
it
is
comedy
night.
Could
I
I
mean
now-
and
I
michael
already
said
that
he
would
be
willing
to
work
as
a
notetaker,
but
it
would
be
useful
to
have
somebody
else.
Also.
C
All
right,
good,
okay,
so
I
will
try
to
follow
the
chopper
also,
and
I
think
we
have
already
have
a
one
one
of
the
choppers.
You
know
scribes
trying
to
help.
If
there's
something
in
there
all
right,
there
isn't
the
meet
echo
link,
which
you
are
probably
aware
of.
If
you
are
already
here
and
so,
let's
see,
let's
go
forward,
so
we
have
quite
a
lot
of
items
in
the
agenda
this
week,
but
most
of
them
are
very
short,
just
a
status
update
or
something
like
that.
C
So
we
have
a
document
status.
Then
we
have
work
items
which
covers
the
group,
key
management
and
the
iptfs
staff,
both
the
base
and
the
young
document.
C
And
then
we
have
lots
of
new
items
or
send
me
new
items
like
the
configuration
for
encrypted
dns
and
new
payload
format
and
equation,
one
graveyard,
sd1
edge
discovery
and
x509
extensions
and
alternate
signature
schemes,
optional,
sats,
payloads
inside
excellent
and
multi
sa
performance.
Any
comments
on
the
agenda.
C
C
Last
call
now
the
I
question
to
intermediate:
we
didn't
get
any
comments
during
the
last
call,
and
then
we
have
an
iptfs
which
had
some
comments
and
we
are
going
to
have
some
update
on
iptfs
later
then
we
have
the
young
iptfs
staff
that
is
was
just
adopted
as
a
working
group
document,
then
we
have
gi
version
2
that
I
think,
is
ready
for
the
working
club
last
goal
and
I
think
we
should
be
starting.
C
C
Some
of
those
actually,
I
think
the
multiple
key
exchange
is
also
something
that
is
ready
for
the
last
call
all
right
so
for
the
lab
of
ip
sector.
Suppose
paul
can
say
a
couple
of
words
for
about
this.
So
go
head
ball.
E
Okay
test
one
two:
three
everybody
can
hear
me:
yeah,
okay,
great
so,
just
on
level
type,
a
sec,
there
hasn't
really
been
a
change
in
the
draft.
We've
been
doing
some
implementation
with
the
linux
kernel,
using
the
sa
linux
security
module
as
the
the
secure
label
provider.
E
It's
been
really
it's
been
like
non-standardized
technology
in
ikev1
and
in
the
linux
kernel
for
like
over
10
years,
and
so
we're
just
standardizing
this
use
for
ikv2
and
and
so
we've
we've
done
quite
some
work
on
it.
But
most
of
this
work
is
now
happening
on
the
sc
linux
specific
parts.
E
C
E
We
did
publish
the
code
last
month
for
egg
v2,
so
there's
an
implementation
out
there.
C
Okay,
so
does
anybody
have
any
comments
about
or
concerns
putting
this
in
working
group
last
call,
if
not,
I
think
you
will
start
a
group
last
course,
almost
immediately
after
this
meeting.
F
After
you've
got
a
resolution
on
that
there
was
a
question
from
lou
about
the
previous
slide
and
whether
there
we
go,
I
dropped
ietf
ipsec
me
iptfs.
He
was
asking.
F
Guess:
third:
item
down.
C
I
pasted
it
from
from
the
previous
slides
previous
meeting
and
then
it
was
still
hops
yeah
to
change
that
thanks
yeah.
C
H
Group
key
management
using
ip2
and
next
slide.
Please.
H
First
of
all,
it's
just
a
reminder:
what
is
it
what
it
is
about
and
where
it
is
used
and
about
securing
id
multicast
and
multicast
supplement
applications?
You
usually
have
at
least
one
center
and
many
receivers,
and
you
take
advantage
of
multicast
routing
which
delivers
packet
to
multiple
recipient
so
that
all
these
recipients
share
one
essay,
so
they
share
the
same
key.
So
this
requires
some
architecture
to
distribute
these
shared
keys
between
this.
A
H
Architecture
consists
of
a
group,
controller
casera
and
a
single
group
controller
cassava,
which
generates
and
distribute
keys,
and
some
group
members
and
group
members
first
create
a
unicast
iqv2
sa
to
grow
control.
The
kisera
and
after
that
group
control
kisera,
distributed
game
material.
H
A
H
Either
unicast
or
multicast,
so
next,
please.
H
So
recently,
a
new
application
for
this
protocol
appeared
its
distribution
of
group
keys
in
ieee
802.15,
so.
H
One
five
nine
specifies
iq
two
as
one
of
key
management
protocols
for
802
15,
four
and
the
first.
As
far
as
I
understand
the
current
standard
for
80
to
15
9
from
2015
and
that
group
key
distribution
out
of
scope,
but
the
current
draft
zero
five
version
of
this
standard,
and
it
specifies
this
g
ic2-
is
used
for
row
key
distribution.
H
H
So
it's
a
new
application
for
this
protocol
and
you
imagine
application
so
the
next
please
so
then
about
the
document
status.
The
document
has
been
in
development
for
several
years,
so
for
a
very
long
time
and
a
few
implementations
of
early
draft
version
exists
that
are
incompatible
with
the
current
draft
it
was
adopted.
It
has
been
adopted
by
bisect
me
a
working
group
in
2019
and
version
01
from
july
2020.
H
It
was
a
major
rewrite
of
the
early
document,
early
version
and
since
then
a
new
version
appeared,
it
was
a
minor
update
and
what
I'm
worried
about
is
the
lack
of
reviews,
because,
from
house's
point
of
view
the
draft
looks
mature.
But
we
are
worrying
that
the
document.
A
H
A
H
Algorithms
were
specified
in
the
attributes,
and
the
set
of
this
attribute
specified
a
policy.
Now
it's
more
like
ip2
style
using
transforms
and
attributes
are
still
used
for
some
variables
that
are
not
enumeration
like
initial
message,
id
values
that
can
be
changed
over
time
over
time,
then
that's
the
convention.
The
the
other
thing
that
is
followed
from
the
first
ballot
is
the
format
of
json
and
kg
below
changed
and
group.
H
Is
that
now
I
implementation
itself
doesn't
see
keys
and
clear,
so
the
key
is
that
they
can
be
stored
somewhere
in
hardware
security
model,
and
even
if
you
hack
the
diamonds
like
diamond,
you
still
don't
access
to
the
keys,
because
key
are
encrypted
even
inside
like
messages.
I
think
that
it's
a
major
change,
then
another
change
that
logical,
key
hierarchy.
Key
distribution
algorithm
is
now
integrated
into
the
core
gi
critical
before
it
was
some
addition
that
is,
that
was
optional
for
implementation.
H
Now,
the
protocol
is
changed
in
such
a
way
that
all
the
of
the
key
management
techniques
is.
It
is
gccs
that
implements
all
the
key
management
techniques
and
for
a
group
member
it
doesn't
matter
which
technique
is
used
either
it's
a
logical,
ki,
haraju
or
just
distribution
keys
without
this
hierarchy.
H
Now
it's
more
an
extension
of
ip2
so
that
all
registries
that
are
concerned
with
jqe2.
A
H
Either
in
core
iq2
on
the
page,
it
is
not
in
separate
page,
and
it
also
updates
many
ip2
existing
registries
like
transforms
and
so
on.
Many
balancers
have
been
renamed
to
reflect
their
purpose.
A
lot
of
qualifications,
for
example
our
load
calculation,
which
was
very
unclear
with
the
multi-cluster
key
messages
it
described
in
detail
introduced,
means
to
indicate
cross-dependency
of
supported.
Algorithms
using
ppk's
jquery
is
clarified.
Using
usain
is
clarified
for
lower
in
situation.
H
If
some
messages
are
lost
during
multicast
three
keys
clarified
well
example
is
rewritten
using
lth,
so
the
next
please.
H
So,
what
about
in
more
details
about
gsa
below
disabled
contain
policy
necessary
to
participate
in
the
group?
It's
protocol
protocol
can
be
either
data
security.
Esp
is
for
historical
reason.
Of
course
nobody
uses
it
or
gi
crickey.
It's
a
new
protocol
that
is
used
that
is
ip2
like
as
it
is
used
for
multicast
key
messages,
so
it
contains
also
traffic
selector
transforms
and
for
algorithm
and
method
used
in
the
policy
in
attributes
for
variables.
Like
initial
message,
I
mean
jessica
format
is
now
common
for
gi
quirky.
H
It's
g
iq,
gi,
q,
2
essays.
It
is
used
for
a
key
and
for
data
security,
multicast
to
say
it's
not
common
and.
A
Especially
some.
H
Specific
case
is
a
jet
preload,
that
is,
growth
policy
law
that
shares
the
same
format
and
specifies
the
policies
it
doesn't
depend
depends
on
the
protocol.
The
next
piece.
H
Kde
polo
j
plot
contains
key
material
necessary
for
the
policy
in
the
gsa
below
so
it
is
now
consists
of
funnel
mode
keys
that
are,
and
and
also
some
security
parameters,
and
each
key
is
individually
wrapped
in
a
new
structure
called
direct
key
and
this
each
key
is
encrypted
in
this
structure
using
either
skd
derived
key
or
other
group.
Key
and
lkh
capacity
is
now
integrated
into
the
eq
2
in
such
a
way
that
some
key
encrypted
with
other
key
in
the
same
message
or
distributed
earlier
to
this
to
this
moment.
H
B
H
May
contain,
as
a
group
key
or
may
contain
individual
key
for
this
subscriber
and,
for
example,
in
the
registration
process
with
lkh.
Each
group
member
is
provided
with
its
own
key.
So
the
next
piece,
so
idg
load
contains
an
identity
of
the
group
that
you
want
to
join.
It's
the
same
format
as
iq2id
reload
and
just
different
payload
in
the
next
place.
H
And
we
also
use
some
iq
to
pillows
some,
sometimes
with
slightly
different
semantics,
so
sag,
it's
a
safer
load
which
specifies
in
which
transforms
are
supported
with
algorithm
and
transforms,
are
supported
by
a
group
member.
So
that
gcks
knows
that
which
policy
is
is
applicable
for
this.
He
can
be
applied
for
this
group
member.
H
It
has
the
same
format.
It
is
likely
to
say,
pollute,
but
slightly
different
semantics,
which
allowed
to
to
specify
core
dependence
of
algorithm
in
jque,
2sa
and
data
security,
essay
and
delete
below
it
is
also
reduced,
and
it
also
has
slightly
different
semantics
because
it
allows
to
specify
a
zero
protocol,
which
means
that
delete
everything.
Every
say
that
you
have
a
next
piece.
H
So
we
also
have
new
notifications
invalid
group.
Id
authorization
failed
registration,
failed
sender.
It's
letters
notified
that
it
supplies
that
group
member
is
is
willing
to
send
data.
So
a
special
semantics
is
used
in
this
case
because
it
must
be
provided
with
separate
prefix
for
counter
mode
algorithms,
so
that
several
center
doesn't
have
the
same
count
as
foreground
mode
algorithm,
and
the
key
is
needed.
Is
it's
a
new
notification
in
zero
one
version?
H
It
is
used
with
ppk
to
let
dcks
know
the
gm
that
it
must
rekey
before
some
sensitive
information
is
sent
over
this
essay
because,
as
we
know,
db
key
doesn't
provide,
I
can
say,
security
against
quantum
computers
until
it
is
required.
So
the
next
please.
H
H
It
is
until
we
have
more
reviews.
I
think
that
it
is
a
bit
earlier
for
the
working
group
passport,
because
after
major
right,
we
received
zero
reviews
it.
I
was
I'm
worried
about
it,
please
review,
because
it
is
an
important
document
and
please
comment
because
it
was
major
changes
and
we
need
your
opinion.
Thank
you.
C
C
Okay
good,
so
if
you
get
couple
of
reviews,
I
think
then
we
can
actually
see
if
it's
ready
for
the
last
call
or
not,
and
when
we
get
those
reviews,
we
can
decide
whether
we
need
to
do
much
some
changes
or
go
to
the
last
call.
C
Some
of
these
is
also
a
little
bit
outside
the
scope
of
our.
You
know:
expertise
like
the
multicast
officer,
so
we
might
actually
get
more
comments
on
the
idea.
Five
last
call
than
working
loop
last
call
or
might
get
some
comments
anyways
anyway.
Okay,
thank
you
thank
you
for
that,
then
I
think
we
will
go
next.
The
next
presentation
is
iptfs
spacecraft.
G
C
I
Is
the
audio
yeah?
Okay,
it
looks
like
it's
working:
okay,
hi
everybody.
This
is
an
update
on
the
ip
traffic
flow
security
draft,
which
entered
last
call
working
for
class
call.
We
ran
recently
next
slide.
Please
these
are
the
updates.
Since
109.
109,
we
actually
were
working
on
o3,
so
we've
been
through
a
couple
of
versions.
Since
then.
The
big
news,
I
guess,
is
that
we
cleared
the
transport
area
review.
That
was
really
good.
That
was
the
one
I
was
afraid
of.
I
Those
can
be
tough,
and
then
we
had
some
pre-working
group
last
call
discussion.
Valerie
talked
with
valerie
about
making
the
draft
a
little
bit
more
generic
in
its
naming,
since
people
had
sort
of
identified
that
they
might
want
to
use
this
outside
of
iptfs,
and
it
wasn't.
I
Maybe
makes
it
a
little
bit
easier
or
more
obvious
that
you
can
do
that,
so
we
changed
the
identifiers
from
ipdfs
to
ag.
Frag
also
fix
the
overhead
numbers.
I
don't
know
how
I
calculated
the
ipsec
overhead,
but
I
got
it
wrong,
so
I
fixed
that
and
then
changed.
The
republican
five
part
of
asking
for
last
call
taro
did
a
nice
review
and
we
published
those
changes
in
o6
next
slide.
I
So
we
did
a
three
week
working
week
last
call
ended
last
two
to
14.
I
guess,
and
we
got
a
bunch
of
reviews
from
tarot
that
was
sort
of
pre
and
post,
and
then
we
got
a
review
from
sean
turner,
paul
waters,
valerie
and
michael
richardson,
and
then
we
posted
the
an
07
based
on
all
the
working
group.
Last
call
mail,
english
discussions
and
excited
talk
about
those
changes.
I
So
we
had
the
notable
changes
were
too
normative.
They
were
minor.
One
was
sort
of
clarifying
that
that
you
shouldn't
fragment
over
multiple
essays.
I
don't
know
if
it
was
clarifying
or
just
putting
it
in
there.
It
would
have
been
a
bad
idea
anyway,
but
it's
good
to
have
it
be
normative
and
also
michael
richardson
had
pointed
out.
There
wasn't
enough
info
on
packetization
layer,
mtu
discovery,
which
is
the
sort
of
the
new
recommended
way
to
do
pmtud.
I
I
don't
know
how
widely
this
is
actually
implemented,
but
there's
always
hope.
I
guess
anyway
in
in
order
to
do
this,
you
need
a
probe
packet.
We
have
those,
so
we
in
the
document
we
you
know,
point
that
out
that
you
use
the
congestion
control
packet,
says
probes,
but
there's
one
little
detail
deep
inside
the
plmtud,
where
it
says
that
congestion
control
should
not
treat
losses
due
to
probing.
So
you
know
so
think
about
it.
I
If
you're
sending
like
a
10k
packet
right
and
it
gets
dropped,
it
says
that
the
congestion
control
algorithm
shouldn't
treat
that
drop
as
a
loss
event.
So
there
needs
to
be
some
way
to
say
that
you
know
the
algorithm
is
running
currently,
and
so
I
added
a
p
bit
for
that.
But
it's
not
actually
used
by
you
know
ag
frag
or
iptfs,
but
it's
just
for
use
by
pl
t
p,
o
m
t,
u
d,
to
say
it's
in
the
process
of
doing
that.
I
Most
of
the
changes
were
informative.
A
lot.
A
lot
of
editorial
cleanup
looks
nicer.
Now
organizational
cleanup
like
splitting.
You
know
bits
out
into
subsections.
Like,
as
previous
mentioned,
we
changed
iptfs
identifiers
to
ag
frag
for
on
on
the
wire
identifiers.
We
expanded
the
text
on
the
ordering
the
packet
processing
on
the
receiver.
I
We
expanded
the
text
on
how
extra
padding
could
be
used
to
avoid
fragmentation
that
you
know
and
even
mentioned
that
you
know
this
is
sort
of
nice,
because
if
you
lose
a
packet
you
only
you
only
lose
that
packet.
You
would
lose
a
you
know.
Fragmented
packet
also
added
a
section
of
on
the
summary
of
receiver
actions.
You
know
with
internal
references.
I
So
just
just
a
you
know
section
that
points
at
those
three
places
and
again
I
fixed
the
overhead
for
the
comparisons
and
the
appendix
same
conclusions
that
just
missed
you
know
some
bytes,
but
it
didn't
change
any
anything
because
everything
sort
of
whether
using
ipdfs
or
ipsec
that
use
the
same
overhead
right
so
next
slide
so
moving
forward.
We
did
complete
the
working
group
last
call
period.
I
think
we've
addressed
all
the
reviews
and
incorporated
you
know.
I
Most
of
the
changes,
not
everything
but
most
of
the
changes
and
yeah
so
wondering
if
it's
ready
to
go
to
the
ice
sheet,
I
think
that's
the
last.
H
Okay,
I
just
only
want
to
explain
why
I
think
that
more
generic
draft
would
be
better.
H
I
think
that,
besides
iptfs,
which
which,
of
course
is
a
primary
application
for
this
mode,
another
very
interesting
application
for
this
mod
is
an
increasing
of
performance
for
short
tickets,
because
when
you
use
esp
for
encrypting
for
protecting,
for
example,
war
id,
which
is
very
short
about
20
bytes,
we
have
another
hat-
that
is
hundreds
of
percent,
and
if
you
can
put
several
of
such
packets
into
single
balloon,
which
will
decrease
in
overhead
of
your
tactical
head
significantly,
and
I
feel
that
it's
it's
completely
a
different
application.
H
And
if,
for
example,
somebody
decided
to
write
a
draft
that
explains
how
to
nucleus
mode
for
such
application,
it
will
require
to
this.
Resisting
epidemic
has
dropped
as
a
description
of
the
mod
aggregation.
H
And
when
implementer
opens
this
draft,
it
will
only
see
iptfs
repeated
as
the
qtls,
so
it
will
think.
Oh,
it's
just
a
proper
use
of
a
mod
that
was.
H
It's
exclusively
for
ibiza
trajectory
security.
That's
why
I
think
that
it's
it's
more
useful
to
first
define
the
mode
itself,
irrigation
and
augmentation
and
then
even
in
the
same
document,
just
with
renaming
instruction
on
it
and
more
accurately
choosing
awards
in
each
section
and
then
describes
it.
The
primary
application
is
ip
traffic,
close
security,
but
it's
not
the
only
application
and
the.
A
I
So
I
I
do
have
a
response
to
that.
We
it's
it's
not
that,
so
it
isn't
just
an
appendix
use
case
of
ag
frag
right
I
mean
we
have
congestion,
control
and
the
reason
we
had
have
congestion
control
and
the
reason
we
had
to
go
through
transparent
review
and-
and
all
of
that
is,
is
because
of
congestion.
Control
right
congestion
control
has
nothing
to
do
with
that.
Crag.
It's
iptfs!
I
It's
because
we're
fire
hosing
right
we're
sending
packets
at
a
constant
rate
and
there's
a
lot
of
things
in
here
which
are
iptfs
and
we
did
take.
You
know
your
suggestions
about
making
it
generic,
including,
I
think,
three
different
areas-
the
abstract,
the
informative
and
even
another
area.
Where
we
specifically
say
you
can
use
this
encapsulation
elsewhere,
but
reorganizing.
This
document
to
be
a
generic
with
a
use
case
addendum
is
not
going
to
help
people
implement
iptfs,
which
is
the
goal
it's
the
chartered.
I
You
know
feature
that
we're
trying
to
do
here
and
if
somebody
wants
to
use
it
to
improve,
do
improve
performance,
they
can
write
a
document,
an
rfc,
a
draft
that
talks
about
that.
I
don't
think
it's
going
to
be
hard
at
all
for
an
implementer.
I
mean
we're
talking
about
like
saying.
Oh,
should
I
do
this?
We
specifically
say
you
can
do
it
like
three
different
places
in
a
document.
I
I
don't
think
reorganizing.
H
Well,
I
agree
that
some
some
section
of
the
document
like
rotation
control
is
very
specific
for
pkf.
I
agree,
but
a
section
of
describing
aggregation,
fragmentation
from
mark
itself
and
the
section
described
in
the
negotiation
of
this
mod
and
the
section
describing
of
some
general
ingress
and
angers
behavior.
It's
it's.
It's
not
concerned
with
apt
exclusively,
but.
H
B
I
I
C
I
think
there's
two
things
that
it's
actually
sometimes
it's
actually
very
good
to
have
a
separate
you
know
like
like.
If,
like
we
see
it,
then
like
oaks
or
intermediate,
or
something
like
that,
it
started
inside
the
one
of
the
you
know
drafts.
Then
we
realized
it's
actually
going
to
be
useful
for
other
things,
and
I
I
think
actually
now
we
already
have
some
other
uses
for
that
and
separating
it
out
as
a
completely
separate.
C
So
actually,
if
you
think
about
somebody
only
implementing
the
receiving
end
of
this,
because
in
some
cases
where
you
have
you
have
to
have
a
client,
you
have
to
have
server
doing
both
of
these,
and
I
think,
if
you
have
a
very
clear
way
to
say
that
okay,
this
is
the
receiving
end.
They
don't
need
to
care
about
sending
you
know
pockets
at
a
constant
rate.
They
just
need
to
be
able
to
understand
what
they
get
from
the
from
the
other
end.
And
then,
if
you
have
a
very
good,
that's
why?
C
I
C
Yeah,
it's
completely,
what's
easy!
That's
what
that's
why
it's
much
easier?
It's!
No!
We
don't!
We
allow
them
to
be
able
to
send
iptf
as
frames
in
both
directions.
You
don't
have
to
send
them
in
constant
rate
in
both
directions.
That's
true!
So
so
it's
completely
valid
to
make
an
implementation
who
receives
ipv,
tfs,
fragments
reads:
these
aggregates
separates
them
out.
Does
com
everything
correctly,
but
only
since
you
know,
if
you
know
fragments
that
don't
say
constant
size,
fragments,
yeah.
I
I
It's
already
got
a
summary
section
on
the
receiver
right
and
it's
very
simple.
I
I
think
that
valerie
is
looking
to
change
this
document
into
a
generic
encapsulation
and
I
think
that's
fine.
If
that's
what
the
working
group
wants
to
do,
if
they
want
to
get
walk
away
from
iptfs
and
start
working
on,
a
generic
encapsulation
drive
no.
C
I
I
I
I
don't
think
people
want
to
wear
the
way
to
ip
dfs.
I
think
they
want
to
be
able
to
see
that
it's
a
it's
written
in
a
very
I
I
don't
think
they're
actually
going
to
be
just
annexed.
It's
it's
going
to
be
like
you
know.
We
have
a
fire
form
at
first
and
then
we
have
the
how
to
use
that
wire
format.
I
C
Actually,
I
would
actually
propose
that
valerie,
because
you
have
been
looking
at
this
and
you
would
think,
would
you
actually
make
a
proposal
of
you
know
what
changes
concrete
changes?
What
you
know
text
you
would
want
to
move
or
something
like
that,
something
like
that
to
the
list
and
and
then
we
can
see
if
it's,
if
it's
so
big
that
I
don't
think
you
actually
need
to
you
know
hash
down
the
you
know
the
actual.
C
I
C
C
He
skips
it
and
then
we
are
funny
fine
with
that.
If
he
says
okay,
it's
going
to
be
seven
paragraphs
here,
moving
that
back
and
forth,
then
we
see
that
they
actually
brought
that
much
of
text
and
then
we
can
see
what
the
actual
text
is
going
to
be
just
trying
to
get
internalized
concrete
steps
to
go
forward.
I
Well,
yeah,
it
says
you
use
iptfs
everywhere
and-
and
you
should
move
all
this
stuff
later
and
I
that's
why
I
said
I
did
say:
you'd
send
it
already.
I
don't
think
that's
enough,
I
think
if
in
working
last
call
we
want
to
change
this
document
so
heavily.
We
should
have
an
example
of
what
that
looks
like.
F
F
Well,
so
channeling
kind
of
semi
jab
ascribing
what's
in
the
chat
in
case
people
have
missed
that
so
ben
notes
that
there's
another
instance
of
a
specific
use
case
being
included
in
a
single
document
and
that
making
it
awkward
when
other
drafts
wanted
to
use
that
framework,
but
not
the
other
parts,
as
tereno
noted
earlier
paul's
view
bit
late
to
totally
reorganize.
The
document
mike
richardson
disagrees
with
making
it
generic
and
unless
and
until
there's
a
second
use
case
paul.
F
There
is
a
second
use
case
mike,
don't
mind,
valerie,
writing
a
this
document
or
a
book
explaining
stuff
but
doesn't
want
this
document
held
up
so
there's
a
fair
amount
of
to
and
fro
in
the
chat
there.
I
C
B
C
Understand
some
of
these
about
actually,
but
but
I
I
mean
it's,
it
wasn't
that
easy
at
that
point.
C
So
I
think
lulu,
oh.
J
I
wanted
to
mention
that
I
thought
the
characterization
of
the
conversation
in
jabber
was
incorrect.
Just
whoever
said
that
there
was
going
back
and
forth,
but
I
see
three
comments
that
they
don't
wait.
I
don't
see
anyone
saying
wait
so
yeah
there
was
there's
discussion,
but
you
know
we
have
paul
saying
it's
late
to
reorganize.
We
have
michael
saying
basically
the
same
thing
I
said
plus
one,
but
you
know
I
am
a
contributor
on
it.
So
yeah
I'm
biased,
but.
C
J
C
Think
anybody
wants
to
wait.
Wait
would
mean
that
we
wouldn't
do
anything
until
something
happens.
I
think
people
want
to
work
on
the
draft
and
get
it
out
as
soon
as
possible.
I
don't
think,
actually
you
know
changing
it
to
the
you
know.
This
kind
of
thing
is
actually
that
many
hours
of
work,
so
so
we
are
not
talking
about
waiting
for
two
weeks
or
three
weeks
or
something
like
that.
C
I
wanted
this
to
go
out
very
quickly,
but
I
want
to
also
be
to
be
best
possible
documents
we
have
so
that's
why
I
was
you
know,
that's
why
I'm
saying
that
if
valerie
can
actually
work
on
this
quickly,
then
we
can
go
on
forward
if,
if,
if
he
thinks
that
he
can't
do
it
in
early
quickly
enough,
then
then
we
go
forward
with
this
one.
F
Thank
you,
lauren
apologies.
There
were
indeed
several
comments
in
in
favor
of
not
not
delaying
this
further
there's
also
a
further
comment
from
mike
richardson
mike.
If
you
have
audio,
could
you
possibly
expand
that
because
mike's
comment
is
it's
a
ps
when
the
second
use
case
comes
along
restructure
it
for
ies.
D
Yeah,
it's
a
proposed
standard
and
the
the
bar
for
that's
already
too
high,
and
if
a
second
use
case
comes
along,
then
some
we
can
write
some
more
documents
and
can
do
abyss
and
that
will
be
a
much
more
efficient
use
of
the
ietf's
time
than
waiting
right
and
I'll.
Give
you
an
example
of
81
rfc
8152.
D
F
C
All
right
so
so
my
proposal
is
to
wait,
for
you
know
to
the
wait
I
valerie
working
on
this
to
get
the
concrete
proposal.
What
would
be
to
change
this
to
be
to
be
done
to
the
draft
in?
C
I
would
say
end
of
next
week,
something
like
that:
yeah,
it's
good
and
and
then
then
I
would
actually
also
because
we
before
we
go
forward.
We
need
to
have
a
you
know,
other
other
things
going
on
with.
We
will
start
simultaneously
going
on
which
will
be
delaying
something
for
for
for
us.
Anyway,
we
have
some
works
to
do
with
outers
and
so
on.
So
we
will
work
on
that
at
the
same
time
simultaneously.
So
this
shouldn't
be
delaying
anything
of
this
going
forward.
K
So
just
one
other
thing:
when
people
come
to
the
mike
and
well,
they
don't
come
to
the
mic
when
they
open
the
mic
and
talk.
Please
state
your
name
because
later,
when
you
watch
youtube
recordings,
you
can't
tell
who's
talking.
You
don't
see
who's
talking.
So
please
state
your
name
as
if
we
were
in
a
physical
meeting.
C
F
F
Yeah
one
one
technical
update,
one
participant
one
participant
reported
that
the
the
audio
streaming
feed
wasn't
working,
so
I've
opened
a
ticket
for
it
and
I've
had
a
response.
They
have
identified
the
source
of
the
problem
and
it's
only
it's
only
affecting
ipsec
me
sorry
about
that.
They
are
working
to
fix
it
before
the
end
of
this
session.
For
us,
the
ideal
stream
wasn't
secure
enough.
C
Yeah
they
should
have
been
using
ipsec
and
the
question
there
is,
of
course
it
hopefully
is
still
going
to
be
recorded,
and
I
mean
I:
I
don't
think
that
many
people
are
using
the
direct
audio
stream
as
long
as
the
me
take
works
and
if
it's
going
to
be
recorded
correctly,
that's
that's.
You
know
good
enough
if
they
can
always
check
check
it
out
later
and
okay.
So
any
other
things
about
this
topic.
C
L
C
L
Hi
don
fettick
here,
laban
consulting
so
this
is
the
the
yang
model
for
ip
traffic
set
flow
security.
Next
slide,
please
so
we
we
had
some
updates
based
on
the
working
group.
Adoption
call
and
we
reorganized
the
statistics
to
separate
inner
and
outer
stats
a
bit
better.
L
We
added
a
max
aggregation
time
as
a
as
a
control
option
and
we've
we're
built
on
top
of
the
yang
for
i2
nsf,
which
is
a
more
a
complete
ipsec
yang
for
ike
and
iklis
and
stuff
like
that,
so
because
we're
built
on
top
of
that
we're
augmenting
it
if
they
change
any
names
and
stuff
like
that,
the
test
files
that
we
have
require
updating.
So
we
did
that
and
the
the
current
version
is
zero.
L
L
Sorry,
it's
a
bit
of
a
I
chart
test,
but
it
just
shows
the
organization
of
the
management
parameters
and
the
the
readout
of
those
on
the
left
side
and
then
the
statistics
so
there's
some
generic
ip
sex
statistics
at
the
top
and
then
the
inner
packet
and
outer
packet
statistics.
L
Next
chart
so
next
steps
track
any
changes
in
the
base.
I
ipsec
iptfs
specification
make
sure
that
we're
up
to
speed
on
that
solicit
feedback
from
the
work
group.
We
we,
you
know
like
comments,
anything
we
are.
We
we
have
running
code
for
iptfs
and
we
are
implementing
this
yang
as
well.
So
next
chart.
L
So,
along
with
that,
we're
also
implementing
a.
L
So
we
we
wanted
to
provide
a
read-only
snmp
nib
in
the
in
for
the
same
objects,
so
we
have
requirements.
Some
operators
still
require
snmp
support
and
we
we
try
it
as
much
as
possible
to
mechanically
derive
that
from
the
yang
model,
there's
not
a
program
to
do
it,
but
it's
a
one-for-one
type
of
mapping,
and
I
I
just
showed
an
example
here
of
the
the
layer,
two
fixed
rate,
what
it
looks
like
in
yang
and
what
it
looks
like
in
snmp
next
chart.
L
So
the
the
tool
like
this
snmi
tools
also
summarizes
the
the
mib
in
sort
of
an
organization
that
looks
a
lot
like
the
the
yang
tree.
So
I
thought
that
was
useful
and
we've
captured
that
in
the
document,
as
well
as
the
mib
definitions,
and
so
this
just
shows
the
the
organization,
and
if
you
looked
at
the
yang
tree,
you
would
find
that
there's
a
pretty
high
correlation
between
the
two
next
chart.
L
So
we
we'd
also
like
to
adopt
this
as
a
a
working
group
document,
and
so
I
think
that's
basically
it
any
comments
or
questions.
K
Well,
you
have
neuro
speaking
with
no
hats.
Well,
maybe
the
i2
and
sf
chair
head.
You
mentioned
the
sdn
ipsec
flow
general
flow
thing
so
that
just
passed
the
isg.
It's
approved,
it's
still
a
revised
id
needed,
but
this
should
no
longer
be
a
moving
target.
F
C
I
I
think
we
have
seen
other
young
documents
before
we
have
never
published
any.
I
think
we
have
seen
a
couple
of
management.
You
know
documents
coming,
I'm
going
and
usually
they
just
come
and
people
are
interested
and
then
people
are
realizing
that
they
can't
really
use
them
that
much
that
they
go
away.
But
hopefully
this
would
be
the
first
one.
That's
actually
going
to
be
used
and
pop.
That's
an
rfc.
F
And
ben
has
a
follow-up
clarification
about
8152
bis.
He
says
for
the
81
52-bit
situation,
81
52
bis,
strzok
is
an
internet
standard,
82,
81,
52
bis,
algs
is
informational
and
draft
ietf
cozy
counter
sign
is
newer
functionality
and
is
going
for
proposed
standard.
If
I
recall
correctly,
paul
vargas
says
we
reviewed
the
nsf
ones.
C
Alright,
so
I
think
that's
so
so
I
is
there
any
other
comments
on
this.
These
documents.
C
And
it
was
just
adopted
as
a
working
group
comment,
so
I
would
hope
people
could
document,
so
I
would
hope
people
actually
review
it
and-
and
my
understanding
is
that
there
is
also,
if
there's
so.
I
don't
think
there's
it's
now
up
to
date
with
the
you
know
currently
iptfs
and
the
current
other
documents
right,
yeah,
okay,
so
so
so
it
there
shouldn't,
be
you
know
any
any
anything
to
requiring
it
to
be
updated.
C
There
is
also,
I
don't
think,
there's
that
much
hurry
with
this
one
than
that
than
the
iptfs.
So
I
think
we
actually
try
to
get
iptfs
out
first
and
then
push
this
after
iptfs,
because
I
don't
think
there's
any
need
to
keep
them
in
sync
or
keep
them.
I
think
the
iptfs
is
more
important.
C
I
We'll
probably
ask
for
a
adoption
call
on
the
third,
the
the
mib.
Oh.
I
C
Okay,
so
so
I
can
actually
start-
and
you
know,
working
group,
because
I
think
it
goes
to
the
same
category
and
the
current
you
know.
C
G
M
Ben
yeah,
I
was
just
gonna
chime
in
as
well
about
using
an
automated
tool,
because
you
know
it's
sort
of
easier
to
have
more
confidence
in
the
results,
especially
if
there
is
some
change
to
the
yang
model
that
you
then
have
to
try
and
propagate
into
the
snmp
mib.
I
Yeah,
that's
why
I
mentioned
don,
took
it
out
of
this
presentation,
but
he
did
start
with
an
automated
tool,
so
it
just
had
some
cleanup
to
do
on
it
afterwards.
C
I
I
was
actually
thinking
about
if,
if
there's
some
things
that
are
missing
from
the
tool
or
something
that
we
should
hopefully
see
that
augmented,
if
there
is,
I
think
I
mean
some
of
those
probably
need
to
run
like
special
cases
in
some
of
the
things.
But
then
we
could
have
just
a
configuration
file
so
that
this
is
the
configuration
files
we
are
using
for
automatically
generate
this
using
these
special
cases,
but
anyway,
okay,
that's.
I
C
H
Hi,
well,
there
is
a
slow
file
is
plus
so
it's
a
presentation,
repeated
presentation
about
ip2
configuration
for
encrypted
dns,
so
the
next
please
so
the
last
time
it
was
presented
in
iitv,
iphone,
9
and
discussed.
H
So
from
previous
version
there
were
some
changes.
First,
a.
A
H
Attribute
was
introduced
and,
and
is
variety
blade.
It
is
used
for
transferring
overriding
plates
for
dennis
over
at
appears,
and
it
was
also
done
some
qualification
on
our
authentication,
private
equipped.
Dns
servers,
so
I
was
encrypted
in
a
server
hosted
by
the
provider,
can
get
to
the
main
available
certificate
from
a
public
series,
but
it
is
only
accessibility
and
connected
to
the
bin.
It
was
a
qualification,
so
the
next.
A
H
H
Piece
for
doh
specifics
server
may
support
more
than
your
writing
play.
So,
if
is
requested,
the
national
initiative
includes
an
empty
and
then
us
writing
plate
attribute,
in
addition
to
english,
ip
4
or
ip6
doh
attribute
in
the
cafe.
A
H
And
if
the
respondent
includes
dns,
ip4,
joke
or,
and
then
safety
fixed
dog
in
the
response,
it
must
also
increase
and
they
need
to
write
a
plate
carrying
one
or
more
right.
H
That's
very
simple,
and
these
mechanism
voids
need
to
rely
on
security,
discovery
mechanism
like
gcp
or
rotated
advancement
and
on
dns
or
port
53,
which
requires
additional
rtt
and
it
is
not
always
secure.
Since
then,
the
sec
is
not
one
data.
H
So
that's
all,
and
I
also
think
that
we
can
reconcile
the
adoption
of
this
document
in
a
second.
F
E
Okay,
very
strange
okay,
so
I
read
the
document
and
I
I
find
that
it
it's
it's.
It's
mixing
up
provisioning
and
ike
protocol
like
where,
with
ike
protocol
you
hand
out
information
from
the
server.
You
have
a
client
server,
trust
relationship
and
that's
how
you
authenticate
the
information
and
what
what
this
does
is
like
somewhere
in
between
provisioning,
where
you,
so
you
don't
hard
code,
the
dns
servers
in
a
provisioning
profile.
E
You
you
allow
them
to
be
specified
in
ike,
but
then
all
of
the
authentication
of
them,
like
is,
is
left
out
of
the
document
is
not
mentioned
in
the
security
considerations.
How
how
that
works
and-
and
it
even
says,
scary
things
like.
Oh,
you
might
authenticate
the
tls
server
of
the
you
know
the
dns
server
over
web
pci,
using
a
public
certificate
from
the
internet
that
the
server
got
previously.
E
I
find
that
really
scary.
I
would
really
want
to
see
a
way
where
the
ike
server
can
convey
the
certificate
used
to
authenticate
the
dns
server.
If
the
dns
server
is
using
a
certificate
because
we
are
ike,
we
are
the
authoritative
source
of
information
for
these
things
and
so
sourcing
that
out
to
somewhere
on
the
world
or,
like,
let's
encrypt,
seems
like
a
dangerous
proposition
to
make.
E
I
also
have
some
minor
things,
but
that
I'll
I'll
bring
those
to
the
list.
But
but
my
my
big
concern
is
that
you
really
need
to
be
able
to
have
this
as
a
standalone
system,
where
you
can
send
a
certificate,
along
with
the
specification
of
the
door
or
dot
or
your
servers.
H
Well,
thank
you
for
a
comment
and
I
think
that
it's
it
can
be
an
improvement
to
the
draft
that,
of
course,
the
draft
is
not
perfect,
and
if
the
working
group
decides
that
you
just
still
want
to
work
on
it,
I
think
that
these
changes
can
be
discussed,
probably.
K
Okay,
tommy.
N
All
right,
can
you
hear
me?
Yes,
we
can
okay
yeah.
So
thanks
for
sharing
this,
and
thanks
for
the
updates,
I
agree
with
paul
that
it
would
be
nice
to
see
a
bit
more
strong
authentication
in
here.
However,
I
think
this
is
something
that
we
could
adopt
in
the
group.
I
think
it
is
ready
for
that
regarding
the
relationship
to
add,
it
essentially
seems
to
be
the
same
as
the
dnr
document
in
there,
which
is
the
dhcp
just
kind
of
taking
those
exact
formats
and
stuffing
them
into
the
ike
attributes.
N
F
A
couple
of
comments
from
the
chat,
mohamed,
booker
they're,
responding
to
paul
paul's
concerns
that
these
are
the
kind
of
things
that
can
be
worked
out
when
adopted,
and
then
scott
flora
again
replying
to
paul.
How
you
get
a
certificate
is
not
security,
important!
It's
how
to
verify
the
cert
and
then
mohammed.
Just
concurring
with
tommy's
tommy's
comment.
D
Hi,
so
I
had
read
the
document
I
think
previous
rev
and
I
followed
a
lot
of
the
add
stuff
and
even
though
a
lot
of
noise,
I
I
don't
think
feel
that
add,
has
progressed
far
enough
for
us
to
reasonably
say
answer
any
of
paul's
questions,
for
instance,
and
I
think
that
that
working
group
is
actively
trying
to
do
that
problem.
So
the
things
that
paul
said
he
felt
were
scary.
D
Yeah
would
be
completely
scary
if
you
were
doing
them
with
just
this
document
in
no
other
context
whatsoever.
So
I
don't
actually
think
we
should
adopt
this
document.
I
actually
think
that
add
should
adopt
this
document
and
we
should
review
it
because
I
really
think
that
the
the
question,
as
was
said
in
chat
about
how
do
you
verify
these
certificates,
and
what
do
they
mean?
D
That's
really
what
addd
is
really
in
some
sense
trying
to
solve,
and
so
whatever
solution
they
come
up
with.
This
document
would
need
to
be
in
in
synchronous
with,
so
I
would
say
that
no,
we
should
not
adopt
it.
We
should
strongly
suggest
that
this
should
happen
in
edd,
with
our
review.
H
Well,
I
think
that
the
document
is
one
kind
of
cross
area
documents,
as
it
is
always
difficult
to
to
decide
which
era
it
must
be
adopted
in
so
probably
addie
is
also
a
good
option
for
trying
to
adopt
the
drought
here
there.
H
But,
as
far
as
I
remember
the
last
time
we
tried
to
present
it
well,
it
was
it
was.
I
think
it
was
in
july
to
ask
for
adoption.
They
deserve
that.
H
Well,
it's
not
concerned
with
abd
it's
specific
with.
It
was
something
like
that.
So
probably
you
can
try
again.
K
K
C
Agree
on
that,
I
think
I
think
we
want
to
keep
that
we
make
the
we
make
the
payloads
and
so
on,
but
I
think
we
already
have
done
that.
I
think
the
document
already
has
those
things
specified:
okay,
the
scent
the
semantics
of
what
they
what
they
are
meaning
is
what
I
think
I
don't
or
what
paul
do
you
have
any
concerns
about
the
actual
bits
on
the
wire,
or
do
you
actually
have
only
what
the
semantics
of
the
meaning
of
these
bits.
E
Does
audio
now
great?
Okay?
Sorry,
so
so,
actually
I
I
do
have
some
other
issues.
So,
for
instance,
section
three
is
a
section
about
deployment,
examples
and
things,
and
that
goes
into
the
same
trouble
that
the
entire
working
group
has
is
that
people
don't
even
agree
on
whether
the
working
group
should
tackle
all
of
that
space?
E
But
the
other
thing
I
wanted
to
to
clarify
is
like
I
spent
a
lot
of
time
with
with
tommy
on
the
split
dns
rfc,
because
the
dls
working
group
and
the
web
pki
people
were
really
concerned
about
the
change
of
trust
anchors
when
you
redirect
dnsx
server
to
something
under
your
control,
and
this
document
is
actually
doing
that
and
the
phrasing
around
split
dns
is
also
kind
of
dangerous
like.
If
I
set
up
a
split
dns
then
can
I
get
google.com?
E
You
know
dns
sec,
trust
anchors
and
do
other
things.
The
there's
there's
a
serious
security
consideration
section
that
should
be
written
there
and
should
be
reviewed
by
the
web
pki
people
again,
just
like
you
did
for
the
split
dns
rfc
and
I
think
the
security
consecutive
right
now
is
just
a
really
bad.
M
All
right
so
ben
yeah
hi,
this
is
ben
kaydock.
I
wanted
to
reply
to
paul,
I
guess
twice
now
so
at
the
beginning,
when
we
were
talking
about,
you
know,
conveying
the
certificate
in
ike
versus
having
a
web
pki
certificate
for
the
doh
server.
M
M
And
you
know,
maybe,
if
we
wanted
to
do
something
in
this
space,
we
would
be
talking
about
conveying
the
trust
anchor
that
you
want
to
use
or
perhaps
forcing
the
specific
and
entity
certificate
as
a
way
of
trusting
the
leaf
directly
and
that
gets
back
into
the.
The
second
point
that
you
were
making
about
the
security
considerations
and
interacting
with
the
web
dki
and
getting
the
review
from
that.
So
I
definitely
agree.
C
Described
all
right,
so
I
think
we
have
to
be
going
forward
on
this
big
soon.
One
of
the
things
I
I
was
thinking
about
we
do
want
to
you
know,
review
this,
and
I
think
we
actually
want
to
you
know
have
people
to
actually
work
on
this
in
ipsec
me
so
because
I
I
still
think
that
it
actually
probably
would
be
either.
We
actually
just
published
the
you
know
the
raw
bits
on
the
wire
and
and
then
the
add,
defines
what
they
are.
C
You
know
used
for,
or
we
just
you
know
head
it
back
to
the
add
to
add
the
police
stuff
that
what
they
want,
but
I
don't
think
we
can.
Actually
you
know
so
so
I
would
actually
want
people
to
actually
review
this
document
anyway
and
get
more
comments
on
it
and
and
and
then
we
can
actually
start
thinking
about
whether
it
must
be
adopted
here
and
they're.
Very,
very,
very,
should
be
actually
published
because
I
think
they're.
Actually
we
get
we
can.
D
I
still
had
a
a
comment
that
that
I
mostly
agreed
with
paul
that
I
thought
that
the
document,
if
it's
going
to
say,
go
into
the
policy,
then
it
needs
to
be
an
add
if
you
want
rip
out
on
just
do
protocols.
If
we
really
feel
strongly
that
that
only
the
ipsec
me
working
group
could
possibly
publish
the
bits
on
the
wire,
then
fine,
in
which
case
the
document
says
too
much,
but
will
probably
then
fail
a
security
review
when
it
doesn't
have
the
rest
of
the
the
content
in
it.
D
So
I
guess
your
plan
is
good,
one
that
we
should
do
more
work,
but
I
just
think
that
we're
gonna
get
nowhere
until
add
actually
gives
us
a
document
to
point
at
for
the
rest
of
it.
C
Now
I
agree
on
that
that
I
don't
think
you
can
actually
publish
this
before
the
add
desires
things,
but
we
can
work
on
it
and
we
can
make
it
so
that
actually
is,
as
I
said,
we
want
to
be
able
to
be.
You
know
check
out
all
the
bits
that
we
are
putting
in
direct
version
2..
I
don't
necessarily
require
them
to
be
published
in
ipsec
may
I
want
to
have
us
to
have
a
proper
review
on
that,
and
I
want
to
have
that
reviewed
up.
C
H
Well
again:
well,
there
is
no
slope
for
this
and
I
want
to
tell
a
little
bit
about
the
possible
new
format
for
ipad
next,
please.
H
So
what
problems
do
we
have
with
current
formats?
I
think
there
are
at
least
two
things
that
make
it
not
very
good
for
some
application,
but
it
contains
a
lot
of
redundancy
and
many
pillows
contains
a
lot
of
zeros
and
lens
occupies
always
occupies
two
octets
and
but
while
most
balloons
are
short
and
most
parameters
compared
to
bytes,
and
we
actually
allocate
less
than
256
values
and
a
lot
of
result
fields.
So
this
is
just
an
example
from
wireshark
so
of
a
simple
load.
H
The
load
size
is
48,
bytes
and
24
of
them
exactly
50
are
zeros
next,
please.
H
So.
The
other
problem
is
that
the
load
length
occupies
exactly
two
bytes,
so
the
load
size
is
limited
to
64,
kilobytes
and.
H
So
it's
now
because
in
like
he
does,
there
are
four
bytes
four
lengths
it's
up
to
four
gigabytes,
but
each
individual
load
cannot
exceed
64
kilobytes.
H
If
we
make
a
load
smaller,
then
it
would
decrease
power
network
bandwidth
for
iot
devices,
which
is
very
precise
for
them
receivers
for
them,
and
it
would
also
decrease
chances
of
the
fermentation
in
the
initial
exchange,
which
is
also
very
important,
because
accreditation
doesn't
work
in
the
initial
exchange
next,
please,
and
if
we
lift
64
kilobytes
size
limit,
as
that,
this
would
allow
using
quantum
algorithm
public
keys
that
some
people
want
to
use.
It
also
would
allow
transfers
large
chunks
of
data,
for
example,
in
configuration
below
so
the
next
piece.
H
H
At
the
same
time,
sample
loads
might
have
special
format
if
it
is
just
a
quiet,
it
is
very
it
if
it
is,
a
lot
of
combat
reducing
in
size
can
be
achieved.
If
you
have
special
formats
non-non,
not
the
generic
one
for
the
network.
H
C
H
No,
I
was,
it
was
some
strange.
I
was
kicked
off
from
there.
H
So,
just
repeat-
and
this
is
a
proposal
etc
proposal-
I
don't
have
a
draft-
it's
just
some
sort,
so
it
is
possible
to
have
three
possible
format
for
generic
reload
heater
for
smoky
loads,
with
up
to
64
bytes
in
length
for
medium
size
below
it
up
to
four
kilobytes,
eight
kilobytes,
sorry
and
flash
below
its
up
to
512
megabytes.
H
H
Unnecessary
fields
when
they
duplicate
each
other
and
we
can
define
the
special
formats
for
some
balloons
for,
to
my
mind,
it
comes
in
a
safer
load
and
empty
status
notifies.
It
is
very,
very
often
used,
and
that's
please.
H
This
is
just
the
top
proposal
for
new
generic
heater,
so
we
can
leave
a
critical,
beat
and
use
the
next
two
bits
to
indicate
as
the
length
of
ballot
of
the
field
per
load
length.
So
it's
just
in
this
format
in
the
ballot
key
field
block.
H
A
length
of
either
6
bits,
13
bits
or
29
bits
for
large
blocks,
depending
on
the
probability
bits.
Next,
please,
we
can
revise
an
existing
load
heaters,
for
example,
for
key
exchange,
identification,
authentication,
configuration.
H
A
A
H
Either
and
we
can
remove
normal
of
spi
fill
because
it
can
be
deducted
from
the
load
length,
the
traffic
selected.
We
can
remove
reserve
field
and
remove
number
of
ts,
because
it
can
also
be
deducted
from
the
load
length
the
next
piece,
so
we
can
define
a
special
format,
photo
loads.
It's
inspired
by
my
draft
that
is
rather
old
and
I
was
presented
it
long
ago.
H
So
for
a
simple
load,
we
can
define
a
special
format
that
can
reduce
its
size
very
significantly,
and
we
can
also
define
the
special
format
from
the
type
of
load
with.
H
Is
it
contains
an
empty
no
data,
so
activity
file
provides
its
status
type
multiplication.
It
can
be
also
decreased
in
size
very,
very
significantly.
So
let's
please.
H
This
is
an
example
of
a
safer
load
format
that
can
have
a
special
format
if
the
current
disable
load
in
this
example
has
a
lens
of
48
bytes,
a
special
format,
only
eleven
lanes
in
points,
it's
exactly
the
same
semantics
and.
A
H
H
H
I
think
there
are
three
options.
First,
we
can
define
new
major,
like
version,
I
don't
think
where
it
is
good
or
bad,
but
it
will
clear
allow
to
negotiate
a
new
promotes
because
the
old
responders
will
be
returning
by
each
major
version.
H
We
can
define
new
type
of
initial
exchange,
for
example
all
type
assignment,
and,
of
course
all
the
respondents
will
return
the
english
syntax
that
will
allow
the
initiator
to
either
re-initiate
with
the
old
formats
or.
H
Either
we
can
include,
we
can
define
a
new
critical
payload
from
india.
I
can
say,
followed
by
balloons,
a
new
format
so
since
the
loads
are
passed
one
by
one
and
once
a
responder
encounters
a
critical
below
that
it
doesn't
understand,
it
will
return
and
support
a
critical
reload,
and
it
doesn't
mean
it
doesn't
matter
if
it
can't
pass
the
rest
of
the
message.
H
So
discussion
we
don't
need
to
assign
new
blood
types
except
for
special
format
to
say
we
can
reuse
the
existing
load
types
if
it
is
clearly
in
the
context
that
the
new
format
must
apply.
For
example,
if
my
question
is
changed
or
we
can
define
a
new
below
types,
if
it
will
exactly
for
the
for
existing
pillows,
it
was
just
duplicated
for
latch
below
transport.
Issues
are
out
of
scope
of
new
format,
and
it
is
assumed
that
tycho
tcp
will
be
used
in
combination
with
like
fermentation,
because
I
go.
H
H
In
draft
medicine,
because
your
search
effect
compressed
vector
defines
x,
509
certificates
in
sibo,
the
next,
please
so
comments.
This
is
just
as
I
said,
I
don't
have
drafting
and
I
just
want
to
to
gouge
if
there
is
any
interest
in
this
work
in
the
working
group.
C
D
Hi,
michael
richardson,
so
if
you're
doing
this
for
constrained
devices,
then
you
should
be
implementing
this
in
cbor.
D
Zebra
already
has
variable
length
integers,
including
down
to
one
byte,
including
the
code,
so
that
would
be
much
better
way
and
we
could
walk
through
the
two-spec
and
we
could
translate
it
to
cdl,
express
it
as
cbor,
and
I
would
say
that
probably
will
get
a
much
better
compression
there
and
a
much
higher
code
you
use
and
if
you're
going
to
compress
certificates
with
that
document,
then
you
need
to
see
board
anyway.
So
there
you
go.
D
D
At
this
point,
the
iot
space
is
not
using
ipsec
at
all,
despite
what
some
people
think-
and
I
would
really
need
want
to
see
some
real
non-research
applications
of
it
before
I
thought
this
working
group
should
spend
the
time
on
it.
Having
said
that,
I
really
think
iot
space
should
be
using
ipsec,
but
it's
not
so
I
don't
think
it's
worth
pursuing
at
this
point.
H
Well,
thank
you.
I
was
thinking
about
sibo
as
as
one
of
is
one
of
approaches,
but,
to
be
frank,
I'm
not
an
expert
in
as
far
as
as
I
understand
it
requires
allocation
of
tax
from
some
registry
from
possible
control
registry.
C
You
know
not
a
chair,
but
I
think
my
comments
on
this
is
that
I
think
I
think
there's
two
issues
here
and
I
think
we
should
keep
them
separate.
One
is
that
do
we
actually
want
to
raise
this
payload
size
limit
from
64
kilobytes
to
larger,
because
that's
completely
that's
not
something
that
they
are
going
to
be
used
in
iot
environments
in
compressed
formats.
If
you
are
going
to
be
having
sending
you
know,
64
kilobyte,
over
664
kilobyte
stuff,
you
are
not
concerned
about
couple
of
bits
in
the
you
know,
header
sure.
C
So
so
I
think
that
should
be
a
separate
issue
and
I
think
we
should
probably
leave
it
out
in
this
discussion
and
add
it
because
we
are
talking
about
more
or
less
actually
if
you
are
working
on
the
completely
new
payload
format-
10.
Yes,
we
want
to
think
about
that.
C
But
if
you
think
about
compressing
the
current
one
like
talk
about
seabor,
I
don't
think
we
actually
need
to
talk
about
that
and
there
I
was
thinking
about
more
or
less
that
what
most
of
these
things
that
you
actually
doing
are
this
kind
of
static
header
compression
stuff?
So
we
could
actually
one
of
the
way
of
looking
at
this
would
be
also
to
work
on
this
kind
of
we
have
an
eye
version,
two
packet
that
has
you
know
stuff
there.
Then
we
compress
it
down
to
something
that
is
you
know.
C
C
The
good
thing
is
that
we
can
actually
still
use
the
original
payloads
if
we
happen
to
have
suddenly
have
something
that
we
can't
compress,
because
somebody
actually
used
some
of
the
research
fields
so,
and
this
would
actually
be
the
same
kind
of
thing
that
converted
into
seaboard,
we
could
actually
have
you
know
ice
version,
two
payload
encode
that
as
a
c
board
and
set
it
out.
C
C
But
but
I
think
this
is
something
that
would
be
interesting
to
work
on,
and
at
least
they
yeah
okay.
So
there's
a
couple
of
comments
in
in
in
chat,
but
yeah.
C
H
So
yeah,
I
just
want
to
answer
well
what
you
described
it.
This
approach
was
used
in
direct
of
smith's
equity
compact.
It
was
just
a
generic
encoder
to
code,
a
prayer,
encoding,
post
prayer
decoding
and
post
encoding
that
just
converts
existing
critical
format
into
compact
form
and
vice
versa,
and
it's
it's
a
good
approach,
but
unfortunately
it
can
be.
You
can
use
if
you
want
to
lift
64
kilobytes
limit,
because
for
this
thing
you
must
redefine,
because
you
don't
have
an
existing
balloon.
H
Suggest
another
approach
when
a
sequence
of
payloads
with
a
size,
less
or
equal
than
64
kilobytes,
is
used
as
a
single
data
unit
for
this
type
of
payload
and
its
size
can
be
greater
than
64
kilobytes
in
this
case,
but
it's
a
last
itf.
H
You
have
suggested
that
probably
instead
of
these
approaches,
it
is
definitely
a
protocol
hack,
some
hack,
so
we
can
redefine
and
upload
vermont.
That's
why
this
presentation
appears
so
I'm
trying
to
to
go
which
whether
it
is
interesting
or
we
can
return
to
this
to
that
proposal,
because
it
is
still
valid
to.
C
C
If
we
are
doing
compression
of
existing
payload
stuff-
and
things
are
under
that,
then
we
can
do
it
here.
If
we
are,
you
know
using
reusing
the
existing
hypers
and
two
payloads
to
having
multiple
payloads
in
one
message.
That's
also
belongs
here
so,
but
I
think
we
are
running
out
of
the
time
very
soon,
so
we
actually
need
to
go
forward.
I
think
it
would
be
interesting
to
get
some
discussion
on
the
list
about
this.
E
E
So
this
slide
has
been
sort
of
a
drifting
in
between
what
to
do
and
fallen
in
administrative
cracks.
Basically,
I've
just
bumped
the
document
to
prevent
it
from
dying,
and
I
just
wanted
to
reiterate
that
the
only
thing
this
document
does
is
create-
and
I
think
it's
most
important
thing
create
ayana
status,
columns
for
all
the
iana
registries,
so
that
we
can
add
things
like
deprecated
there
with
the
link
to
the
rfc
and
then
formally
closes.
E
I
think,
even
if
we
decide
not
to
do
this
because
people
go
like
well,
we
are
not
the
internet
police
and
if
people
use
iqv1
then
go
ahead,
we
still
need
a
document,
to,
I
think,
add
the
ayanna
column
for
deprecated
to
some
of
these
things.
So
if
you're
having
that
document,
you
might
as
well
nudge
them
a
little
bit
further
from
from
not
using
ip1.
E
So
I've
now
bumped
this
twice.
So
I
think
you
know
you
should
really
move
on.
I
don't
think
there's
a
next
page
is
there
there
is
oh
yeah.
This
is
just
a
shaming
tarot
into
the
process,
so
so
nothing
has
happened.
We
should
just
either
adopt
this
or
kill
it,
but
then,
if
you
kill
it,
I'm
going
to
come
back
with
the
status
column
for
ayana
draft
document.
K
P
Okay,
can
you
hear
me?
P
Yes,
okay,
okay,
great,
my
name
is
dan
harkins,
so
I
actually
support
adopting
this,
but
I
think
there
we
should
do
some
changes
so
paul
thanks
for
doing
this.
First
of
all,
similar
to
what
tls
is
doing
deprecating
tls
1.0.
I
think
that
this
should
be
a
bcp,
not
standards
track,
and
also
you
know,
I
it
went
from
die,
die
die
to
graveyard,
but
you
know,
I
don't
think
we
need
these.
P
P
P
If
you
know
you
know
you
note
that
there
hasn't
been
any
work
on
ikv
one
for
over
a
decade
and
I'm
not
really,
and
if
this
does
go
to
historic,
I'm
not
really
sure
what
sort
of
subterfuge
could
could
happen
by
not
you
know
without
deprecating
these
these
registries,
but
the
reason
I'm
I'm
cautioning
on
this
is
because
other
other
organizations
are
using
at
least
one
part
of
the
ikv
one
registry,
and
I
think
you
know
before
we
just
go
deprecate
everything
I
think
it
should
be.
P
We
we
really
need
a
good
reason.
Why?
My
final
comment
is
you
mentioned
that
one
of
one
of
the
reasons
not
to
use
ike
v1
is
because
it
uses
quote
very
weak
groups,
two
and
five,
but
then
you
don't
go
and
deprecate
them
all.
You're
deprecating
is
1
and
22..
E
So
the
the
reason
they're
not
deprecated
here
is
that
we
have
another
cycle
of
documents
for
that,
so
we've
got
like
rc
a223
and
four
seven
that
are
specifically
about
espn,
algorithms
and
and
deprecating
those.
So
this
document
only
talks
about
the
things
that
are
not
talked
about
in
those
documents
and
there's
a
lot
of
may
algorithms
that
people
just
never
bothered
to
deprecate
that
this
document
sort
of
tried
to
pick
up
and
just
deprecate
as
well.
C
This
terror,
given
I'm
talking
now
as
an
I,
am
an
expert
for
I
person,
two
registries,
and
there
was
this
discussion
about
adding
this
status
column
to
the
iron
registry.
I
I
I'm
not
against
having
status
clone.
That
only
has
a
deprecated
and
not
its
tattoos.
I
I'm
against.
C
If
we
actually
want
to
have,
there
have
been
people
saying
that
we
should
have
an
should,
must,
and
that
should
be
that
kind
of
information
in
the
iron
registry,
and
I
don't
think
we
don't
want
to
doubt
that
adding
this
status
column
that
has
deprecated
is
okay.
For
me,
thai
question:
one
registries
are
already
closed.
Okay,
that
you
can't
actually
allocate
anything
that,
if
you
do,
I
think
the
ayana
should
be
complaining
about
that
anyway.
The
only
thing
that
is,
actually,
I
think
they
are-
we
are
just
moving
the
actually.
C
E
But
that
is
but
that's
a
very
informal
thing
of
the
ayana
registry
expert
aka
iu,
no.
C
C
C
It
doesn't
change
anything
from
them
point
of
view,
because
they
still
can't
be
doing
any
updates
with
them
and
they
haven't
been
able
to
do
any
updates
with
them
anyway,
since
the
last
time
uh.11
forced
us
to
update
things
there,
even
if
would
it
have
been
needed,
but
anyway.
B
C
Yeah,
so
I
think
that's
my
comments
for
this.
I
think
ben
is
next.
M
So
it's
not
really
clear
to
me
that
we
want
to
switch
to
doing
this
as
a
bcp
versus
a
different
way.
Dan
had
also
mentioned
that
we
could
move
the
old
documents
to
historic.
If
I
understood
correctly,
there's
something
about
historic
and
we
do
have
a
dedicated
mechanism
for
changing
the
status
of
documents,
including
moving
the
to
historic,
which
does
not
necessarily
involve
an
rfc
to
do
that.
There's
a
separate
class
of
status
change
document
and
there's
a
isg
statement
about
it
that
I
will
put
in
the
chat
after
I
stop
talking.
E
M
Yeah
exactly
and
then
the
other
point
dan
made
was
about
the
version.
One
registries
that
are
in
use
by
other
organizations-
and
I
have
in
my
local
notes,
that
the
ieee
is
using
them
and
I
have
a
to
do
item
to
send
a
or
to
have
us
send
a
liaison
statement
to
ieee
before
we
actually
make
any
new
actions
in
terms
of
closing
off
or
deprecating
those
registries.
Just
to
make
sure
that
everyone
is
aware
and
has
a
plan.
C
P
C
All
right
so
so
I
think,
but
I
think
we
are
still.
I
think
the
adopting
this
document
is
still
okay,
so
I
think
we
should
adopt
this
document
as
a
working
group
item
and
then
start
working
on
it
or
actually
finish
working
on
it.
I
don't
think
that's
actually
requires
that
much
work,
but
except
yeah
dan
has
some
comments.
C
So
if
you
actually
adopt
it
as
a
working
group
program
and
then
we
can
work
on
it
and-
and
I
would
actually
like
to
publish
it
out
and
if
anybody
has
any
comments
or
disagreements
or
adopting
this
or
making
starting
the
adaption
call,
please
say
now
something
or
sent
to
the
list,
but
I
will
start
an
adopting
call
for
this
after
this
idf.
C
O
Good
good,
okay,
so
we
have
this
draft
in
idr
for
the
sd1
h
discovery.
What
it
is
is
sd1
is
basically
adding
additional
bandwidth
to
the
existing
mpls
vpn
network,
so
the
provisioning
is
slightly
different
from
the
ipsec.
So
the
reason
for
us
to
come
to
here
to
ipsec
me
group
is
to
get
the
feedback
on
what
we
did,
what
we
are
doing
and
see
if
there's
any
problem
with
that,
and
because
our
next
step
is
for
working
group.
Last
call:
okay,
next
page,
please,
okay!
O
So
here
just
some
typical
comparison
with
the
traditional
ipsec
configuration
so
for
the
pgp
controlled
sd1.
So
we
have
the
mpos
vpn
already
existing
and
we're
adding
additional
episode
tunnels
between
the
two
edge
nodes
to
increase
the
bandwidth.
O
The
differences
be
to
the
traditional
ipsec
is
those
cpes
are
already
connected
to
the
controller,
which
is
the
route
reflect
rr
in
this
diagram
through
a
secure
channel.
So
the
authentication
is
already
down
because
they
have
to
control
other
configuration
for
the
cpe2
and
cpu
one
so
and
also
for
the
the
like.
We
called
the
ipsec.
We
call
traffic
selector
you
we
have
in
bgp.
We
have
route
target
with
broad
target.
O
You
can
import
a
particular
vif
or
export
vif,
and
so
that
your
your
routes
can
be
allowed
to
talk
or
not
allowed
to
talk
and
all
those
policies
are
implemented
through
the
client,
vrf,
and
so
with
this
you
can
scale
better
with
large
number
of
nodes.
So
so
this
is
just
the
compare
with
the
traditional
episode
next
page,
please.
O
So
here
we
put
a
table
here.
I
want
to
get
your
feedback.
The
highlight
yellow
means
the
bgp
controlled
sd1
for
the
ipsec
parameter,
exchange
can
be
optimized
in
the
bgp
control,
hdmi,
environment
and
the
gray
part
is
the
same
as
ipsec
traditional
configuration,
especially
for
the
the
authenticated
peers.
The
controller
actually
has
the
total
saying
a
total
control
on
which
node
can
this
particular
node
can
communicate
with,
and
the
communication
is
already
authenticated
and
for
the
remote
peer
address
configuration
that
is
also
controlled
by
the
route
reflector.
O
The
policy
is
in
the
controller
and
not
on
the
node
themselves,
the
the
grey
part,
the
ip
I
ik,
v2
proposal,
the
transform
set.
Those
are
the
same
even
with
bgp.
We
have
to
exchange
them
through
the
messaging
for
the
client
discovery.
The
prefix
discovery
like
when
you
have
multiple
client
prefix
attached
to
the
edge
node
in
the
ipsec.
You
run
routing
protocol
in
each
of
the
tunnels
in
bgp,
update
bg
update
itself
will
update
advertise
the
client
attached
to
the
particular
node
and
also
associate
tunnels.
O
So
here
the
last
one
is
the
access
list
or
traffic
control
traffic
selector
and
is
achieved
by
the
bgp
route
target,
import
and
export
raw
target.
Next
page,
please,
okay!
So
so
here's
just
explanation
on
how
does
client
traffic
are
exchanged?
So
in
bgp
we
have
those
recursive
update.
We
advertise
the
the
bgp
advertise.
The
client
route
like,
for
example,
10.1,
slash,
1624,
and
the
next
hop
is
the
node
which
is
cpe2,
and
then
it
can
have
the
extended
community
to
indicate.
O
This
is
a
hybrid
tunnel
which
includes
mpos
tunnel
and
the
ipsec
tunnel,
and
we
use
color
to
coordinate
with
the
update
2.,
so
update.
2
is
more
about
infrastructure
information
so
that
this
will
describe
in
detail
of
the
like
episode
parameters
or
the
vpn
mpos
parameters,
and
also
indicate
for
specific
ipsec.
O
Like
inner
encapsulation,
whether
gi
or
other
other
form
of
inner
encapsulation,
so
with
this,
the
client
update
is
separated
from
the
ipsec
itself,
make
it
more
flexible
and
make
it
scale
better
next
page,
please
so
so
for
the
bgp
update,
you
can
include
the
ipsec
attributes
or
you
can
be,
have
a
pre-established
security
association
with
the
identifier.
O
So
for
the
underlay
tunnel
advertisement
we
can
include
the
ipsec
sa
identifier
and
together
with
the
inner
encapsulation
next
page,
please-
and
you
can
also
give
this
specific
episode
subtlyovs,
which
indicate
all
the
key
information,
the
nouns
the
transform
set
next
page.
O
So
I
sent
the
email
to
the
episode
me
a
few
weeks
ago
asking
for
feedback.
I
got
some
people
coming
back
with
questions,
so
I
just
want
to
take
this
opportunity
to
get
feedback
see
if
there's
any
major
flaw
we're
doing
in
bgp
and
if
not
that
would
be
great,
then
we
will
go
for
working
group
adoption
in
idea.
B
C
Q
Yeah
hi
everybody.
Can
you
hear
me?
Q
Okay,
great
yeah.
This
is
leonie
brockett
from
zakunet
I'd
like
to
raise
the
topic
of
alternative
signatures
in
ikv2
next
slide.
Please.
Q
So
the
iso
x509
standard
defines
three
extensions:
subject:
alt
public
key
info,
alt
signature,
algorithm
and
alt
signature
value
they
allow
for
for
introduction
of
an
alternative
algorithm
into
certificates,
and
they,
if,
if
this
extension
is
present
and
the
application
are
upgraded,
the
alternative
algorithm
is
is
used
instead
of
the
native
fields.
Q
So,
if
you
think
of
post-quantum
cryptography,
so
you
choose
a
post-quantum
signature
scheme
as
an
alternative
algorithm.
Then
this
would
mean
that
only
the
post-quantum
signature
will
be
verified.
Q
So
pc
is
not
not
fully
trusted
at
the
moment.
Standardization
will
take
some
time
so
it
may
be.
It
may
be
a
good
idea
to
use
a
hybrid
mode,
so
yeah.
Of
course,
this
alternative
extension
allows
for
a
smooth
migration
from
one
algorithm
to
another
and
is
not
limited
to
post-quantum
cryptography
but
yeah
in
case
you
want
to
use
post-quantum
cryptography
early.
It
may
be
a
good
idea
to
use
yeah
a
hybrid
solution
such
as
it's
done
with
the
hybrid
key
exchange
yeah.
Q
So
the
first
question
to
the
working
group
is:
has
anyone
already
thought
about
how
this
alternative
signature
extension
can
be
integrated
in
ike?
Q
And
the
second
question
is
yeah,
I
know
some
people
that
would
prefer
a
hybrid
solution.
So
I'd
like
to
hear
your
feedback.
Do
you
think
that
we
need
a
hybrid
solution
for
signatures.
C
All
right,
so
I
think
we
are
now
so
much
out
of
time
that
I
don't
think
we
actually
want
to
cut
the
comments
on
here.
I
think
we
want
to
discuss
this
in
lamps
or
or
some
other
working
group,
because
I
don't
think
it's
actually
it's
related
to.
We
actually
just
use
the
certificate,
as
x5.9
gives
them
us
to
us
or
pickix
or
whatever.
M
Jumping
in
as
the
area
director
there's
been
some
discussion
already
in
the
lamps
working
group
about
post
quantum
crypto
and
the
potential
for
doing
hybrid
and
what
the
hybrid
would
actually
look
like.
So
I
think
that
may
be
best
to
try
and
consolidate
the
itf
discussions
of
that
in
lamps,
and
that
would
also
give
the
opportunity
to
sort
of
align
what
we
do
for
x,
509
and
pkix
in
general
in
the
itf,
because
I
think,
as
you
note,
there
is
some
stuff
in
the
iso
x509.
M
C
All
right,
so
there
is
a
couple
of
comments
in
the
jabber
about
this,
but
I
think
we'll
skip
them
now
and
go
to
the
next
presentation.
This
is
paul.
Look
at
the
five
minutes
for
your
two
five-minute
sessions,
so
try
to
compress
them
in
two
and
a
half
minutes
each.
E
Okay,
test:
okay,
so
there
was
a
draft
a
couple
years
ago
about
simplifying
the
re-key
process
by
leaving
out
all
the
things
that
we
don't
need
because
they
are
staying
the
same
anyway.
So
this
draft
originally
didn't
see
much
adoption,
because
there
was
some
ipr
confusion
that
has
been
resolved
now.
E
So
there's
no
no
problems
with
ipr
and
I
think
it's
a
good
good
drive
to
have
it
will
also
valerie
will
be
happy
to
know
greatly
reduce
the
number
of
bytes
and
during
reiki,
because
you're
basically
skipping
the
entire
sa
payload,
all
the
algorithm
negotiation
parts.
They're,
all
you
don't
send
them.
You
just
send
a
new
notify,
saying
yeah
same
as
before:
here's
the
new
spy,
here's,
the
old
spy
continue.
So
next
page.
E
So
the
way
they
do
it
is
they
they
send
a
new
notify,
a
minimal
reiki
support
it,
and
then
during
the
re-key
you
can
omit
the
sa
and
or
ts
payloads
and
then
send
a
unchanged
message
with
the
spy
and
everything
else
is
the
same
as
before,
and
then
next
slide
and
the
changes.
I
think
that
are
still
needed
for
this
document.
It
says
that
you're
you
could
change
your
algorithms,
which
I
don't
think
is
allowed.
So
I
don't.
I
don't
think
we
should
have
that
text
and
there's
some
text.
E
That
said
what
to
deal
with,
if
your
acls
change
to
sort
of
fall
back
to
the
old
system,
but
I
think
that
should
be
simplified
by
well.
If
your
configuration
changed
and
you
reloaded
from
disk,
you
should
just
delete
all
your
items.
All
your
essays
and
start
from
scratch
like
we
normally
do,
and
I
think
for
the
the
sats
unchanged
payloads
is
where
you
basically
do
a
child
re-key.
E
I
think
we
also
need
to
send
the
old
spy
which
is
currently
doesn't
do,
because
if
we
have
multiple
traffic
selectors,
multiple
child
assays,
with
the
exact
same
traffic
selectors,
we
really
want
to
tell
them
which
one
we
are
replacing
with
this
wiki.
And
otherwise
we
don't
know
because
normally
that
spy
is
present
in
the
sa
payload,
but
we're
not
sending
that
now
and
I
think
we
should
clarify
a
bit
more-
the
bfs
and
the
ke
payload.
So
that's
initial
overview.
Nichelle.
E
E
E
E
So
the
changes
we
made
the
numcus
now
only
has
one
value.
We
found
that
negotiating
minimum
maximum
leads
to
too
many
corner
cases
where,
where
things
get
confusing,
so
we
just
take
one
number
of
the
the
preferred
number
and
people
can
take
the
the
largest
of
the
two.
If
it's
not
insane
and
outside
of
their,
you
know,
ddos
protection
things.
E
We
also
added
a
significant
possibility
for
the
cpu
identifier.
Initially,
we
didn't
have
them,
but
our
experience
has
shown
that
if
you
start
re-keying
things,
it's
really
useful
to
know
which
one
goes
where
or
what
what,
where
it
relates
to,
so
that
you
can
better
match
the
match,
then,
and
we
did
a
bunch
of
readability,
improvements,
some
language
changing.
So
again,
we
would
like
people
to
read
it
and
give
us
feedback
and
run
our
code,
and
then
maybe
we
will
all
get
consensus.
E
Oh
okay!
I
I
that's
basically
it
like
that.
Actually
one
thing:
if
you
go
one
slide
back
sorry,
there's
one
important
thing
I
want
to
mention.
The
problem
is
that
the
rss
on
network
cards
for
esp
is
rarely
supported,
and
so
we're
kind
of
stuck
with.
If
we
want
to
do
this
properly,
we
would
really
need
to
use
encapsulation
like
udp
encapsulation.
E
Usually
the
problem
is
if
we
have
multiple
one
of
them
currently
the
protocol
maps
this
all
to
a
single
port,
and
we
really
would
like
some
way
where
we
can
map
them
onto
different
ports
so
that
they
can
actually
use
the
rsr
rss
mechanism
of
the
nic
cards
and
it's
currently
not
possible
on
ike,
and
so
we
would
really
like
some
more
people.
Thinking
about
this
problem.
B
C
C
In
the
list
so
but
yes
people
would,
I
would
hope,
hope
people
would
actually
review
this
document
and
you
can
probably
send
a
name
reminder
to
the
list
and
ask
for
reviews
and
so
on,
but
I
think
that's
actually.
We
are
running
out
of
time
now.
This
was
the
final
thing
and
I
don't
think
we
have
a
time
for
open
discussion
anymore,
because
we
used
most
of
that
during
the
earlier
times.
C
So
and
we
know
we
don't
allow
any
puppies,
so
I
think
that's
it.
Unless
somebody
has
some
really
really
important
things
before
we
close
up.
C
Okay,
I
I
don't
hear
anything
so
I
hope
we
are
going
to
be
seeing
people
interacting
in
the
list
and
try
to
get.
You
know
things
going
forward.
C
In
my
to-do,
like
list,
I
have
an
starting
working
group
last
call
for
lab
labeled
ap.
I
question
two:
do
some
reviews
on
eye
question
two
make
a
working
group
other
ups
and
call
for
meep
document
and
grade
your
document,
and
I
think
that's
what
I
was
I'm
planning
to
do
after
this
meeting
closes.