►
From YouTube: IETF104-OPSEC-20190325-1120
Description
OPSEC meeting session at IETF104
2019/03/25 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
B
B
So
yeah,
so
we
studied
this
in
September
2012
right,
it's
a
long
long
one.
It
has
been
hearing
the
queue
for
many
years
of
usually
governors
feedbacks
and
at
some
point
of
time
we
need
to
go
once
on
the
working
class
goal.
We
failed
and
basically
my
ass
for
today
will
be.
Can
we
get
another
in
group?
Last
call.
B
And,
as
you
know,
that's
of
course,
of
operational
security
consideration.
So
it's
not
recommendation
right.
It's
very
important,
the
difference
here,
so
the
main
change
since
the
last
one
we
are
currently
at
15
compared
to
the
14
as
we
do
it
every
six
months.
We
need
to
refresh
the
references.
They
are
a
couple
of
document
that
we're
base
that
they
know
an
RFC.
So
we
need
to
change
this
also
stating
to
the
introduction
that
we
do
not
cover
the
IOT
world.
So
we
say
recover
is
be
residential
and
enterprise.
B
They
were,
then,
we
were
shortening
shortening
and
now
what
we
simply
say
please
go,
and
this
draft
go
to
the
ula
usage
consideration
and
two
lines
before
to
explain
what
ula
is
because
it's
document
is
assumed
to
be
readable
by
anybody,
even
unhappy
v6
expert,
so
more
security
guy
that
come
to
understand
implicational
v6.
So
we
say
what
ula
is:
please
go
there,
so
if
somebody
still
find
this
small
section,
controversion
I
would
love
to
know.
Yes,
yes,.
D
B
Somebody
suggested
into
a
review
that
we
also
put
the
Vasavi
logging.
So
that's,
basically
you
remember
to
get
the
mapping
between
the
v6
address
and
the
MAC
address.
Basically
for
user
tribution
there
we
recommend
to
do
well
severe
again,
if
is
possible.
Sorry
is
the
technique
that
allows
you
to
keep
the
mapping
there
and
basically,
I
am
already
on
my
last
slide
right
wrong.
You
said
it
was
a
fast
meeting.
It
will
be
near
the
first
meeting.
We
want
to
go
on
the
last
week,
a
group
class
goal
I
think
now
the
document
is
ready.
B
A
One
Bonica
speaking
as
an
individual
contributor,
since
we
have
a
bunch
of
time
in
the
session
I'd
like
to
bring
up
a
couple
of
the
issues
on
from
the
document
sure
the
first
is.
The
very
first
section
recommends
that
everybody
used
P
I
space
for
security
reasons.
The
first
question
is:
do
we
really
want
to
do
that
and
risk
exploding
routing
tables?
A
B
Well,
does
it
say
so:
I
had
a
hard
time:
okay,
nobody!
We
do
not
cease
consideration,
so
if
we
still
somewhere
recommend
something,
then
we
are
wrong
because
we
need
to
do
consideration
right
the
title,
the
document,
so
we
may
want
to
change
this
text
there,
but
I
still
believe
that,
for
an
enterprise
getting
P
is
pace
is
much
better
because
you
are
independent
of
your
service
provider.
Well,
that
I
think
it's
obvious
right.
All
of
us
in
the
room.
C
B
A
We
need
fresh
air,
so
thank
you,
generalizing.
That
comment
to
other
sections.
There
are
other
places
where
you
talk
about
an
idiosyncrasy
of
ipv6
and
you
talk
about
a
consideration,
but
it
never
really
shows
up
as
a
good
security
consideration.
It's
just
an
idiosyncrasy.
For
instance,
you
mentioned
when
you're
discussing
extension
headers,
you
mentioned
many
networks
drop
packets,
whether
it's
extension
headers.
Well,
yes,
that.
C
E
A
B
Again
and
then
it's
easier
to
remove
tags
and
edits
I
still
until
now,
maybe-
and
the
last
point-
we
really
really
would
love
to
get
reviews
of
this.
All
right,
so
I
will
apply
the
to
change.
Recommend
it
today
is
your
dash
16,
and
then
we
send
to
the
list
and
get
to
review.
That's
what
do
you
need
them.
F
Nathan
ripens,
you
see
I've
been
following
the
work
for
years
and
also
the
latest
one
I
think
it's
great
work.
I
would
like
to
take
in
the
comment
about
PII
that
should
not
be
distinguished
from
pa
since
we're
and
also
Jen's
comment
about
the
RFC
1918
addresses
I,
think
that
should
be
revised
as
well
other
than
that
I'm
perfectly
happy
move
forward.
Ok,.
G
So
the
comments
about
P
I
in
the
comments
about
extension
has
maybe
maybe
those
things
are
more
about
risk
management
and
security.
Maybe
it's
still
worth
capturing
things
that
are,
you
should
document
as
risks
and
your
action
against
that.
So
you
may
well
decide
that
you
want
to
you've
identified
a
risk
that
your
provider,
you
may
need
to
change
provider
or
they
may
go
out
of
business
and
God
knows
what
happens.
G
Then
you
identify
that
as
a
risk,
and
maybe
your
mitigation
is
to
deploy
PI,
it's
not
necessarily
security,
but
it's
risk
management
which
many
people
do
equate,
unfortunately
to
security.
So
maybe
there
is
scope
to
either
put
that
in
another
document
and
just
shorten
this
one.
So
you
can
get
consensus
by
making
it
less
things
for
people
to
read-
or
maybe
it's
an
appendix
or
a
section
at
the
end,
that's
risk
rather
than
security.
It's
a
good
suggestions
is
also
a
PVC.
G
Author
is
there
right,
yeah,
so
there's
faith,
so
somebody
mentioned
the
issue
you
LA's
and
I
think
it
came
up
there
and
we
eventually
tried
to
shorten
the
text.
We
were
saying
I
think
we
ended
up
referring
to
this
internet
draft
that
no
doubt
will
never
be
finished,
the
ula
recommendations
or
considerations
draft.
This
that's
been
going
for
about
five
years
and
it'll.
G
B
H
G
G
G
B
I
I
I
So,
regarding
your
document,
I'll
be
happy
to
read
and
offer
comments,
so
the
draft
that
I
want
to
very
briefly
talk
about
is
not
a
presentation.
Just
a
commenter
two
requests
going
to
working
group
last
call
so
that
that
the
draft
is
titled,
enhanced
physical
path,
unicast,
reverse
path
filtering.
We
presented
it
a
couple
of
times
in
in
this
working
group
and
in
April
of
last
year
there
was
good
discussion
on
the
list
when
we
requested
an
adoption
call.
So
there
was
a
lot
of
good
back
that
was
offered.
I
We
factored
in
all
the
feedback
and
updated
the
draft
in
October
of
last
year
and
more
recently,
jeff
has
myself
and
that
Montgomery
we
took
a
close
look
at
it
and
we
discussed
it
between
ourselves.
We
are
satisfied
that
the
draft
is
in
a
is
in
a
good
shape
to
request
a
working
group
last
call
at
this
time.
So
we
would
like
to
request
that.