►
From YouTube: IETF113-MADINAS-20220324-1200
Description
MADINAS meeting session at IETF113
2022/03/24 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
Okay,
hello,
everyone
we're
gonna,
get
started
slowly.
Well,
people
come
back
from
lunch
here
and
connect
some
some
of
them
very
early
in
north
america,
or
a
little
late
in
asia.
So
hi.
Everyone
welcome
to
the
ietf
madina's
working
group
at
ietf
113
here
in
vienna,
austria,
our
first
hybrid
meeting,
and
we
see
many
more
people
in
this
for
this
session
connected
remote
than
than
locally.
A
A
A
So
please
be
aware
that,
but
by
participating
in
this
meeting,
you
agreed
to
this
policies
and
therefore,
if
you
are
aware
of
any
ietf
contribution
covered
by
patent
or
patent
application,
please
let
us
know
you
have
to
disclose
it
or
not,
participate
in
the
discussion.
If
you
so
desire,
you
acknowledge
that
written
audio
and
video
photo
records
of
this
meeting
will
be
made
public
and
the
personal
information
that
you
provide
to
the
itf
will
be
handled
in
accordance
to
the
privacy
statement.
A
A
A
So
if
you
have,
if
you
have
questions
about
the
agenda,
the
mythic
information
or
you
need
technical
assistance,
you
can
also
use
those
links
and
final
point,
though
so
minutes
are
taken,
the
meeting
is
recorded
and
your
presence
is
locked.
So
at
this
point
we
would
like
to
see
if
anyone
could
help
us
take
notes,
lauren
thanks.
Anyone
else
ivan.
A
So
the
agenda
for
this
time
we
have
this
slides
that
we
are
going
through
right
now,
we're
going
to
start
with
jerome
talking
about
the
use
cases
and
problem
statement,
draft
randomized
and
changing
mac
addresses,
followed
by
carlos
presenting
the
mac
address,
randomization
current
statute
of
affairs.
So
those
two
drafts
have
been
adopted
by
the
working
group
and
the
they
will
be
the
the
main
focus
thereafter.
A
B
The
document
is
at
the
link
that
is
available
at
the
top
of
the
slide,
and
we
realized
that
in
in
many
cases,
with
the
conversations
where
often
people
pass
each
other
and
that's
because
there
are
multiple
environmental
constraints
and
variables
that
people
were
referring
to
and
they
were
not
always
referring
to
the
same
ones.
For
example,
we
say
they
are
spying
on
your
personal
information,
their
pii
they,
who
is
they?
What
pii
are
we
talking
about?
B
B
You
know
these
different
actors
that
may
be
involved
in
this
exchange
with
infrastructure
and
the
internet,
starting
from
the
user
device.
So
we
recognize
that
there
are
some
network
entities
that
say
objects
for
example,
that
is
your
wi-fi
access
point.
Your
wireless
lan
controller,
your
switches,
your
routers,
you
know
all
these
devices
may
have
a
view
of
the
device
mac
address
as
traffic
transit
through
them,
but
there
are
also
some
human
related
entities,
and
that
could
be
you
know,
multiple
people.
B
Of
course
it
could
be
the
user,
but
it
could
be
also
the
it's
supporting
an
enterprise
that
could
be
the
entity
managing
the
wi-fi
at
your
airport,
etc.
So
each
of
these
will
have
a
different
type
of
interaction
with
the
device's
information
and,
of
course,
with
the
mac
address.
We
also
recognize
that
not
every
environment
is
the
same
and
not
every
user
has
the
same
relationship
with
the
environment.
B
So
we
come
to
define
what
we
call
the
trust
level
where
we
say
there
are
places
where
probably
a
device
and
its
user
will
not
trust
any
device
or
any
actor
in
the
environment.
Typically
public,
wi-fi,
guest
wi-fi.
You
will
not
trust
anything.
There
are
some
other
environments
where
the
trust
might
be
more
towards
the
partial
trust
where
you
may
be
trusting
some
of
these
elements,
but
not
all
of
them.
For
example,
if
you
are
in
enterprise
network
with
device
provided
by
your
enterprise,
it
is
likely
that
you
might
be
trusting.
B
You
know
the
network
wire
network
section
of
the
enterprise,
because
all
that
is
manage
your
device
and
the
network.
You
may
not
trust,
you
know
the
air
and
people
sniffing
around,
but
you
may
be
trusting.
You
know
the
services
provided
by
the
device
to
the
device
by
the
environment
et
cetera,
and
then
we
go
on
by
listing
the
entities
among
all
of
those
that
may
have
a
need
or
an
interest
in
tracking
mac
addresses.
B
So
that
is,
of
course,
you
know
anything
that
is
a
functional
entity
that
needs
the
mac
address
to
proceed
through
communication
exchanges.
But
of
course
there
are
some
entities
which
are
human
entities
that
rely
on
the
mac
address
for
different
purposes
like
troubleshooting,
tracking
or
legal
tracking
etc.
B
So
we
list
all
these
elements,
and
then
we
finish
these
documents
by
you
know
listing
the
assumptions
and
again
I
I
bring
you
back
to
the
document
to
to
these
assumptions
about
the
fact
that
you
know
a
network
element
should
not
nor
rely
on
the
id.
That
is
a
unique
mac
address
association
to
a
device
that
would
be
permanent,
etc.
B
So,
again,
I'm
just
browsing
through
this
draft
fairly
quickly,
because
I
know
we've
been
discussing
it
extensively
in
the
current
version
of
the
draft.
You
may
remember
that,
before
its
adoption
to
the
martinez
group,
we
had
a
conversation
about
this
draft
extensively
and
the
last
one
was
in
the
meeting
prior
to
the
vote
by
which
the
group
decided
to
adopt
it.
So,
after
the
vote
to
adopt
this
document
was
passed,
we
brought
we
changed
the
name
of
the
document
and
brought
it
from
the
henry
something
version.
B
Three,
if
I
recall
into
the
draft
ietf
madinas
use
case
version
zero,
which
is
you
know,
the
same
document
as
this
henry
v3
document,
but
brought
into
the
ownership
of
of
the
magnets
group
and
then
immediately
after
we
started
implementing
in
v1
the
commands
that
we
received
in
the
face-to-face
where
it
was
designed
and
voted
that
we
would
adopt
this
document.
So
currently,
the
version
that
you
will
see
in
these
documents
is
version,
one
of
the
marinas
use
case
document
and,
of
course,
as
usual.
B
This
document,
of
course,
is
a
living
document,
we're
intending
to
work
with
it
to
improve
it
and
among
the
things
that
we
think
we
could
do.
One
of
them
is
to
match
this
document's
evolution
with
the
charter
of
the
group,
and
that
includes,
for
example,
survey
the
current
standards
and
their
use
of
the
mac
address
as
a
device
identifier
in
the
protocol,
we'll
have
a
quick
read
in
about
half
an
hour.
B
I
think
on
what
happens
at
the
ieee
in
the
802.11
group,
but
it's
likely
that
there
are
some
other
groups
and
other
sdos
that
could
be
interesting
to
us
once
we
have
this
reading.
It
could
be
interesting
for
us
also
to
come
to
conclusions
on
whether
we
see
that
the
usage
is
a
conformant
to
what
we
think
should
be
the
right
balance
between
operational
efficiency
and
and
privacy.
So
we
could
also
make
some
recommendations
to
the
working
groups.
You
know
to
remove
those
dependencies
if
there
are
any.
B
Of
course,
we
will
likely
identify
that
there
are
some
scenarios
where
we
will
not
want
these
devices
to
be
identified
by
anything.
In
which
case
you
know,
rotation
of
mac
address
is
something
that
we'll
be
probably
suggesting
or
recommending
and
we'll
be
examining
what
protocols
can
be
affected
by
the
rotation
of
the
mac
address.
B
There
will
also
be
likely
some
scenarios
or
environments
where
we
will
identify
that
it
might
be
useful
for
the
user
experience
and
for
the
continuity
of
service
that
an
id
that
identifier
would
be
exchanged
between
the
device,
and
you
know
the
target
service.
In
that
case,
we'll
probably
we
need
to
come
through
the
different
centers
and
see
if
there
are
some
identifiers
that
could
be
used.
B
For
example,
in
1811
2011
there's
a
table
called
table
966,
which
is
defined
in
the
anqp
section
of
the
document
that
defines
venue-
and
it
says
you
know
the
access
point
can
express
what
kind
of
venue
this
device
is
in,
and
you
can
say
it's
very
expensive.
It
has
more
than
70
types
of
venues
from
automotive
to
a
boat
to
an
airport
etc.
B
So
that
could
be
information
that
could,
for
example,
be
sent
to
the
station
to
help
the
station
assess
if
it
may
decide
to
start
trusting
some
of
the
services
or
not
knowing
that
this
information,
of
course,
is
not
secured.
It's
not
authenticated
until
the
association
is
complete,
so
there
are
all
sort
of
environmental
conditions
that
we'll
need
to
to
think
about.
B
But
you
know
that
kind
of
exchange
of
information
between
the
venue
elements
related
services
that
the
station
may
need
and
the
station
may
help
the
station
decide
what
to
do
and
what
kind
of
environments
it
might
it
might
be
operating
and
therefore
make
choices
in
terms
of
obfuscating,
further
its
identity
or
revealing
some
identifier
to
some
services
that
it
decides
needs
to
be
continuous
through
the
mac
rotation,
so
that
you
know
could
be
an
identity,
of
course
to
the
network
or
to
specific
services.
And,
of
course,
in
that
same
line.
B
B
So
among
all
these
steps,
the
first
one
to
me
is
probably
one
where
we
have
most
urgency
and
a
lot
of
work
to
do,
because
you
know
I'm
an
eight
to
11
person.
My
knowledge
of
the
now
now
close
to
nine
thousand
itf
rfcs
is
more
limited.
I
don't
know
the
9000
by
hearts,
so
you
know
it
would
be
interesting
for
us
to
look
into
those
standards.
B
You
know
outside
of
the
itf,
but
also
within
itf,
to
know
which
ones
use
the
mac
address
as
a
device
identifier
and
possibly
make
the
expectation
that
the
device
itself
is
identified
by
its
mac
address.
You
know.
Few
rfcs
that
come
to
mind
would
be
those
related
to
protocols
like
dhcp,
for
example.
It
seems
to
me
that
in
the
choreography,
the
initial
identifier
of
the
station
as
far
as
layer
3
goes,
is
a
0
0
0.
B
If
it's
ipv4
and
then
you
know,
the
address
is
going
to
be
the
mac
address
to
and
from
the
dhcp
server,
and
then
once
the
ip
address
has
been
assigned
and
allocated
and
accepted
by
the
station
it
it's.
It
seems
to
me
that,
most
of
the
time
the
station
is
going
to
be
identified
in
the
dhcp
server
by
its
mac
address
and
its
association
to
the
ip
address.
So
that
could
be
a
first.
You
know
element
that
comes
to
mind,
but
again
I'm
not
an
expert
in
these
rfcs.
B
You
know
those
of
you
on
this.
This
calling
in
this
room
have
more
expertise.
There
may
help
us
identify
those
protocols
and
what
kind
of
dependencies
assume
are
not
assumed,
and
also
are
there
some
identifiers
that
could
be
replacing
the
mac
address
in
those
another.
One,
of
course,
is
anything
which
relates
to
to
the
11
process
of
attaching
to
an
access
point,
and
that
is
include
a
heap
that
includes
radius
and
no
problem
for
the
other.
B
So
if
you
know
of
any
protocol
or
standards
or
rfcs,
where
you
think
the
mac
address
may
play
a
role
in
the
identification
of
the
device,
you
know,
I
would
like
to
call
you
to
come
forward
and
post
to
the
list
or
talk
to
us.
You
know
help
us
identify
those
those
protocols,
so
we
can
start
in
this
draft
listing
them
and
you
know
listing
and
documenting
how
they
expect
the
mac
address
to
be
used,
and,
of
course
you
know
this
is
true
at
the
itf.
B
This
is
true,
of
course,
elsewhere
you
know
by
the
ieee
11.
We
have
some
familiarity,
I'm
sure
that
they're,
I'm
not
going
to
be
able
to
identify
all
by
myself
everything
that
is
done
in
82.11,
for
example,
which
is
close
to
6000
pages
so
far,
but
there
are
also
some
other
you
know
sdos.
You
know
idea
triple
itself
a22.1,
for
example,
and,
of
course
802.1x.
B
You
know
all
the
association
for
radius,
but
also
other
other
sdos
like
the
wba,
for
example,
the
wi-fi
alliance
and
and
many
others
that
I
don't
think
of.
So
please,
if
you
have
any
willingness
to
contribute,
help
us
identify
those.
Please
help
us.
You
know
by
maybe
listing
how
you
see
documenting
how
you
see
those
mac
addresses
be
used
or
if
it's
you
know
just
too
much
of
a
read.
Please
just
share.
B
You
know:
rfc
numbers
protocol
numbers
in
the
chat
in
the
chat
in
the
in
the
list,
and
you
know,
let's
start
together,
exchanging
on
those
and
come
through
this.
The
practice
of
the
industry
today
to
identify
where
mac
addresses,
are
needed
and
see.
If
we
can,
you
know,
continue
operating
services
without
those
mac
addresses.
B
C
Yeah,
carlo
bernardo's
question
as
an
individual
all
right.
A
comment
is
on
this
point
about
the
identifying
what
protocols
use
the
the
mac
address
as
an
identifier,
I
wonder
if
there
is
any
way
of
where
we
can
do
this.
As
a
more
I
don't.
I
don't
know
how
to
say
a
way
that
we
ensure
we
don't
miss
any
because
I
guess
there
will
be
many
potential
protocols
out
there
that
may
use
the
mac
address
random.
I
mean
the
manga
is
as
an
identifier
I
just
thinking
of,
for
example,
mobility
protocols.
C
There
are
a
lot
that
come
to
my
mind
that
mac
addresses
may
be
one
of
the
identifiers
that
they
can
use.
It's
not
the
only
one,
but
maybe
so
I
wonder
if
there
is
anything
that
we
can
do
to
make
this
in
a
more
organized
way,
maybe
asking
feedback
from
other
working
groups.
I
don't
know
how
to
do
it
to
ensure
that
we
don't
miss
any
because
I
don't
know
if
this
button
up
approach
may
may
we
may
miss
some.
I
don't
know
this
is
a
question
for
us
to
to
think
about.
B
Yes,
thank
you
very
much,
carlos
and
in
fact,
I
think
we
should
do
both
you're
right.
I
think
a
liaison,
and
we
have
such
things.
Our
questions
to
the
other
seos
would
be
a
great
way
to
to
help
us.
I
did
a
fun
exercise.
The
other
day
I
got
went
to
dr
go
and
search
for
mac
address
with
the
site
ietf.org.
B
I
found
only
200
000
references,
so
just
that
tells
me
that
it
probably
would
be
useful
even
within
the
ietf,
to
maybe
query
experts
in
some
groups
or
the
groups
themselves.
If
we
have
such
communication
medium
to
ask
them
to
help
us
so
yeah
working
both
way
up
bottom
up
and
top
down
yeah.
Thank
you.
Okay,.
B
A
D
Here-
and
I
am
the
pretty
much
the
lead
technical
contributor
to
the
drip
working
group
and
where
we're
dealing
with
unmanned
aircraft
and
right
now,
we're
focusing
on
what's
called
the
broadcast
remote
id.
These
are
messages
which
are
sent
with
broadcast
frames
to
receive
by
by
observers
on
the
ground,
so
these
are
sent
through
the
various
broadcast
frames
in
bluetooth,
4,
bluetooth,
5
or
wi-fi
nan
or
wi-fi
beacons.
D
The
observer
can
only
see
these
messages,
maybe
for
a
brief
period
of
time,
to
need
to
link
them
together.
This
standard
has
been
written
and
designed
to
use
mac
addresses,
particularly
bluetooth
4.
We
only
have
27
bytes
of
payload,
so
anything
to
do
has
to
be
linked
by
via
mac
addresses
in
terms
of
the
uas
themselves.
They
pretty
much
are
consistent
on
at
least
using
the
same
mac
address
per
quote
operation,
which
you
would
call
per
flight.
B
D
E
B
A
E
Time
is
tim,
hey,
don't
tim,
hey
jerome,
so
on
the
I'm
not
sure
about
all
the
tooling
across
the
stos,
but
at
a
minimum
I
think
we
should
be
able
to
de-reference
the
mac
address
right
if
people
did
normally
reference
it
and
pull
all
the
specs
that
mentioned
it
I
mean
I
don't
know
that
might
be
an
easy
way
to
get
a
bunch
on
the
use.
Cases
looks
awesome.
The
one
thing
I
would
say
is
across
these
docks.
I
would
avoid
mdm
versus
byod.
E
G
G
I
don't
know
what
the
cost
of
missing
a
protocol
is
in
this,
because
I
don't
know
what
we're
going
to
do
with
this
list
at
the
end
of
the
day,
and
I
think
that's
actually
more
important
discussion
to
have
than
how
to
get
you
know.
All
the
references
is.
What
is
the
goal
of
doing
this
and
I
think
bob
actually
brings
up.
G
So
I
think
that
that
what
I
think
we're
doing
in
this
group,
I
think
we're
going
to
be
trying
to
write
down
the
set
of
compromises
where
randomize
and
changing
mac
address
is
a
good
idea
and
where
it's
a
bad
idea
and
then
in
fact
it
may
be
privacy
violating
to
do
that.
Rather
than
so,
I
don't
think
it.
Our
goal
should
be.
G
How
can
we
remove
mac
addresses
from
being
the
primary
key
of
databases
everywhere,
but
rather
to
say,
these
uses
are
clearly
privacy
violating,
and
you
should
do
something
else,
and
these
other
users
are
going
to
have
to
the
second
category.
Well,
you're
going
to
have
to
do
some
correlation
after
the
fact
and
the
third
category
is
my
refrigerator
just
isn't
going
anywhere.
I
really
don't
care
what
mac
address
it
uses
it's
always
going
to
be
in
my
house,
and
it's
not
going
to
starbucks
and
that's
really
it
right.
It's
a
moot
point.
F
A
Yeah
I
I'd
like
to
well
answer
just
to
to
your
point
about
the
purpose,
because
I
think
that
touches
on
the
on
the
group's
chart
there
and-
and
I
think
indeed
what
what
you
mentioned
is-
is
the
end
goal.
So
it's
not
to
say
let's
randomize,
but
rather
given
the
fact
that
randomizing
mac
addresses
is
happening.
A
We
want
to
list
all
these
use
cases
and
you
just
went
through
a
few
of
them
that
are
very
relevant.
We
want
to
make
sure
that
we
capture
in
this
document
all
these
use
cases,
plus
any
other
that
people
may
have.
We
talked
about
the
hospitality
or
private
networks,
public
networks
etc.
So
so
fair
enough
and
then
once
we
categorize
those
we
can
say
yes
in
this
case
it
doesn't
make
sense.
A
H
A
C
C
Okay,
I
think
now
is
better,
so
I'm
carlos
bernardos,
I'm
presenting
the
macarthur's
randomization
draft
on
behalf
of
my
co-author,
juan
carlos
amelia,
so
just
a
brief
introduction,
because
the
the
goal
of
the
presentation
today
is
more
about
talking
about
next
steps
and
specifically
about
some
changes.
Potential
changes
on
the
table
of
contents,
but
well,
some
introduction.
You
all
know.
C
Privacy
is
an
increasing
concern
and
the
use
of
mac
address
unique
mac
address
may
lead
to
some
potential
threats
and
because
of
that
well
many
projects
and
many
os
vendors
have
started
to
randomize
addresses
and,
and
that
also
triggers
some
other
efforts
in
some
research
and
standardization
communities
about
the
use
of
mac
address
randomization,
and
this
draft
is
basically
documenting
what
is
being
done
in
in
those
in
those
areas
in
those
seos
and
also
in
those
mobile
oss.
What
are
the
policies
and
approaches
that
are
being
used
to
randomize
mac
access?
C
So
this
is
the
table
of
the
current
table
of
content
of
the
draft.
We
have
the
introduction,
introduction
the
background,
the
activities
on
the
ieee
on
the
itf
on
the
wba,
and
then
we
have
a
section
on
the
current
practices
of
the
different
oss,
focusing
a
bit
more
on
the
mobile
oss,
but
also
covering
other
fixed
os's,
and
that's
the
section
I
will.
I
will
have
a
question
at
the
end
on
how
we
basically
manage
that
particular
section.
C
We,
because
we
got
quite
comments
on
the
on
the
mailing
list
on
this,
so
moving
on
in
itf.
Well,
there
there's
been
a
quite
a
lot
of
activity
related
to
mac
address
randomization
we
started
quite
in
itf
91.
We
were
doing
some
tests
and
experiments
for
those
that
were
there.
Maybe
you
even
tried
the
the
scripts
that
we
provided
to
see
what
happened
when
you
start
to
run
domain
addresses
in
a
real
network.
C
There
were
also
other
documents
related
to
to
privacy,
the
use
of
different
iavs
and
ipv6
and
other
things
in
dcp,
the
the
potential
impact
of
of
using
an
identifier
in
the
protocol
and
then
after
that.
Well
it
came
that
now.
Randomizes
mac
address
is
a
default
policy
in
mobile
oss
and
what
there
will
be
more
on
that
at
the
end.
C
Let's
see
that's
weird
well,
anyway,
there
are
some
activities
also
at
the
ieee.
I
don't
know
if,
if
you
stop
and
start
that
get
fixed
anyway,
you
will
see
later
on
on
this
by
jerome.
So
basically,
here
is
just
a
pointer
on
what
the
denon
is
gonna
be
explaining
later
on,
and
then
I
don't
know.
Oh,
there
is
also
a
section
in
the
draft
about
the
wba
activity.
C
There
was
a
run
of
alliance,
look
at
the
at
the
issues
created
by
randomizing
mac
addresses
and
there
are,
as
there
is,
a
document
documenting
the
use
cases
where
this
is
relevant,
where
this
make
case
cause
some
some
issues
and
lucid,
I
think,
is
going
to
present
that
next
right
from
the
vba
then
the
current
practices.
This
is
an
accept,
except
from
the
from
the
draft
about
what
the
major
mobile
oss
are
doing
today,
android
starting
from
version
10
and
ios
from
version
14..
C
I
will
not
go
into
the
details,
but
basically
we
look
into
how
the
randomized
mac
addresses
are
created
under
which
circumstances
and
and
when
they
are
refreshed,
whether
they
are
persistent
or
non-persistent,
whether
they
change
from
one
network
to
the
other
or
they
rotate
through
maybe
every
day
or
every
sometime,
these
kind
of
things-
and
we
also
did
a
more
elaborated
tests
involving
also
windows,
10
and
linux,
and
in
the
latest
version
of
the
draft.
We
also
added
some
notes
that
are
starting
in
android
12.
C
There
are
some
changes
compared
to
what
we
did
in
the
previous
version
in
terms
of
the
use
of
persistent
or
non-persistent
and
other
randomization.
So
there
are
some
few
changes,
some
view
tweaks
there
regarding
the
updates
version:
zero,
zero,
its
zero
zero
was
the
the
exactly
the
same
version
that
was
adopted,
the
one
that
was
in
the
working
group
adoption
call
and
in
the
current
version
version
01.
We
basically
addressed
some
comments
that
we
receive
mainly
from
from
hey
salon
on
the
this
android
particular
change
and
next
steps.
C
C
There
were
some
comments
on
how
to
basically
keep
this
section
up
to
date,
whether
we
should
move
it
on
a
wiki
or
some
external
repository.
Somehow
that
can
be
updated
even
when
the
this
document
is
published.
So
there
are
some
options
listed
here.
There
are,
I
mean
there
may
be
others,
but
the
the
three
main
ones
that
that
we
see
is
one
option.
Is
we
keep
it
as
it
is
option
two?
C
Is
we
move
section
section,
seven
to
an
annex
and
refer
also
to
an
external
wiki
or
other
type
of
url
or
document
repository
where
we
keep
that
text
updated,
but
we
still
keep
like
the
picture
of
what
is
the
status
at
the
time
of
publishing
this
document
option?
Three?
Is
we
convert
that
section,
seven
in
the
external
reference,
so
there
is
no
current
picture
kind
of
or
a
snapshot
of
the
status
in
the
document,
and
we
refer
to
some
external
resource
and
there
may
be
other
options.
C
C
A
Carlos,
so
I'm
putting
myself
in
the
in
the
queue,
I
personally
have
a
preference
for
not
option
one
definitely
and
between
option
two
and
three.
I
think
it
depends
on
what
what
is
going
to
be
the
actual
goal
of
the
document,
the
I
like
the
idea
of
keeping
it
dynamic
personally
and
if
we
are
not
going
to
draw
any
conclusion
from
this
draft
and
it's
100
informational,
I
think
it
makes
sense
to
to
keep
it
completely
outside
and
then
rather
concentrate
on
how
we
can
keep
that
wiki
up
to
date.
A
But
for
this
specific
point,
especially
because
it
it
will
change
so
much
and
time
I
I
I
can
see
that
it'll
change
a
few
times
from
from
now
until
we
publish
so
I
don't.
I
think
it
will
diminish
the
value
of
the
published
document
if
we
take
snapshots,
so
my
preference
would
be
to
keep
it
completely
outside
and
and
point
to
it.
C
C
I
Let
me
keep
speaking
just
a
comment
regarding
the
table:
you've
just
presented
where
you
list
the
operating
system.
We
already
discussed
about
this
issue,
but
so
I
understand
that
for
ios
and
windows,
it's
more,
it's
rather
a
monolithic
system,
but
for
android
and
linux
they
are
based
on
components.
In
fact,
it's
not
the
android
system
that
decides
how
the
address
is
handled.
I
This
is
a
component
called
the
wpa
supplicant,
and
maybe
it's
not
the
only
one
that
is
dealing
with
that
and
the
features
that
can
be
implemented
in
the
code
and
also
activated
by
android
and
also
the
vendors
are
such
that's.
The
the
way
erasmization
may
vary
a
lot
between
the
same
version
of
androids,
depending
on
how
the
vendors
decided
to
activate
or
not
some
of
the
features.
So
my
question
is:
maybe
we
should.
I
C
Okay,
that's
that's
a
good
point
regarding
android
from
what
I
understood
I
mean
in
linux.
I
fully
agree
linux.
There
are
many
options
and
you
can
configure
everything
and
depends
on
the
distribution
that
you
may
have
and
the
network
you
are
using
network
manager.
There
are
like
at
least
three
options
or
four
options
regarding
this
that
you
can
configure.
So
it's
really
on
the
user.
And
then,
if
you
go
more
low
level
touching
the
wpa's
applicant,
then
you
can
even
have
more
options.
C
So
in
linux
is
true,
that
is
more
user
driven
and
there
may
be
variations.
We
try
to
capture
in
the
document,
but
we
we
may
try
to
improve
that
the
the
options
so
depending
on
how
you
configure
things,
what
you
can
get
that
for
the
linux
part
for
the
android.
I
also
be
there.
I
think
that
what
we
tried
to
put
there-
or
we
put
there-
is
basically
the
official,
vanilla
kind
of
android
approach.
But
I
guess
I'm
not
an
expert
on
that.
C
It's
true
that
then
the
user
and
the
on
the
the
variations
that
the
the
vendors
of
the
mobile
phones,
these
customizations,
that
they
do.
May
change
the
behavior,
so
I
guess
we
should
also
try
to
say
okay,
this
is
kind
of
the
baseline,
and
these
are
the
options
or
the
different
things.
The
different
behaviors
that
you
can
also
obtain
using
an
android
or
any
other
os.
E
J
F
J
We
sought
out
and
identified
different
methods
that
have
made
use
of
the
mac
address
and
how
they
need
to
be
addressed
to
replace
the
use
of
of
the
mac
address.
In
that
we
we
took
all
the
different
current
solutions.
We
analyzed
them
and
we
documented
them
in
different
facets
and
against
the
different
use
cases.
And
then
we
created
a
section
of
recommendations
and
how
these
solutions
may
be
used.
J
Then
what
we
did
was
we
examined
the
gaps
between
these
solutions
where
they
did
not
meet
the
requirements
to
solve
the
problem,
or
I
address
the
problem
of
rcm
and
then
we
put
together
a
solution.
You
know
suggested
solutions
for
the
different
use
cases
and
finally,
we
are
now
in
the
process
of
liaising
the
completed
paper
out
to
other
standards
bodies.
J
J
J
So
we
did
a.
We
did
look
at
it
that,
over
years
as
we
know,
the
mac
address
has
been
used
by
different
functions,
different
networks,
different
individuals
for
many
different
aspects,
and
while
the
mac
address
was
not
set
up
to
for
this
use,
it
was
a
easy
indicator
to
identify
a
device
for
different
functions,
such
as
access
control
being
able
to
troubleshoot,
and
also
even
within
law
enforcement
that
the
you
know.
J
We
in
looking
at
the
different
technologies
that
are
out
there,
we
also
looked
at
how
they
attempt
to
identify
the
device,
either
directly
or
through
the
user,
to
identify
the
device
and
that
you
know
this
is.
This
is
how
we
can
do
it,
how
we
could
take
these
solutions
and
apply
them
to
the
various
use
cases.
J
So,
as
as
we
were
looking
at
this
and
talking
to
different
vendors,
we
found
out
that,
in
the
majority
of
cases,
the
current
rcm
implementation
is
a
standard
or
session
based
or
a
time
base
that
they
will
maintain
that
same
mac
address,
but
once
a
session
is
as
ended
and
that
ssid
or
network
has
been
forgotten.
It
comes
back
generally
with
a
new
ssi
or
a
new
mac
address.
J
However,
there
is
some
applications
where,
even
during
the
session,
and
if
the
network
has
not
been
forgotten
over
a
period
of
time,
the
mac
address
is
reset,
and
this
impacts,
like
I
said,
the
the
earlier
conditions,
such
as
troubleshooting
access
control.
One
prime
example
is,
you
know
you
visit
a
hotel,
you
go
through
a
captive
portal,
you
go
out
for
several
hours
or
a
day,
and
you
come
back
now.
You
have
to
go
through
that
process
again,
because
your
your
mac
address
has
changed.
So
it
becomes.
J
J
J
It's
not
a
single
solution
to
blanket
all
use
cases,
but
that
a
set
of
solutions
could
be
used
to
cover
most
of
the
the
use
cases,
however,
that
some
of
these
solutions
actually
will
conflict
with
the
with
each
other,
so
they
can't
be
used
in
harmony
and
this
this
wraps
up
all
the
basic
findings
that
we
found.
The
these
findings
are
listed
out
in
the
white
paper.
As
I
mentioned
earlier,
we,
the
wba,
is
in
the
process
of
completing
the
liaison
to
make
the
paper
available
to
the
to
this
group.
A
Thank
you
very
much
luther
I
put
myself
in
the
queue.
First
of
all,
we
very
much
appreciate
the
report
from
wba.
I
think
it's
extremely
useful
and
relevant,
and
I
just
want
to
clarify,
as
you
mentioned,
that
we
we
very
much
like
the
the
fact
that
you
are
communicating
with
us
this
white
paper.
The
information
is
very
useful
and
relevant,
and
we
we
are,
as
you
know,
we
are
just
clearing
out
the
way
to
make
sure
that
it's
shared
properly.
A
But
with
that
in
mind,
I
think
that
this
paper
is
is
a
extremely
relevant
and
useful
reference
for
for
our
use
cases.
So
for,
of
course,
not
only
manage
networks.
We
are
going
to
look
at
all
type
of
networks,
but
we
have
to
make
sure
that
all
the
use
cases
that
you
mentioned
are
covered.
Perhaps
there
are
some
that
fall
outside
your
scope
and
that
would
be
fine,
but
for
the
ones
that
do
fall
in
your
scope.
A
As,
as
you
know,
the
the
purpose
of
this
group
is
to
find
the
the
gaps
and
then
ideally
point
to
solutions.
If
you
are
already
doing
that
and
you
found
some
issues,
that's
that's
perfect.
If
those
issues
fall
in
the
scope
of
ietf,
then
it
will
be
the
next.
The
next
topic
for
for
martinez,
to
see
how
we
can
do
that.
If
we
have
to
talk
to
the
relevant
working
group
or
if
we
have
to
do
something
some
new
work,
etc,
yeah
it
was.
J
B
Yep
no
worries
at
all.
Anyway.
It's
it's
going
to
be
a
recap
of
what
we've
heard
before
you
know
that
the
I
at
the
ihp
there
are
multiple
groups.
The
one
I'm
going
to
focus
on
is
the
802
group.
You
know
the
networking
group-
and
you
know
we
mentioned
before
there
was
a
group
called
802e
which
brings
recommendations
for
privacy
in
consideration
in
the
development
of
standards.
B
So
I
want
to
mention
this
one,
because
maybe
we
this
is
one
of
those
where
we
will
want
to
to
have
a
look
to,
but
the
main
two
I
would
like
to
focus
on
are
the
8.11bh
and
bi,
where
many
of
you
have
heard
of
so
they
were
formed
at
the
end
of
of
a
group
of
study
of
privacy
and
the
effect
of
rcm
in
802.11
standards,
and
they
have
two
different
objectives
that
I
will
give
you
and
update
what
they
are.
Bh
is
a
short
term.
B
B
So
sorry
I
mentioned
for
you
to
mention
that
rcm
is
randomized
and
changing
mac
address,
so
rcm
randomized
and
changing
mac
address.
So,
given
that
devices
randomize
and
change
the
mac
address,
what
is
the
effect
on
8.11
service
and
is
there
something
that
needs
to
be
done
in
the
ieee?
A
total
11
group
to
address,
though
the
effect
of
those
mac
address
changes?
The
idea
in
this
group
is
that
the
a
total
11
standard
does
not
allow
a
station
to
change
its
mac
address
while
in
session.
B
So
you
can
change
your
mac
address
between
connections,
but
not
within
a
connection
as
of
today.
But
you
know,
changing
between
sessions
can
have
some
effects.
Like
you
know,
troubleshooting,
you
know
you
have
a
problem
with
your
phone
connected
to
wi-fi
in
the
enterprise
today
you
can
support
tomorrow
morning
and
they
don't
know
who
you
are
because
the
mac
address
has
changed.
So
that's
the
kind
of
thing
they
are
looking
into
in
the
current
status
of
the
group.
B
They
identified,
of
course,
that
you
know
multiple
things
may
be
broken
by
rcm
and
they
have
identified
nine
solutions
which
essentially
are
about
trying
to
pass
an
identifier
between
the
station
and
the
access
point
so
that
if
the
station
changes
its
mac
address
from
one
day
to
the
other
from
one
session
to
the
other,
etc,
it
can
come
back
and
re-express
an
identifier
back
to
the
ap
and
essentially
in
these
nine
proposals.
You
know
some
suggest
that
the
ap
gives
an
identifier.
B
B
They
express
the
intent
to
be
finished
by
the
end
of
the
next
year
and
there's
another
group,
which
is
longer
term
which
is
bi,
and
what
these
people
do
is
that
they
look
at
80.11
and
try
to
identify
if
there
is
a
way
to
augment
the
privacy
of
devices
within
80.11.
It's
obvious
that
anybody
can
sniff
the
network,
so
they
want
to
see
there
are
some
identifiers
sent
in
8
11
frames
that
could
expose.
You
know
the
uniquely
the
identity
of
a
device.
B
You
know
beyond
the
mac
address,
mac
address
being
just
one
of
them
and
of
course
they
identified
tons
of
them.
So
for
now
they
are
going
through
combing
the
standards
and
they
have
try
to
make
requirements
on
what
exactly
should
be
protected
and
against
what.
So,
that's
an
interesting
work
for
us
to
look
at
and,
of
course,
you
know,
their
approach
is
very
much
focused
on
these
first
two
layers.
B
You
know
the
thigh
and
the
back
layer,
so
the
and
that's
what
we
most
of
us
know
right
that
there
are
some
keys
that
you
exchange,
for
which
you
make
an
identification
by
saying,
I'm
reusing
key
number.
55
when
you
rejoin
well,
if
we
identify
the
key,
then
we
may
identify
the
station,
because
that's
the
the
station
that
was
using
keep
55
before
there
is
mac
address
exposure.
B
You
know
you
have
a
header
which
has
a
lot
of
options,
many
of
which
allow
to
uniquely
identify
a
flow
or
the
station,
so
they
are
listing
all
these
exposures
that
they
call
requirements.
You
know
that
the
thing
should
be
obfuscated
at
this
stage.
They
should
finish
by
this
summer
ish
once
they
have
that
they'll
start
looking
into
80.11
and
start
looking
into
what
they
should
do,
what
tech
should
be
brought
into
the
standard
to
alleviate
those
exposure.
B
So
those
two
you
know
for
us
are
probably
interesting
to
look
into
bh,
not
so
much
because
I
think
we
will
find
items
for
us
to
refer
to
because
they
are
looking
at
short
fixes
on
the
ids
to
pass
an
identifier.
But
it's
interesting
for
us
to
realize
where
this
identifier
is
scoped
to
be
limited
to,
and
it's
really
between
the
station
and
the
access
point.
B
When
we
talk
between
station
and
services
in
this
group,
if
we
decide
to
go
there,
so
you'll
find
here,
you
know
these
documents,
the
8011
is
very
open.
So
if
you
go
to
the
second
link,
you
can
access
pretty
much
any
public
document
in
the
working
representations,
contributions,
etc.
The
only
thing
you
cannot
access
is
the
draft
really
of
the
next
standard,
but
you
know
you
don't
need
that.
We
don't
have
any
at
that
stage.
A
A
A
If
there
are
any
so,
it
seems
like
we
have
an
interesting
and
limited
work
to
do,
which
is
also
in
line
with
the
short
lived
task
groups
that
you
mentioned
and,
and
this
one
it
himself
so
perfect
seems
to
me
that
we
have
some
some
interesting
homework
to
do
from
now
till
the
summer
at
least,
and
well.
We
are
at
the
top
of
the
hour
one
minute
over,
in
fact.
So
if
there
are
no
more
questions,
I
encourage
you
to
participate
in
the
list.