►
From YouTube: IETF115-MADINAS-20221110-1700
Description
MADINAS meeting session at IETF115
2022/11/10 1700
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
C
B
C
B
Some
Theory,
okay,
so
not
well
as
usual.
This
is
an
ITF
meeting,
so
we
have
to
respect
the
the
procedures
and
policies
of
ITF.
So
by
participating
to
this
group,
you
agree
to
these
processes
and
policies
and
if
you
are
aware
of
any
contribution
that
is
covered
by
patterns
or
patent
applications,
please
let
us
know
and
mention
it.
B
You
acknowledge
that
the
information
here,
written
audio,
video
and
photographic
will
be
made
public
and
personal
information
that
you
provide
to
the
aetf
will
be
handled
in
accordance
to
the
Privacy
statement,
and
also
you
agree
that
you
will
work
respectfully
and
you
will
treat
likewise
to
other
participants.
If
you
have
any
issues,
please
contact
the
ombudsman
and
you
have
here
the
pcps
for
all
extra
information
that
you
require.
B
So
please
use
a
QR
code
or
log
into
the
meter
code
to
capture
your
record,
your
participation
with
data
tracker,
and
we
will
use
data
tracker
to
to
manage
the
queue
it's
really
useful
for
us
to
to
make
sure
people
remote
also
understand
who
is
talking.
Please
keep
your
audio
and
video
off
and
wear
masks
and
that's
it.
B
B
B
B
E
All
right,
thank
you
and
welcome
everyone
to
this
call
sorry
I'm
not
on
site
with
you.
So
let's
go
to
I
mean
this
document.
We've
been
discussing
it
a
lot,
so
you
know
you
probably
are
all
aware
of
of
what
it
says
and
what
it
contains.
But
as
there
were
some
interesting
conversations
during
the
on
the
list,
I
would
like
to
to
reassess
where
we
are
and,
of
course
ask
for
for
the
group
inputs
on
on
where
we
go
next,
can
you
go
the
next
slide?
E
I
don't
seem
to
have
control
over
the
slides.
Thank
you.
So,
as
you
remember,
we
have
two
documents
in
Flight,
we'll
talk
about
the
other
one
in
a
few
minutes,
but
this
one
is
what
we
call
We
call.
We
used
to
call
it
the
use
the
framework,
and
now
we
call
it
the
use
case
and,
and
the
goal
of
this
document
is
to
try
to
better
refine.
E
You
know
our
definition
of
what
a
problem
space
lies
and
for
that
we
found
you
know
two
years
ago
that
we
we
couldn't
agree
on
some
basic
vocabulary,
definitions.
So
what
this
document
does
in
the
use
case
is
start
by
defining
some
terminology.
You
know
when
we
say
you
know
they
can
inspire
you
with
your
Mac
address.
Who
is
they
so
in
this
document?
You
go
through
the
different
actors
that
are
involved
in
at
least
to
wireless
network
action
and
monitoring.
E
Then,
of
course
we
look
at
the
technical
entities.
You
know
the
switches,
rebounder
the
services,
the
dhcpe
or
DNS
all
these
things,
but
also
the
human
entities.
People
who
are
you
know,
spying
on
you.
You
know
the
eavesdroppers,
but
also
people
who
administer
the
network
or
administer
the
services
of
the
network
and
give
you
access
to
the
internet
and
people,
of
course,
on
the
internet.
E
And
of
course,
we
also
Define
some
environments,
because
it's
clear
that,
although
we
shouldn't
trust
anybody
anywhere
sad
world-
and
there
are
some
places
where
the
level
of
Trust
might
be
slightly
different.
For
example,
if
you
are
in
a
public
venue
like
you,
are
here
I'm
expecting
that
the
trust
you
have
that
you
can
send
your
unencrypted
credit
card
out
over
the
years
very
limited.
E
However,
if
you
move
to
an
MDM
control
device
in
a
factory,
the
level
of
trust
that
you
have
in
the
network
in
the
environment
and
the
network
actors,
whether
they
are
is
likely
to
be
higher
simply
because
you
know
there
is
no
likely
pii
on
your
device
and
also
the
environment
might
be
controlled.
So
we
Define
these
different
environments
and,
of
course,
we
Define
this
different
level
of
trusts.
E
So
that's
the
general
structure
of
the
document.
As
you
you
may
remember,
we
went
back
and
forth
on
on
the
early
definitions
of
this
documents
and
we
spend
a
lot
of
work
and
there
you
know,
together
as
a
group,
to
try
to
Define
exactly
the
scope
of
that
document.
So
that's
getting
to
a
point
of
Fairly
good
stability,
then,
as
we
form
the
the
WG,
we
had
a
few
edits
on
these
documents
and
you
see
here
a
list.
E
The
latest
update
is
what
we
have
now,
as
b
as
V3,
which
occurs
between
our
last
inter
meeting
call,
and
this
meeting
where
we
had
two
types
of
edits.
One
is
a
typo
fixing
and
I
received
typos
and
I
heard
from
some
of
you
that
were
still
typos
I'm
expecting
there
is
still
typos,
so
please
mention
them.
If
you
tell
me
there
are
typos,
it's
not
useful.
E
Tell
me
where
you
see
a
typo,
so
I
can
correct
it
I'm
sure
there
are
still
a
few
of
them,
but
the
other
thing
we
did
also
was
that
in
V2
in
the
last
section
of
this
argument,
which
is
section
seven,
we
started
listing
what
we
call
solutions
that
were
already
existing
I,
think
we
mentioned,
among
others,
wp2
up
and
looming,
and
a
few
more
in
this
V3
I
received
comments.
Offline
of
people
say:
oh,
you
should
also
mention
this.
There
is
also
that
solution
and
so
on
and
I
Incorporated
those.
E
However,
one
big
mishap
I
did
and
I
like
to
apologize
to
the
group,
for
that
is
that
I
received
those
comments
and
I
made
the
integration
and
posted
a
new
revision
where
it's
not
what
I
should
have
done.
I
should
have
you
know,
at
least
you
know,
pull
the
branch
from
GitHub
and
you
know
communicate
it
back
to
at
least
a
suggestion
for,
for
where
you
know
the
changes
should
be
so
you
know,
I
I
intend
to
fix
that,
and
in
fact,
thankfully
there
were
some
some
dialogues
following
this.
E
This
update,
which
is,
is
going
to
help.
You
know
fix
that
at
this
point
in
this
V3
of
this
document
it
seems
that
you
know
the
goal
is
to
look
at
the
use
cases,
so
that
section
in
section
seven,
where
we
look
at
Solutions
might
not
be
the
element
that
is
entirely
needed.
Anymore.
I
mean
it
may
be
very
useful
for
another
document,
but
if
we
are
focusing
in
these
documents
in
the
use
to
the
use
cases,
this
is
not
use
case.
It's
a
solution.
E
So
maybe
that
section
doesn't
belong
to
these
documents.
However-
and
some
of
you
have
been
Michael
in
particular,
have
been
suggesting
that
we
should
probably
add
to
our
group
task
the
creation
of
a
third
document
which
could
be
something
like
a
BCP.
In
that
case,
you
know
that
document
would
be
examining.
You
know
the
possible
solutions,
and
maybe
that
section
7
would
fit
better
in
that
new
document
than
it
is
in
this
document.
E
So
one
possibility
you
know
to
fix
the
addition
that
I
did
without
getting
the
full
feedback
from
the
group
is
to
move
those
additions,
in
fact
the
entire
section,
seven
on
Solutions
into
a
form
of
NX.
So
we
can
store
that
section
there
until
the
group
you
know-
maybe
today-
or
maybe
you
know
in
in
the
in
in
on
the
mailer
or
maybe
on
next
meeting-
decides
if
we
create
BCP
and
if
that
material
can
be
useful
for
that
BCP
I
think
it
would
be.
E
You
know
ways
to
destroy
it,
but
you
know
at
least
storage,
maybe
in
an
X
also
feedback
I
got
a
lot
about,
is
about
the
section
6.3
I'm
not
going
to
flash
it
here,
but
you
may
remember.
This
is
what
we
call
the
requirements
formulation
and
what
this
is
is
a
list
of
elements
that
we
think
are
useful
for
the
group
to
continue
with
its
activity
and
what
happened
there
is
that
if
this
was
useful
when
we
were
creating
these
documents,
but
at
this
point
sorry
this
is
a
working
group.
E
But
at
this
point
the
group
is
created,
so
it
seems
that
this
section
6.3
has
fulfilled
its
goal
and
it's
not
really
useful
in
the
context
of
the
use
case
document
anymore.
So
my
proposal
would
also
be
to
delete
that
section
6.3,
which
is
not
necessary.
So
those
are
the
two
main
things
that
I
would
like
to
offer
to
the
group
for
for
feedback.
Of
course,
you
know
I
can
always
undo
the
type
of
fixing,
but
you
know
I
think
this
is
Trivial
thing
that
we
want
to
do
anyway.
So
let
me
pause
there.
A
Probably
not
don't
that's
my
first
comment
and
then
second
comment
is
on
the
on
the
actual
use
cases.
The
document
is
called
use
cases.
Well,
it's
not
called
use
question
requirements
currently
I
think
we
should
probably
change
in
the
the
name.
If
we
keep
the
requirements
to
reflect
that,
that
will
be
the
second
command
and
then
there
is
a
third
one.
There
is
as
currently.
A
Basically,
explaining
the
document,
although
there
are
use
cases,
there
is
a
maybe
a
bit
higher
at
the
first
read
to
find
the
use
cases,
because
we
are
talking
about
the
trans
relationships
and
the
network
environment,
so
not
really
in
the
shape
of
classical
use.
Cases
maybe
like
in
the
WBA
document,
is
explained
so
I,
don't
know
that
that
may
be
worth
trying
to
do
a
bit
of
rewriting
to
to
make
the
content
more
use.
Cases
I
like
that
will
be
my
my
third
comment.
E
A
E
A
Think
that
that's
a
personal
comment,
so
I
mean
you
may
disagree
and
the
working
group
May
disagree,
but
I
I
think
I
was
expecting
more
like
use
cases
section
or
something
that
is
like
use
case,
a
b
c
and
d,
and
we
don't
have
that
in
the
document
percent.
Now
we
have
like
the
trust
levels
and
then
we
have
the
the
different
environments.
The
environments
at
the
end
of
the
day
is
kind
of
the
the
use
cases
referring
to
the
to
the
trust
levels.
A
F
G
Can
you
hear
me
now,
yes
yeah,
so
my
question
is
I.
Think
from
the
BCP
I
think
I
try
to
follow
up
with
Carlos
comments
so
for
the
vcp
document,
are
we
going
to
I
mean?
Are
we
going
to
address
per
environment
or
you
try
to
address
it
per
usual,
a
use
case
because
I
think
like
what
Kyle
says
like
the
current
draft
it
it
doesn't
contain
a
concrete
use
cases.
So
I
just
want
to
hear
from
you
like
what
you
propose
for
the
PCP.
Thank
you.
A
So
I
mean
my
my
comment
was
regarding
the
the
use
cases.
I
think
that
we
need
to
describe
a
bit
more
into
use
cases,
format,
kind
of
the
use
cases.
So
it's
a
bit
about
restructuring
a
bit
the
content
that
we
have.
So
this
is
kind
of
independent
on
the
on
the
BCP.
So
the
BCP
I
think
is
more
related
to
the
solution.
A
G
A
Well,
that
that's
up
for
the
working
group
to
discuss,
because
sometimes
also
the
vcp
is
more
related
to
how
to
address
the
requirements
right,
not
necessarily
the
use
cases.
So
the
structure-
I,
don't
have
a
strong
opinion.
I
will
probably
start
from
the
requirements
and
then
how
to
address
the
requirements
with
the
PCP,
but
I
guess
there
may
be
other
ways
of
doing
it.
G
Okay,
okay,
I
think,
okay,
I
think
I
got
you
so
in
this
case
you.
So
what
we
need
to
do
here,
I
think
for
the
use
case,
we'll
have
to
know
explicitly
either
like
doing
a
use
case
or
requirements.
So
that
then,
because
I
think
in
the
end,
I
want
to
make
sure
that
the
PCP
addressed
something
that
we
really
are
clear.
What
the
problems
we
try
to
solve.
B
I'm,
putting
myself
in
the
queue
and
yeah
I
think
just
just
to
add
a
couple
of
comments.
I
I
agree,
and
just
at
least
in
my
mind
that
the
structure
would
be
we
need
to
identify
the
the
set
of
use
cases.
What
are
the
requirements
for
each
one
of
these
use
cases?
Then
we
need
to
identify
what
existing
solutions
they
are
and
we
we
provide.
B
What
are
the
the
best
common
practices
regarding
the
solutions,
because
we
don't
know
if
these
Solutions
are
being
implemented
or
not
or
if,
if
there
is
no
issue
to
solve
or
if
there
is
a
gap,
so
that
that
is
basically
the
outcome
that
the
BCP
will
provide.
This
is
the
best
common
practice
that
you
should.
B
There
is
a
solution
you
should
use
it
or
we
may
find
out
that
there
is
a
gap
holding
one
of
the
use
cases
for
One
requirement,
in
which
case
we
will
figure
out
what
to
do
if
we
need
to
talk
to
other
organizations
other
working
groups,
if
we
need
to
recharger
Etc,
but
that
we
won't
not
know
until
we
have
identified
the
use
cases
and
the
requirements
so
so
again,
PCP
is,
is
what
it
says.
Best
common
practices
on
on
existing
Solutions.
A
Okay,
so
this
is
Carlos
bernardo's,
representing
the
draft
on
behalf
of
my
course
so
next
slide,
please
so
there's
a
brief
introduction
of
what
this
document
is
about.
This
document
is
about
documenting
the
State
of
Affairs
regarding
the
the
mark,
average
randomization,
the
RCM
in
ITF
and
other
sdos,
and
also
including
what
vendors
mobile
OS
vendors
are
are
doing.
A
A
So
there
were
a
couple
of
more
than
a
couple
of
pull
requests
from
Michael
regarding
the
thing
is
that
we
should-
or
we
could
do
in
the
in
the
document-
and
we
discussed
that
in
the
in
the
last
meeting
about
that
taxonomy.
We
discussed
that
that
was
a
good
idea
to
encode
in
the
document,
although
we
need
to
really
check
what
we
are
putting
there
to
avoid
any
anxiety.
So
at
this
point
in
time,
I,
basically
added
the
content
provided
by
Michael
thanks
again
Michael
for
playing
that
and
I
would
like
to.
A
A
So
this
is
a
summary
of
the
taxonomy.
So
basically,
it's
about
the
different
policies
that
maybe
follow
for
card
reselection
and
there
are
like
five
different
approaches
or
categories
there,
the
classical
one
that
is
the
per
vendor
of
UE
Mac
address,
so
the
Legacy
or
the
the
one
that
we
will
have
in
in
most
of
the
devices
up
to
the
recent
past.
That
is,
the
device,
has
a
pre-burn
MAC
address
there,
and
this
is
the
one
that
is
used,
and
then
we
have
a
set
of
different
approaches
per
device
generated,
Mac
addresses.
A
So
basically,
this
is
randomly
generated
by
the
device
and
is
done
at
the
beginning
of
the
lifetime
of
the
device
and
then
is
used
for
the
rest
of
the
operational
lifetime
of
that
device.
That's
a
possible
approach.
We
need
to
really
recommend
it.
When
this
may
make
sense
and
and
possible
issues,
then
we
have
the
purple
generated
Mac
address
in
this
case.
This
address
is
generated
per
Boot
and
it's
not
a
store
in
any
permanent
storage.
So
this
basically
means
that
that
address
will
change
on
a
per
boot
basis.
A
Then
we
have
the
one
that
is
more
typically
used
now
for
by
mobile
OSS.
That
is,
the
pernet
originated
Mac
address,
so
basically,
you
generate
and
use
on
a
per
Network
basis.
This
randomly
generated
address
and
typically
indexed
by
SSID.
So
that's
what
I
mean
by
per
Network
basis
and
then
the
purpose
you
generated
Mac
address
that
is
basically
a
way
of
rotating
the
address.
So
the
mobile
OSS
use
a
kind
of
a
combination
depending
on
the
OS
on
the
last
two
policies,
the
per
Network
generated
and
the
generated
marketers.
A
A
And
this
is
just
a
summary
of
changes,
so
in
the
last
two
revisions,
which
are
the
ones
that
took
place
between
last
ATF
and
this
ITF.
Basically,
we
added
a
section
on
taxonomy.
We
removed
some
BCP
14
terminology
that
we
have
or
text
that
we
have
in
the
Dera,
but
didn't
apply,
and-
and
we
also
added
some
other
minor
things
that
were
submitted
by
by
means
of
guitar
requests,
put
requests
from
from
Michael.
So,
basically,
those
are
the
main
changes,
and
this
is
it
thanks.
Thank.
D
Fers
are
getting
shorter
and
shorter
Michael
Richardson,
so
I
just
wanted
to
thank
you
for
accepting
it
I'm
going
to
try
to
point
out
to
the
group
that
some
of
those
policies
are
stupid
policies
and
part
of
the
point
of
of
naming
them
is
so
that
you
can
say
that
device
has
a
stupid
policy
and
whatever
and
the
vendor
could
say.
Oh
yeah,
that's
what
policy
we're
doing?
D
Oh
until
you
get
three
of
them
on
your
network
and
then
your
network
melts.
So
it
could
very
well
be
that
there's
a
policy,
that's
not
in
this
list
and
I
guess,
let's
say
per
Network
generate
Mac
address.
That's
what
all
the
mobile
devices
did
five
years
ago,
suddenly
right
and
and
then
Apple
and
others
have
have
moved
to
the
generating
a
new
one,
every
12
hours
or
something
like
that
and
that
I
guess
it
just
falls
down
on
its
own
and
I.
A
I
think
that
what
the
mobile
OSS
are
doing
today
is
more
a
combination
of
the
two.
Let
the
last
policies
right,
because
it's
rotating
the
MAC
address,
but
it's
doing
on
a
pair
SSID
basis.
So
maybe
I
don't
know
if
we
should
I,
don't
know
if
generate
a
new
policy
or
comment,
but
I
think
it's
a
combination
of
both
right.
D
Right,
it
could
be,
as
my
understanding
is
from
the
settings
I've
seen
and
things,
and
what
Dave,
Taylor
and
we've
discussed
in
previous
meetings
is
that
in
most
cases
you
either
tell
the
device
use
them
a
permanent
address
that
I
told
you
that
you
had
use
the
address
the
same
one.
You
had
last
time,
which
is
per
Network
generated,
Mac
address
or
randomly
change
it
periodically
and
as
far
as
I
know,
the
randomly
change
it
periodically
doesn't
like
come
back
to
the
same
address
ever
on
the
same
network.
B
If
I
go
author,
just
just
trying
to
respond
there,
I
mean
it
varies
also
from
a
version
version
of
the
OS
or
right,
but
latest
things
is,
is
mainly
you
make
sure
that
you
don't
change
while
you
are
associated
to
the
network
so
that
you
don't
break
your
connections
but
as
soon
as
you
disassociate
yeah.
Well,
if
you
pass
over
the
period
Then,
you
can
get
a
new
address.
Okay,.
D
So
so,
actually,
that's
a
new
policy,
that's
different,
because
my
understanding
from
our
previous
meetings
is
that
there
were
devices
that,
while
you
were
associated
with
the
same
network,
we're
going
to
change
their
Mac
address,
which
causes
them
to
disassociate
and
reassociate.
Okay,
because
you
can't
you
can't
do
WPA
with
changing
your
address,
but
until
they
fix
something,
but
that
they
would
do
that
regardless.
But
you're
telling
me
that
there's
another
policy,
which
is
that
each
time
you
connect
you
get
a
new
Mac
address,
but
it
it.
It
doesn't
expire.
D
B
D
D
A
Yeah
in
mind,
I
have
to
check
what
the
devices
do
today,
but
it's
basically
as
I
say
a
combination
of
both.
So
you
have
a
different
Mac
addresses,
ID,
yes,
and
on
that
one,
you
may
rotate
that
one
every
whatever
amount
of
time
like
one
day,
two
days
or
whatever.
So
it's
a
kind
of
a
combination
of
both,
but
not
necessarily
that
every
time
you
change
network,
you
need
a
new
one.
So.
D
So
I
would
like
to
extend
that
with
that
concept
and,
as
I
said,
I
think
it's
important
that
we
document,
even
if
it's
even
if
it's
only
one
rev
of
one
operating
system,
done
something
weird
right.
I
think
it's
important
that
we
document
that,
for
the
simple
reason
that
someone
else
is
going
to
do
that
or
show
up
with
that
wrong
thing
or
think
it's
a
good
idea,
and
so
we
need
to
to
say
be
able
to
say
to
them
and
carve
the
conversation.
Are
you
doing
this
and
they
go
yeah
yeah?
D
F
B
H
B
B
Okay,
so
if
that's
okay,
let
me
practice
from
here.
So
this
is
a
reminder
of
of
the
discussion
we
had
in
the
beginning.
So
so
we
have
these
deliverables
in
our
Charter
right,
first
and
I'm
copy
pasting
from
the
charter
literally,
so
we
have
a
document
documenting
current
state
of
affairs
and
we
have
two
informal
informational
documents.
One
is
the
use
cases
and
identity
requirements
document,
and
we
heard
already
the
presentation
from
Jerome.
B
Then
we
have
the
MAC
address
randomization
current
set
of
a
first
document.
Then
we
heard
the
presentation
from
Carlos
and
we
are
missing
this
third
one,
which
is
the
the
BCP
document
that
we've
been
talking
about
so
taking
again
another
part
of
the
draft
of
the
charter
separating
here
in
three
different
colors
just
to
make
it
easier.
B
So
let
me
read
it
quickly:
the
green
part.
We
will
generate
a
BCP
document
that
will
recommend
means
to
reduce
the
impact
of
RCM
on
the
documented
use
cases,
while
ensuring
that
privacy
is
not
compromised.
So
fair
enough,
we
need
to
debate
the
BCP
needs
to
rely
on
the
use
cases
that
will
be
documented
in
the
first
informational
document.
B
So
this
is
basically
what
our
the
MAC
address
was
used
for
before
and
if
we
want
to
preserve
the
Network
Services,
we
need
to
exchange
these
identifiers
between
client
and
service
provider,
and
we
will
first
recommend
whatever
existing
Solutions.
Are
there
to
do
so.
Moving
on
to
the
purple
part,
the
working
group
will
work
together
with
other
working
groups
at
the
ietf,
for
instance
the
HC
interior.
B
So
basically,
what
we
are
saying
here
is
that
we
need
to,
of
course,
first
identify
the
use
cases
these
requirements,
that's
the
part
that
we
were
talking
earlier
with
with
Jerome
and
to
answer
the
question
that
we
heard
from
from
you.
We
will
first
recommend
whatever
is
existing
there
and
we
will
not
constrain
to
ietf
Solutions,
so
so
we
could
also
consider
data
2.1x.
We
could
also
consider
pass
point,
so
this
solutions
can
come
from
I
triple
80802
can
come
from
the
Wi-Fi
Alliance.
B
B
If,
of
course,
we
found
some
gaps,
then
that's
a
different
discussion
and
at
that
point
we
may
say:
okay,
well,
is
this
Gap
in
a
nato2
11
specifications?
Let's
talk
to
them
and
let
them
figure
out
if
they
will
do
something
in
nato2
at
11
BH.
If
there
is
a
gap
in
with
the
Wi-Fi
Alliance,
then
we're
going
to
talk
to
them.
B
If
what
WBA
is
doing
makes
sense,
we
can
also
adopt
it,
but
if
ever
there's
an
issue
with
an
ietf
document
at
that
point,
I
guess
we
would
need
to
see
if
it's
in
the
scope
of
one
of
the
existing
working
groups.
So
if
there's
something
else
to
do,
but
basically
we
cannot
do
any
of
that
until
we
have
identified
the
use
cases
clearly
the
requirements
for
each
one
of
these
use
cases
and
this
we
have
evaluated
existing
solutions
that
are
out
there.
B
So
that
is
I,
guess
the
main
point
of
having
the
first
two
documents
in
a
good
shape
so
that
we
can
start
talking
about
BCP
I'm,
not
saying
we
will
wait
until
those
documents
are
are
published.
We
can
work
in
parallel,
but
we
need
to
keep
in
mind
that
the
BCP
it's
a
follow-up
of
the
earlier
document.
B
D
D
That's
the
recommendation
is
stop
doing
WPA
psk
because
it
just
doesn't
work
when
everyone
knows
the
psk,
because
you
just
get
you
know,
evil
twins
and
they
just
put
up
a
thing
and
then
they
get
all
your
privacy
information
right.
So
that's
a
a
for
example.
Just
doesn't
work
right.
What
we're
doing
in
the
ietf
with
our
Network
don't
validate
certificate
again
doesn't
work
because
people
just
take
your
your
credit,
your
your
they
just
watch
you
in
Layer,
Two
and
the
whole
point
of
the
RCM
becomes
moot
right.
D
So
I
think
there's
a
bunch
of
things:
don't
have
an
open,
non-encrypted,
Hotel,
Network
and
a
portal
you
can't
it
can't
work
and
also
when
you
change
your
Mac
address,
you
have
to
go
through
the
portal
again,
which
pisses
everyone
off,
which
means
they
turn
off
the
RCM
for
the
Hilton,
which
means
that
effectively
anything
that
makes
you
turn
off.
Rcm
is
effectively
an
attack
is
my
opinion.
So
that
means
that
we
have
to
somehow
move
to.
D
Having
EAP,
TLS
otherwise
known
as
WP
Enterprise,
and
we
have
to
make
it
easy
and
I
don't
see
any
way
of
any
other
direction
like
that
has
to
be
our
recommendation
and
if,
if
that's
too
hard
or
whatever,
then
my
answer
is
okay:
I
guess
you
didn't
really
want
privacy,
okay
and
and
that's
okay.
You
can
make
that
decision
right,
I,
really
don't
care.
D
If
anyone
knows
my
fridge
is
talking
to
my
access
point,
because
it's
my
fridge
and
it
doesn't
go
to
coffee
shops
and
it
doesn't
go
anywhere
else
and
that's
all
right.
Okay,
contains
the
coffee,
doesn't
go
to
the
coffee
right,
so
I
think
that's
something
that
I
think
we
really
need
to
make
clear
and
that
RCM
is
is
a
is
a
a
benefit
and
it
comes
with
a
cost
and
we
have
to
decide
if
we're
willing
to
pay
that
cost
or
not,
and
one
of
the
costs
is.
D
That
means
we
actually
have
to
have
identities
that
are
usable
from
in
our
devices
that
people
can
do
things.
So
that's
really
all
I
say
I'm
willing
to
work
on
this
document,
but
you
know
you're
going
to
have
to
put
something
someone
else
with
me
to
kind
of
hold
me
down
a
bit
because
you
won't
like
the
result.
Otherwise
you
may
not
like
the
results
or
it
may
be
too
radical.
That's
all.
D
Sure
do
look
both
ways
before
crossing
the
street.
Okay,
don't
step
onto
the
street.
With
your
eyes
closed,
so
I
mean
that's,
it's
the
same
advice,
okay
and
in
here
you
will
get
killed
because
you
look
the
wrong
way,
but
so
yeah.
So
we
have
to
be
clear
when
we're
making
a
recommendation,
we're
going
to
have
to
be
clear
why
other
things
do
not
work.
So
there
was
a
recommendation,
a
suggestion.
D
We
could
have
a
DHCP
option
to
tell
a
portal
that
where
the
same
guy
is
lost
time
I'm
like
well,
that's
that's
just
a
a
new
p,
a
new
easier
way
to
get
your
identity
for
an
attacker
to
me
and
yeah.
So,
for
instance,
don't
use
EAP,
TLS
1.2,
because
your
certificate
will
be
in
the
clear
over
EAP
do
use
eapt
less
1.3,
which
is
just
barely
a
RFC
at
this
point,
because
you
get
to
encrypt
your
certificate
and
you
get
to
validate
the
server
cert
before
you
send
your
client
certificate.
D
B
Thanks
I,
I,
agree
and
I
think
that
that
goes
in
line
with,
at
least
from
my
point
of
view,
with
the
the
philosophy
and
intention
of
ietf
in
general,
when
we
have,
for
instance,
security
considerations.
It's
also
to
make
sure
that
whoever
reads
the
RFC
understands
what
are
the
other
things
that
they
have
to
consider
whenever
they
Implement
specifications,
so
in
this
case
to
make
makes
perfect
sense.
B
Also,
you
make
me
think
that
the
latest
discussions
in
the
Wi-Fi
Alliance,
for
instance,
are
indeed
talking
about
securing
beacons
and
stuff
like
that.
So
so
it's
true
that
we
may
not
be
aware
of
all
the
things
that
are
happening.
So
a
lot
of
these
are
upgrades
to
previous
versions
so,
and
that's
for
a
reason
that
they
do
that
so
making
like
a
warning
about
don't
use
this
previous
version
for
X
and
Y
makes
perfect
sense
to
me.
C
B
C
B
So
there
is
I
mean
for
sure
there
is
the
global
and
local
bit
that
has
to
be
respected
right,
because
otherwise
you
you
have
a
global,
unique
identification,
then
moving
on.
There
are
recommendations
in
NATO
too
about
how
to
use
and
how
to
declare
the
rest
of
the
the
the
bits.
There's
a
specification
that
talks
about
a
quadrant
where
you
can
Define
what
type
of
randomization
you're
going
to
use,
and
you
can
also
request
the
specific
organization
identifiers,
but
those
are
recommendations
so
so
to
answer
your
questions
sounds.
B
A
Yeah,
basically
yeah
there
are,
as
Juan
Carlos
said,
you
can
do
different
things
and
I
guess
your
comment
about
keeping
the
kind
of
the
ouai
the
the
prefix
on
them
randomize.
The
second
part
is
one
of
the
quadrants
that
is
defined,
so
they
typically
Define
a
way
of
a
structure
in
the
the
local
space
of
Mac
addresses.
A
So
there
is
a
bit
for
local
and
Global
and
in
the
local
you
can
have
this
this
quadrant,
so
you
play
with
two
bits:
25
with
quadrant,
and
one
of
them
is
basically
specified
to
do
what
you
mentioned.
Well,
there
are
other
approaches.
You
can
randomize
the
whole
44
remaining
bits.
You
can
do
other
things,
but
one
is
exactly
what
you
mentioned.
Good
explanation.
B
So
at
your
room,
it's
this
infrastructure
that
allows
people
from
different
academic
institutions
to
connect
to
the
network,
and
then
we
are,
we
have
enrolling
it.
We
have
been
working
with
ROM
and
connecting
to
other
room
for
a
while
at
the
ietf.
So
you
you
may
have
seen
the
this
is
ID
and
people
that
belong
or
have
affiliation
with
some
academic
institution
automatically
can
connect
to
to
other
ROM.
B
So
open
roaming
expands
that
by
using
a
pass
Point
from
the
Wi-Fi
Alliance
to
allow
not
only
one
but
multiple
identity
providers,
and
there
are
a
number
of
them.
These
can
be
Cloud
providers.
Service
providers,
corporations
cellular
companies
that
already
have
some
sort
of
a
relationship
to
a
to
a
client,
and
the
idea
is
to
allow
different
network
infrastructure
so
or
network
infrastructure
providers
to
authenticate
with
these
multiple
identity
providers.
B
B
So,
to
give
you
an
update
about
a
little
more
details,
since
we
did
not
run
the
experiment
at
this
time,
we
we
did
do
some
steps
towards
future
meetings,
so
we
had
a
technical
meeting
before
ITF
between
WBA
and
the
ITF
knock
specifically
because
they
are
the
ones
that
run
the
the
network
for
people
that
are
not
aware.
We
have
the
network
ratings
center
team
at
the
ITF
and
they
had
to
agree
and
look
at
all
the
details
of
any
experiment
that
runs
on
the
ITF
Network.
B
As
you
know,
this
is
critical
infrastructure
for
our
meeting,
so
we
want
to
first
most
make
sure
that
it
doesn't
endanger
our
our
meetings.
So
the
different
points
that
we
need
to
solve
is
who
would
be
the
identity
provider?
If
ever
we
run
this
experiment
or
the
identity
providers
that
we
preserve
the
user's
privacy,
as
we
always
do
with
the
ietf
attendees,
how
we
would
provision
devices,
meaning
mobile
phones
or
laptops
with
different
operating
systems?
F
B
B
We
had
a
big
question
marks
about
the
BCP,
but
I
think
we
made
some
progress
here
and
we
even
have
some
some
volunteer
to
to
start
editing,
something
which,
of
course,
requires
more
more
work
on
the
on
the
use
cases,
but
otherwise
I
think
the
these
immediate
steps
are
what
is
needed.
Eric
right,
I,
don't
know
if
you
see
something
else
that
we
need
to
work
on.
F
We
take
the
mic
for
the
giant
anyway,
it's
nice
right
now,
yeah.
As
you
said,
we
are
basically
arriving
at
the
end
of
the
Milestone
I
mean
assuming
the
BCP
is
done
within
a
year,
which
I
think
is
reasonable,
because
we
got
already
some
basis
and
Michael
will
provide
more
and
we
may
be
our
last,
but
one
know
last
but
two
madina's
meeting
and
we
declare
success
touching
wood,
okay
and
thanks
as
well
for
the
working
group,
because
you
provided
some
feedback
right
to
improve
the
document.
It's
always
interesting.
A
I
have
one
one
common
question:
I
think
that
as
a
potential
neck
has
next
actions,
so
we
have
to,
of
course
provide
an
update
on
different
documents
following
or
getting
into
account
the
feedback.
But
then
maybe
I
would
like
to
at
least
as
a
sort
of
one
of
the
documents.
I
will
appreciate
if
we
can
get
some
volunteers
to
review
the
next
iteration
of
the
document
before
the
next
ITF
meeting
ibid.
B
Yeah,
that's
a
good
point
and,
and
in
fact
a
couple
of
the
questions
that
we
heard
it's
part
of
the
intention
of
these
documents
is
precisely
to
answer
those
questions.
So
so,
if,
if
you
are
interested
in
this
topic,
for
instance,
the
implementations
on
the
operating
systems,
so
if
you
don't
find
the
answer
to
your
questions,
it's
a
super
good
information
for
the
authors
to
to
provide
like
okay,
well,
I
would
like
to
understand
what
is
happening
or
what
you
are
missing.
This
reference
or
I.