►
From YouTube: IETF111-MADINAS-20210728-1900
Description
MADINAS meeting session at IETF111
2021/07/28 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
So
here
is
myself
juan
carlos
to
welcome
you,
together
with
carlos
bernardos,
we're
welcoming
you
and
helping
you
drive
through
this
interesting
discussion.
As
a
reminder,
this
is
the
second
buff
that
we
have.
We
didn't
have
one
at
the
last
ietf.
We
had
a
couple
of
meetings,
but
this
time
is
it's
a
slightly
different
buff,
because
it's
going
to
be
a
wg
forming
buff
and
we're
going
to
get
into
the
the
details
about
it.
A
So
carlos
would
you
mind
going
for
the
next
slide?
Yes,
so,
first
to
get
make
sure
that
you
join
the
the
queue
before
participating.
If
you
raise
your
hand
or
join
the
queue,
we're
going
to
make
sure
you,
you
get
your
spot
and
make
your
comments.
Please
mute
your
mic
unless
you
are
speaking
so
that
we
don't
have
as
much
interference
and
ideally
turn
off
your
video.
A
If
you
are
not
speaking,
you
have
some
instructions
on
how
to
play
with
mythical
on
the
on
the
links
that
is
are
on
the
screen
and
note.
Well.
A
So,
as
any
other
ietf
meeting,
please
make
sure
that
you
are
familiar
with
this
when
you
participate
in
idf,
you
agree
to
follow
the
processes
and
policies
and
please
make
sure
that
if
ever
there's
any
itf
contribution
covered
by
patents
or
patent
applications
that
you're
aware
of
you
make
that
known
to
to
also
the
group
either
by
sending
us
an
email
or
raising
your
voice
at
the
at
the
mic.
A
The
information
that
you
provide
at
this
itf
will
be
handled
in
accordance
with
the
privacy
statement.
It's
going
to
be
public
notes
are
being
taken,
the
meeting
is
being
recorded
and
any
of
these
material
could
be
used
in
a
in
a
litigation
and
ideal
litigation.
If
need
be
so
the
reminders,
as
I
mentioned,
the
minutes
are
taken.
A
The
this
minute
is
being
recorded.
Your
presence
has
already
been
locked,
our
blue
sheets
by
logging
into
the
data
tracker,
and
you
have
a
link
there
to
the
code
emd
also
you
have
it
on
top
on
the
mytheco,
with
the
pencil
and
square
icon.
A
So
please
help
us
take
notes
so
that
we
can
record
good
minutes
and
again
as
a
reminder.
These
minutes
are
going
to
be
public,
so
next
slide.
A
Our
agenda
is,
is
quite
loaded
but
very
interesting,
as
you
will
see.
First
we're
going
to
go
through
a
quick
recap
of
of
the
meeting
the
intro,
the
scope
and
so
on.
So
carlos
and
I
are
going
to
take
care
of
that.
Eric
is
going
to
be
helping
us
here
as
a
supporting
id.
A
A
A
So
that
way
we
can
address
all
your
concerns
and
questions
on
the
background
in
one
shot
and
in
that
one
slot.
After
that,
we're
going
to
move
to
the
use
cases
and
problem
statements
where
jerome
is
going
to
be
presenting
us
with
the
randomize
and
changing
mac
addresses
use
cases,
which
is
his
draft,
providing
a
problem
statement
as
a
baseline
for
the
discussion
here
and
then
we're
going
to
devote
quite
a
bit
of
time
to
the
charter
discussion.
A
There
was
a
charter
already
published
in
the
in
the
list
and
we
are
going
to
go
through
it.
Carlos
and
I
are
going
to
be
running
that
with
the
support
from
our
80s
and
we're
going
to
leave
a
few
minutes
at
the
end
for
the
next
steps
and
all
the
usual
questions
that
we
get
for
above.
A
All
these
are
are
addressing
the
latest
status
on
mac
address,
randomization,
how
to
do
it
and
what
it
implies
and
what
it
affects.
So
that's
the
the
main
purpose
of
this
group
is
to
to
basically
make
a
snapshot
of
what's
going
on
and
to
see
what
is
achieving,
but
also
what
services
are
being
affected
and
if
there
is
something
that
we
need
to
do
about
it.
A
So
for
that
we're
going
to
talk
about
the
present
network
and
application
service
related
issues
that
are
seen
due
to
this
mac
address
randomization
and
as
a
reminder,
market
randomization
is
a
feature
that
allows
to
provide
a
user
privacy.
A
In
this
case,
by
actions
we
mean
coordination
with
other
seos
documenting
use
cases
that
people
are
experiencing
and
identification
of
existing
solutions
or
gaps
for
that
the
purpose
is
going
to
be,
or
the
proposal
is
to
form
a
working
group
that
is
going
to
take
care
of
these
three.
But
as
you
notice,
there
are
no
solutions
for
seeing
our
new
solutions
for
seeing
at
the
moment.
So
there's
no
protocol
work
forcing
for
the
short
term
the
idea
and
we
will
get
into
the
details
of
the
chartered
discussion.
A
We'll
see
that
during
the
charter
discussion,
I
don't
know
if
there
is
any
other
point
that
carlos
eric
would
you
like
to
say
something
at
this.
C
And
nothing
on
my
side
now.
The
really
important
stuff
is
to
to
check
at
the
end
of
this
buff
whether
there
is
interest
in
working
in
this
area,
whether
we
can
achieve
work
and
whether
there
are
people
ready
to
work
on
this
topic.
That's
basically
the
questions
to
be
answered
at
the
end.
A
D
E
Right
so
the
iutf
has
already
dealt
with
mac
randomization
in
a
number
of
processes,
namely
ipv6
address
generation
used
to
be
mac
dependence.
It
was
generated
from
the
mac
address
of
the
device,
but
so
there
are
several
solutions
that
have
been
discussed
over
the
years
for
a
long
period
of
time,
going
back
to
2004
or
something
that
allow
for
ipv6
address
generation
independently
of
the
mac.
E
There's
also
been
discussions
on
macro
randomization
in
terms
of
networking
for
automobiles
like
an
ipwave,
it
comes
up
in
all
of
the
groups.
All
of
the
working
groups
where
you
have
you
know
privacy
concerns
from
before,
but
not
only
mac.
Randomization
is
a
relevant
concern
for
the
ietf
or
has
been
over
the
years.
E
There's
also
a
number
of
other
privacy
initiatives
currently
ongoing
in
the
iitf
that
deal
with
non-mac
and
non-ip
related
identifiers,
like
pair
g
q,
name
minimization
for
dns.
There
is
anonymity
profiles
in
rfc,
7844
and
so
forth.
You
can
find
a
number
of
identifier
related
rfc
reviews
and
also
further
work
in
our
in
the
data
tracker
document
tracing
for
rfc
6973
privacy
considerations
for
protocol
design.
E
If
you're
interested
in
delving
deeper
into
iotf
privacy
work,
including
macro
randomization,
but
not
solely
mac
randomization,
a
number
of
rfc
reviews
have
led
to
privacy
oriented
changes,
and
so
we
see
that
in
many
places
actually
in
the
ietf.
Now,
if
you
want
to
know
more
about
specifically
the
ipv6
address
generation
on
the
various
initiatives
that
are
related
to
this
or
the
unlimited
profiles,
you
can
see
drafts
mac
address
randomization,
which
is
available
in
version
one
at
data
tracker,
and
it
contains
an
entire
chapter
about
the
or
class.
E
A
E
A
Thank
you
very
much
amelia.
So
next
is
the
mac
address.
Randomization
work
at
like
tripoli,
802
and
we'll
have
jerome
presenting.
F
Thank
you
and
I'll
get
out
of
a
mutedness,
then
next
slide,
please.
So
thank
you
very
much.
My
name
is
jerome.
Henry
I've
been
working
at
the
ieee
for
for
a
long
time,
so
I
would
like
to
share
with
you
what's
happening
over
there
in
terms
of
macronutation
and
and
privacy
in
there
are
two
groups.
I
would
like
to
make
you
aware
of
one
which
is
in
the
umbrella
of
a22
in
general,
another
one
which
is
branched
into
two
subgroups
in
the
8
11
working
group.
F
So
in
the
dual
framework,
after
the
work
that
emilia
mentioned
at
the
ietf
in
the
years,
13
and
15,
the.
F
So
this
document,
you
have
a
link
on
on
this
on
the
page
here,
which
essentially
lists
a
certain
number
of
considerations
about
privacy
in
nato
technologies.
F
The
issue
of
randomizing
changing
mac
addresses,
especially
on
the
client
side,
is
not
directly
addressed
there,
but
it's
it's
highly
prevalent
because
you
know
that's
one
of
the
first
thing
that
we
noticed
in
the
communications
that
had
a
bearing
on
privacy.
So
although
this
document
doesn't
make
any
special
provision
about
rcm,
it
does
recognize
that
there
is
a
direct
association
between
the
mac
address
and
a
device,
and
if
this
device
is
a
personal
device,
then
immediately
you
have
a
an
association.
G
F
A
mac
address
and
a
user,
and
you
know
to
respect
privacy.
There
are
certain
number
of
suggestions
that
this
subreconnect
practice
does,
including
one
which
is
to
use
temporary
identifiers
every
time
which
is
possible,
so
that
doesn't
mean
necessarily
mac
address.
But
mac
address
is
definitely
in
many
cases,
an
identifier
and
also
when
you
use
a
temporary
identifier.
F
The
suggestion
is
also
to
make
sure
that
the
identifier
doesn't
remain
beyond
the
need
of
the
communication
or
the
establishment
of
the
communication.
So
somehow
you
know
the
rcm
itself
is
not
described,
but
it
doesn't
know
the
privacy
recognitive
practice
recognizes
that
rcm
is
here
and
likely
to
stay
because
it
allows
you
know
the
implementation
of
these
recommendations.
F
That
group
concluded
its
work
back
in
2019
and
the
spec
was
published
in
2020,
and
you
have
the
link
here
if
you
want
to
have
a
deeper
look
at
it.
Next
slide,
please
in
between
specifically
in
the
8011
working
group,
which
is
you
know,
something
very
sensitive,
grew
very
sensitive
to
those
issues
because,
as
you
know,
wi-fi
communications
happen
over
radio
technologies,
which
means
that
anybody
in
range
of
the
signal
can
read
that
signal
and,
of
course,
some
of
the
signal
content
will
be
encrypted.
F
F
So
in
2019,
a
group
was
formed
which
is
initially
a
topic
interest
group
as
they
call
it
over
there.
That
then
became
a
study
group
sg
to
look
into
this
problem
of
randomizing.
Changing
mac
addresses,
observing
that
many
vendors
were
already
implementing
such
scheme
and
you're
wondering
if
that
had
any
consequence
for
the
802.11
communications.
You
know
with
a
strong
idea.
Probably
it
did
the
conclusion
of
that
group
in
2020
led
to
the
formation
of
two
subgroups,
which
are
you
know
the
ones
I
would
like
to
share
with
you
about.
F
One
is
based
on
the
conclusion
that
a
randomizing
changing
mac
addresses
are
obviously
going
to
be
here
for
a
while,
because
you
know
those
wireless
communications
being
unprotected.
As
far
as
the
mac
address
is
concerned,
in
the
source
or
destination
fields
in
the
header,
handheld
vendors
are
likely
to
continue
implementing
randomizing,
changing
mac
address
schemes
for
their
and
held
devices,
and
the
first
question
that
this
group
was
asking
itself
was:
what
does
that
do
to
8
to
11
communications?
F
F
There
was
an
implicit
assumption
that
one
station
meant
want
one
mac
address
and
as
soon
as
you
decouple
the
station
from
the
mac
address,
strange
things
may
happen
or
maybe
not,
but
we
were
not
sure
and
because
the
spec
is
fairly
long.
It's
about
400
or
4000
pages.
There
was
the
first
group
that
was
created.
A
211
bh,
which
name
as
you
see
on
the
screen
is
enhanced.
F
Services
with
randomized
mac
address
was
to
go
through
a
series
of
use
cases,
services
that
you
know
the
group
thought
were
necessary
to
the
implementation
or
the
good
implementation
of
the
good
operations
of
11
and
that
might
be
affected
by
8
to
11,
sorry
by
randomizing.
Changing
mac
addresses.
F
So
what
the
group
is
ongoing
right
now
is
examination
of
these
services
that
you
know
are
a
total
event
services
and
looking
to
use
cases
where
rcm
may
have
an
impact
into
the
efficiency
of
these
services
and
every
time
it's
possible,
you
know,
suggest
solutions
to
alleviate
those
issues.
So
the
goal
is
not,
you
know
to
recommend
not
doing
rcm
right.
The
idea
that
rcm
is
here
so
the
goal
is
not
to
diminish
privacy
or
or
negate
the
rcm
process.
F
By
just
observing
that
it's
there
try
to
assess
if
there
are
some
modifications
of
eight
to
eleven
that
could
be
done
within
the
next
year
or
two
to
make
sure
that
the
operations
of
8011
would
continue
smoothly
even
in
the
presence
of
11..
So
as
you
see
at
the
bottom,
the
group
is
expected
to
have
its
work
done
within
two
years,
which
is
you
know,
fairly
short
for
the
eight
to
eleven
world.
F
Next
slide,
please,
and
then,
at
the
same
time,
the
same
same
group
recognized
that
because
the
a2011
communication
happens
over
wireless
communications
and
because
you
know
an
observer
can
see
some
of
that
traffic
and,
although
you
know
some
of
the
traffic
payload
may
be
encrypted,
there
is
probably
a
bearing
in
8011
about
privacy.
That
needs
to
be
examined.
F
So
a
second
group
was
formed
which
is
802.11bi,
which
is
also
you
know
the
result
of
this
tig
and
sdg
work.
That
now
looks
more
precisely
into
how
can
we
modify
a211
to
enhance
privacy,
while
still
you
know
maintaining
services?
So
the
goal
here
is
to
look
into
it
even
say:
can
we
make
it
work
and
improve
privacy
at
the
same
time?
So
you
know
the
goal
here
is
to
look
into
what
8011
communications
entail
and
look
at.
F
If
there
are
some
elements
here
that
could
be
augmented,
improved
to
increase
the
privacy
when
we're
looking
at
personal
devices.
So
you
know
there
is
a
some
some
overlap
somehow
in
the
scope
between
these
two
groups,
but
you
know
they
are
very
distinct
in
the
event
mine
11bh
is
looking
at
rtm
is
here:
does
it
break
anything
in
82.11
and
can
we
fix
these
things
so
that
it
even
continues
working
even
when
rcm
is
in
place,
whereas
802.11
bi
is
saying?
Well,
we
know
a
total
11
communications
happen
over
the
year.
F
F
next
slide,
please,
if
you're
interested
in
looking
into
those
groups
and
their
documents,
please
be
aware
that
the
802.11
policies
that
all
the
documents
contributions
to
the
groups
are
publicly
accessible.
They
know
the
draft
of
the
documents
are
not
accessible
to
everyone,
but
every
contribution
that
is
made
to
any
group
is
publicly
accessible.
F
So
we
have
on
the
slides,
a
few
pointers
for
you
to
look
at
the
timelines
as
they're
being
revised
and
the
documents.
If
you
want
to
look
at
what's
going
on
and
of
course,
I
would
like
to
point
again
to
the
azure
mac
address
from
the
middle
draft,
because
in
this
draft
you
will
also
see
what
are
the
current
rcm
schemes,
which
are
implemented
by
handheld
vendors.
You
know
that
make
8011
devices
that
are
personal
devices,
I'll
post
there
and
go
back
to
muteness
as
well.
Thank
you.
A
H
I
think
I
must
have
the
wrong
microphone.
Sorry
about
that.
H
Okay,
skip
that
one.
Thank
you
and
move
on
to
the
next
super.
Okay.
So
at
the
wba
we
don't
tend
to
address
things
in
quite
such
a
technical
way,
we're
more
looking
at
the
technologies
as
being
of
use
to
our
members.
We've
been
watching
mac
randomization
for
a
couple
of
years,
and
it's
become
apparent
that
now
devices
are
starting
to
use
it
and
it's
starting
to
become
a
problem.
A
So
sorry
tim,
we
would
would
it
be
possible
to
you
to
speak
even
louder
or
closer
to
the
mic.
It's
very,
very
faint.
We
can
hear
you
but
very,
very
quick.
A
Yeah
we
have,
we
are
doing
well
with
agenda
time,
so
I
I
see
there's
about
a
settings
icon
on
the
top
right
to
change
devices.
I
don't
know
if
this
could
help.
H
H
Okay:
it's
it
appears
that
the
web
session
is
overriding.
The
laptops
settings.
Yes,
okay,
sorry
about
that
right.
So.
H
Sure,
yes,
so
just
quickly,
we've
been
watching
mac
address
randomization
for
a
couple
of
years
and
it's
starting
to
become
an
issue
for
various
sectors
of
our
members,
and
so
we've
set
up
a
project
to
examine
the
issues
and
to
look
at
what
alternatives
there
are
available
to
use
for
session
management
and
authentication
and
such
like.
H
Its
aim
is
to
find
alternative
means
so
that
mac
addresses
don't
get
used
beyond
their
legitimate
per
session
use
and,
amongst
the
things
that
we
intend
to
do
is
to
liaise
with
all
the
other
standards
bodies,
all
who
are
working
on
these
issues,
because
we
don't
tend
to
actually
produce
standards
ourselves,
but
to
look
at
how
they
work.
Look
at
the
end-to-end
journey
for
the
users
and
make
recommendations
so
we're
going
to
analyze
the
available
solutions,
find
gaps
and
such
like
and
document
the
problems
and
then
recommend
technologies.
H
Please
so
what
we've
done
so
far,
we've
started
off
looking
at
the
problem
statement,
you
know
investigating,
where
mac
addresses
are
used
and
for
what
purposes
and
and
what
issues
these
this
causes,
and
we've
done
that
already
and
we
have
supplied
a
document
to
the
ietf
and
the
wfa,
with
some
of
the
results
of
those
studies
going
on
from
there.
We've
looked
at
those
those
issues
that
have
been
raised
to
identify
what
the
actual
identification
requirements
are,
whether
they
are
for
devices
as
mac
addresses
normally
do
or
whether
they
are
for
users.
H
So
we've
done
that
phase
and
we're
currently
examining
the
existing
solutions
that
are
out
there
or
solutions
that
do
not
rely
on
a
permanent
mac
address
and
how
they
can
be
used
for
networks
and
the
the
management
and
operation
of
networks.
So
these
are
things
like
802.1x
passpoint,
open
roaming
for
other
cases,
maybe
dpp,
and
there
are
other
less
standardized
things
like
identifying
the
user
through
an
app
they
put
on
their
mobile
device.
H
So
we're
currently
looking
at
all
those
and
seeing
what
they
can
provide
in
terms
of
identification
and
what
they
can't
provide
and
how
much
they've
been
standardized.
So
next
slide,
please
so
that's
where
we've
currently
got
to
and
we're
just
starting
work
on,
seeing
how
these
various
standard
technologies
work
and
how
they
fit
the
requirements
of
various
sectors.
H
And
whilst
we're
doing
that,
we
expect
to
find
that
there
will
be
requirements
from
the
network
providers.
The
network
operators
that
will
not
be
met
and
we
hope
to
identify
those
at
the
same
time
and
at
that
point
certainly,
we
would
want
to
be
coming
back
to
standard
bodies
like
the
ietf,
with
those
issues
and
discussing
them
and
seeing,
if
there's
anything
that
can
be
done
to
resolve
them.
A
So
this
is
the
the
the
end
of
first
three
presentations
and
then
we're
going
to
move
on
to
two
questions.
There
are
multiple
discussions
already
going.
G
A
On
the
chat,
but
I'm
not
sure
the
presenters
are
are
following
necessarily
so
I
would
invite
you
to
come
up
to
the
mic
and
ask
if
you
have
any
questions
to
either
emilia
on
the
working
itf
jrom
on
the
work
at
nitric,
802
or
tim
on
the
work
on
wireless
broadband
alliance.
A
I
Invitations
to
at
least
they
always
brought
me
up
to
spee,
I
heard
in
the
beginning.
One
of
the
one
of
the
focuses
of
the
boss
of
the
future
working
group
would
be
around
liaison
liaisoning
with
different
kind
of
groups.
Could
any
of
the
previous
kind
of
speakers
who
were
representing
the
ieee
work
or
the
wireless
broadband
lines
talk
about
what
that
lies
in?
What's
that,
what's
the
substance
of
that
liaison
with
the.
H
Itf,
okay,
well
I'll,
give
that
a
go
from
my
side
and
already
we
have
presented
the
analysis
of
sorry
just
a
second,
the
analysis
of
the
uses
of
mac,
identif
mac
as
identifiers
and
the
problems
they
pose.
H
This
is
the
typical
kind
of
liaison
we
would
do,
but
you
know,
if
you
have
similar
problem
case
problem
statements
or
issues,
then
we
would
be
quite
happy
to
receive
those
and
read
those
and
between
us
discuss
the
issues
and
I
think
for
us
it's
about
clarifying
that
the
problems
that
are
caused
by
mac
randomization
and
how
the
operators
of
the
networks
can
resolve.
H
A
If
I
may
add
here,
I
think
that
there's
also
probably
you
know,
roman-
that
there's
also
an
iab
ieee
coordination
group
that
it's
been
going
on
for
a
while.
So
over
there.
We
make
sure
that
whatever
new
work
related
from
one
organization
to
the
other,
it's
been
addressed
commented
and
if
ever
communicated
you
know
to
to
the
group
so
that
we
can
coordinate
and,
of
course
avoid
any
overlap
in
the
work.
A
So
that
would
be
clearly
also
something
that
madina's
could
interface
with
ieee
802
and
maybe
jerome
can
provide
more
information.
But
I
think
at
this
point,
it'll
be
important,
especially
because
there's
ongoing
work
in
I
triple
eight
or
two
right
now
the
to
make
sure
that
that
is
taken
into
account
before
any
any
suggestions.
Bcps
or
anything
else
is
suggested
that
the
ietf
side.
F
That
actually
works
at
layer.
Two
itf
works
with
upper
layers.
It
feels
that
it's
important
to
communicate
on
challenges
which
we
see
on
outside,
because
you
know
there
are
clearly
dependencies
on
each
other.
So
it's
useful,
you
know
to
avoid
overlap
and
to
avoid
gaps
where
you
know
one.
The
stu
might
think
that
the
other
is
likely
to
take
care
of
something
and
vice
versa.
So
you
know
making
sure
that
we
communicate
extensively.
F
I
think
is,
is
very
important
and
I
I
must
say
you
know
I'm
vice
chair
of
iterative
mbi,
but
I
speak
here
as
a
as
a
as
an
active
participant.
This
is
not
in
an
official,
you
know
it's
a
given
ieee
statement,
but
those
liaisons
will
help.
You
know
smoothen
this
communication
between
this
group
and
streamline.
You
know
the
joint
efforts.
I
think.
A
A
G
I
guess
I'll
just
add
some
color
to
what
I
said
at
the
chat
I
mean.
I
think,
essay
password
is
often
left
out
of
these
discussions,
because
no
vendor
has
implemented
it
just
because
a
vendor
hasn't
implemented.
It
doesn't
mean
it's
not
a
solution
to
the
problem.
I
think
that's
why
we
ended
up
in
a
lot
of
these
messes
to
where
we
are
today
right.
G
If
there's
an
easy
way
to
do
something,
people
will
take
that
road
and
it
doesn't
push
adoption
of
more
secure
ways
to
do
things
and
so
like
between
passport
and
sae
sc
password
id.
We
have
a
solution
and
dpp.
We
have
a
solution
for
everything
right
and
to
to
continue
to
try
and
keep
anything
about
mac
based
identification
alive.
We'll
just
continue
to
continue
this
problem
right,
so
I
guess
I
I
still
struggle
at
what
this
group
is
eventually
trying
to
solve.
A
So
so
this
group
is
just
to
answer
that
one
last
point
is
trying
to
solve
those
questions.
So
if
ever
there
are
solutions
existing
that,
that
would
be
clearly
in
the
scope
of
this
group
to
to
highlight
them
and
mention
that
these
are
the
solutions
to
be
taken.
But
for
that
we
need
to
for
sure
first
do
the
the
problem
statement
and
and
gap
analysis
to
make
sure
that
first
we
agree
that
there's
a
problem
across
all
the
different
seos
that
we
analyze
these
solutions,
the
ones
you
mentioned,
and
maybe
some
others.
A
Why
not
and
then
we
can
decide
if
if
there
are
gaps
or
not,
if
there
are
no
gaps,
then
perfect,
we
just
mention
it
clearly
in
a
document
and
say
there
is
a
solution:
it's
just
that
it's
not
being
implemented,
but
there
is
a
solution
and
we
strongly
suggest
you
to
implement
it
or
there
are
solutions
for
x,
number
of
use
cases,
but
there's
still
one
remaining,
which
may
require
some
extra
work,
and
at
that
point
the
question
will
be
open.
What
would
be
that
work
and
who
should
do.
A
A
So
jerome
is
going
to
give
us
an
update
on
about
his
draft.
F
Thank
you.
Thank
you
very
much
and
and
sae
if
anybody
is
interested
is
extensively
discuss,
11bi,
so
it's
its
solutions
and
its
challenges
are
very
much
discussed
there.
So
this
draft
you
know,
goes
of
course
beyond.
You
know
eight
to
the
11
statements
and
what
we
try
to
do
is
to
look
at
the
rcm
problem
statement
a
little
bit
more
in
detail
and
also
look
at
you
know
some
perform
some
some
minimal
cap
analysis
about
what
the
current
requirements
are
about
next
slide,
please
so
and
next
slide.
F
So
in
that
context
we
wanted
to
have
a
document
that
would
analyze
the
use
cases
that
rcm
you
know
brings
in
terms
of
effect
affecting
network
services
and
affecting
user
experience
and
also
at
least
no
requirements
associated
to
rcm
that
we
could
use
as
a
foundation
for
us
to
to
continue
working
on
that
analysis
of
what
is
there
and
what
may
not
be
there.
So
we
have,
of
course,
a
link
to
the
draft
here.
If
you
want
to
have
a
look
and
of
course
the
feedback
is
always
welcome.
F
Next
slide,
please,
in
that
context,
if
I
go
through
the
document
briefly,
what
we're
doing
is
that
we
are
trying
to
organize
a
little
bit
our
thoughts
around
rcm
by
trying
to
triage
the
contributing
elements
around
the
discussion
around
rcm.
The
first
is,
you
know:
user
versus
device
steam
shared.
You
know
in
wba
many
times
the
cases
of
identifying
the
user
not
identifying
the
devices
so
distinguishing
cases
where
we
talk
about
the
device
and
what
we
talk
about
the
user
is
one
thing
we
do.
F
So
organizing
or
thought
about
you
know
the
issues
around
those
different
types
of
elements
is
all
something
we
try
to
do
and
of
course
you
know
our
cm
is
to
protect
privacy
against
people
if
dropping
or
them,
and
we
would
try
to
list
who
are
these
them
that
you
know
may
invade
on
on
privacy,
and
there
are
multiple
actors
that
we
try
to
list
up
may
have
a
say
or
an
action
into
the
communication
structure
of
any
device
implementing
rcm.
So
there
are
some
functional
network
entities.
F
You
know
the
access
point,
wireless
switches,
all
these
things
and
there
are
also
some
human
related
entities.
You
know
people
managing
your
wi-fi
if
you
are
in
a
shared
home
home
structure,
for
example,
and
also
observers.
You
know
that
may
be
there
for
multiple
reasons
to
troubleshoot
things
or
to
spy
on
you
and
they
may
be
over
the
air.
They.
F
They
may
be
inside
the
network,
they
may
be
outside
the
network
on
the
internet,
so
we
try.
You
know
to
organize
those
different
elements
and
and
you'll
at
least
name
them
so
that
we
could
refer
to
them.
As
we
look
into
what
solutions
are
there,
what
problems
are
there
and
what
requirements
are
there
next
slide?
Please?
In
that
same
logic,
we
also
try
to
look
into
what
is
rcm
trying
achieving.
F
What
is
the
the
trust
variable
that
that
comes
into
this
privacy
protection,
and
we
find,
of
course,
that
there
are
many
different
scenarios.
There
are
scenarios
where
you
know
users
have
full
trust
into
some
of
these
entities
or
all
of
them.
Maybe
some
scenarios
where
users
have
trust
in
some
of
these
entities,
but
not
some
others
and
some
scenarios
where
there
is
absolutely
no
trust,
and
there
is
a
strong
will
to
obfuscate
the
user
identity
or
decouple
it
from
the
device
from
from
all
the
the
users.
F
Sorry,
the
all
the
actors-
and
that
brings
us,
of
course,
to
the
notion
of
environment,
and
we
find,
of
course,
different
types
of
environments
that
we
want
to
list
in
this.
These
drafts,
where
we
say
you
know
the
home
environment,
is
probably
very
different
from
a
public
venue.
You
know
a
hot
spot
in
airports
in
terms
of
who
is
there,
who
is
doing
what
and
who's
watching
what
same?
If
you
have
an
enterprise
where
you
have.
G
F
Mdm,
you
know
management
managed
device
provided
by
the
enterprise
the
requirements.
There
are
probably
very
different
from
again
a
report
or
some
some
place
like
that.
So
we
try
to
list
those
elements
together
and
also
as
far
as
rcm
is
concerned,
we
try
to
list
the
elements
that
are
using
the
mac
address
today,
for
you
know,
multiple
reasons,
practical
reasons
being
most
of
them.
F
You
know
from
the
ap
who
needs
to
know
who
is
connected
and
respond
to
whom
you
know
the
services,
like
the
http
dot,
one
x,
hr,
routers,
all
the
things
that
use
today
the
mac
address
to
try
to
identify
stations,
and
then
you
know
we
try
to
go
into
the
assumptions
into
rcm
and
that's
the
next
slide,
which
brings
us
to
the
requirements
that
we
conclude
about
to
say
when
we
are
we're
looking
at
rcm
next
night,
please,
there
are
a
few
things
that
we
we
need
to
to
make.
F
Sure
first,
one
is
that,
although
we
have
all
these
elements
which
are
going
to
help
us
guide,
you
know
our
reflection.
You
know
the
network
should
not
make
any
assumption
that
you're
going
to
say
you
know,
don't
randomize
your
mac
and
you
know
that's
something.
We've
seen
a
lot
in
literature
over
the
last
year.
So,
where
you
know
simple
solution
was
like
don't
randomize
the
mac,
you
have
nothing
to
hide
in
that
kind
of
thing,
so
we
said
well
that
cannot
hold
it.
Just
it
doesn't
happen.
Also.
You
know.
F
We
assume
that,
because
rcm
happens,
rcm
should
be
expected
to
happen,
because
it's
likely
to
continue
to
be
that
way,
even
when
services
are
are
used,
and
of
course
you
know
if
a
service
is
used
and
the
mac
changes
and
that
services
uses
the
mac
address.
Well,
that
may
cause
some
service
interruption
and
you
know
there
may
need
to
be
something
there
to
you
know
address
what
happens
there.
Maybe
the
service
breaks
and
that's
okay.
F
Maybe
there
is
a
recovery
mechanism
that
exists,
maybe
or
maybe
not
that's
something
probably
interesting
to
look
into
to
to
you
know
evaluate
what
happens
in
that
case,
and
of
course
you
know,
the
mac
address
is
not
necessarily
the
identity,
so
we
also
try
to
make
this
distinction
in
the
requirements
to
to
avoid
confusion.
A
next
slide,
please,
which
brings
us.
F
You
know
to
thank
you
to
to
the
conclusion
of
of
the
draft
where
we
say
well,
based
on
all
these
elements
that
could
be
used
as
a
vocabulary
convention
between
people
interested
in
that
matter.
We
can
start
looking
at
different
use
cases
and
try
to
different
look
at
the
different
standards
where
mac
address
is
used
and
where
rcm
may
have
an
impact
and
try
to
organize
our
work
by
you
know,
thinking
these
different
environments
and
see
if
there
are
different
different
challenges,
this
different
trust
level
etc.
F
Maybe
doing
so
will
allow
us
to
evaluate
different
impacts,
evaluate
that
there
are
maybe
some
already
mechanisms
in
those
standards
or
protocols
that
you
know
allow
us
to
function
very
well
without
rcm
and
as
a
jc
was
saying.
Maybe
it's
just
about
you
know
putting
up
some
bcp
or
a
best
practice
document
to
say.
Well,
there
is
a
solution.
Just
do
this
and
it
solves.
You
know
your
problem
for
this
and
that
service
in
this
in
that
environment.
F
Maybe
there
are
some
secure
mechanisms
that
can,
you
know,
be
used
with
rcm,
and
maybe
there
are
some
mechanisms
that
may
make
rcm
less
disruptive
for
services
for
which
we
do
not
want,
or
we
think
that
disruption
may
be
damaging
for
the
user
experience
or
the
service
efficiency.
So
all
this
you
know
maybe
something
we
can
evaluate
by
looking
at
these
different
scenarios:
different
use
cases,
organizing
these
different
vocabularies
etc.
F
G
F
In
the
previous
buff
and
in
a
few
meetings
as
well,
so
we
think
we
start
having
a
good
series
of
input
about
these
different
scenarios
that
we
try
to
to
assess
and
organize
our
thoughts
against.
But,
of
course
you
know,
as
usual,
we
welcome
very
much
any
additional
feedback
and
additional
input
to
try
to
structure.
You
know
this
document
in
the
way
it
can
be
useful.
F
You
know
to
people
working
in
the
field
of
rcm
and
trying
to
you
know,
have
a
statement
a
bit
more
or
granular
than
saying
you
should
never
hide
your
mac
address,
because
you
have
nothing
to
hide,
which
is
you
know
a
bit
too
generic
or
you
should
hire
your
mac
address
from
everybody,
always
because
if
they
are
bad
and
they
want
to
get
you,
we
should
also
be
to
generate.
So
we
hope
that
trying
to
organize
a
little
bit
around
those
different
structure,
we'll
have
better
assess.
F
F
F
Okay,
no
thank
you,
which
may
be
a
sign
that
you
know
either
everybody
has
read
the
draft
multiple
times
and
you're
tired
of
hearing
me
talking
about
it
or
it's
the
first
time
you
read
about
it
in
both
cases.
Please
read
it
again.
If
you
have
a
chance-
and
you
know
as
usual,
every
feedback
is
very
welcome.
F
E
Yes,
I
would
so
I
have
a
question
relating
to
requirement.
Eight.
E
Which
is
relating
to
association
or
post-association,.
E
So
identify
a
secure
mechanism
for
the
device
to
notify
the
network
prior
to
updating
the
mac
address.
Does
this
concern
pre-association
or
post-association
notifications.
F
So
maybe
what
I
should
do
is
and
read
it
again,
so
so
in
that
section,
thank
you
amelia.
Thank
you
very
much
in
that
section,
8
3
6.
There
is
a
requirement
formulation
as
we're
looking
at
in
the
in
the
last
slide.
So
we'll
list,
you
know
eight
requirements
that
we've
assembled
so
far
that
you
know
we
think
rcm
brings
and
our
requirement
number
eight.
Let
me
read
it
again-
is
identify
a
secure
mechanism
for
the
device
to
notify
the
network
prior
to
updating
the
mac
address.
F
So
what
this
is
is,
of
course
it
follows
the
previous
requirement,
where
we're
saying
if
there
is
a
service
which
is
ongoing
provided
to
that
station
and
that
device
and
that
device
only
changes
its
mac
address
that
may
be
disrupting
this
service.
So
in
that
case
it
may
be
useful
if
the
the
device
in
the
interaction
of
service
disrupts
the
network
operation
and
or
the
user
experience
on
the
device.
F
So
if
there's
such
disruption,
what
this
requirement
number
eight
says
so
maybe
we
should
look
into
whether
there
is
already
an
existing
mechanism
that
would
allow
the
mobile
device
to
say
hey.
You
know
I'm
going
to
change
my
mac
for
the
others,
but
to
you
I'm
going
to
tell
you.
This
is
still
me,
so
we're
looking
at
whether
this
a
type
of
a
possibility
exists
there.
So
we're
not
necessarily
looking
at
802.11
in
particular.
F
So
therefore,
association
or
not
association
is
is
not
the
target
here
is
to
say:
if
we
don't
want
to
have
a
poor
user
experience-
and
you
know
the
mac
address,
rotation
may
be
disrupting
the
service.
Are
there
in
those
standards
we'll
be
looking
into
some
existing
mechanism?
That
would
alleviate
the
disruption
by
you
know,
providing
this
information
in
the
events
so
that
that
particular
service
would
not
be
interrupted
from
the
user
standpoint.
A
This
all
right,
so
thank
you
very
much
for
that
presentation,
your
home
and
the
clarifications.
So
the
next
point
in
the
agenda
is
the
charter
discussion
and
we
have.
A
We
have
posted
the
latest
version
on
the
on
the
list
and-
and
it's
also
something
you
can
find
in
the
in
the
materials
well
basically
here
on
the
on
this
slide
set.
So
carlos,
would
you
mind
going
to
the
to
the
next
slide
the
charter?
The
idea
here
is
to
discuss
the
charter,
and
for
that
we
are
going
to
split
it
into
into
different
sections,
starting
from
the
the
intro
the
scope
and
then
going
into
into
the
actual
plan
for
the
for
the
working
group,
so
that
it's
easier
for
everyone.
A
A
Then
the
first
part,
the
introductory,
I
think
it's
pretty
straightforward,
it's
just
stating
what
mac
address
randomization
is
and
and
for
that
we
define
that
in
this
case,
by
mac
we
mean
the
the
link
layer
address
using
i802
technologies.
That
was
originally
something
assigned,
as
you
may
know,
historically,
by
the
ieee
registration
authority.
Community
iraq
for
globally
unique
mac
addresses,
of
course,
starting
from
ethernet.
A
That's
the
the
source
and
the
birth
of
the
of
the
user
of
mac
address,
but
that
evolved
over
time
into
other
use
cases,
notably
wireless,
and
then
802.11
made
it
so
popular
that
now
we
have
almost
every
one
of
us,
a
few
mac
addresses
on
our
bodies
and
since
then,
of
course,
the
the
paradigm
changed,
because
from
being
a
an
address
that
was
linked
to
to
a
just
a
network,
a
network
card.
Well
now
we
had
it
or
a
network
interface.
A
For
that
reason,
then,
the
idea
of
of
changing
this
identifier
started
popping
up,
as
we
heard
from
2013
14
15,
the
work
that
we
started
doing
in
ieee
and
ietf,
and
therefore
the
paradigm
has
started.
Shifting
mac
addresses
now
are
being
randomized,
and
we
in
in
the
draft
at
the
million
percent
that
we
we
show
how
some
operating
systems
are
actively
randomizing
mac
addresses
nowadays,
which
is
good
thing
for
privacy,
but
not
such
a
good
thing
for
certain
services
that
we're
relying
on
the
long-lasting
nature
of
these
identifiers.
A
A
As
I
said,
the
idea
of
this
working
group
would
be
to
examine
the
the
effect
of
this
randomizing.
Changing
mac
addresses
on
network
and
application
services
in
scenarios
that
are
relevant
so,
for
instance,
specifically
where,
where
identity
of
the
device
or
the
user
is
required,
where
it
is
not
required
in
in
case
where
the
personal
device
identity
stability
is
desirable.
A
A
Regarding
the
time
frame
and
inter
seo
coordination-
and
we
had
a
question
about
that-
the
idea
is
to
work
together
with
relevant
working
groups
first
inside
ietf,
such
as
bhc
and
interior,
and
also
liaise
with
other
seos
such
as
I
triple
e82,
and
the
wireless
broadband
alliance
wba
and
coordinate
on
these
recommendations
and
potential
follow-up
activities
within
or
outside
the
ietf.
A
For
that
we
expect
the
working
group
to
be
a
short
time
frame.
We
don't
think
that
this
would
take
too
long,
so
we
are
forcing
some
12-18
months
to
quickly
assess
these
needs
and
publish
a
couple
of
solutions
based
documents,
if
ever
recharging
processes
identified
as
necessary,
so
just
to
clarify
here,
and
we
will
see
that
in
the
deliverables,
the
idea
is
not
to
get
into
solution
in
the
sense
of
producing
protocol
work,
but
rather
just
work
on
problem
statements
and
gap
analysis
at
this
moment.
A
So
if
we
can
move
to
the
next
slide,
the
deliverables
then
proposed
would
be
that
informational
problem
statement
document,
including
use
cases
and
analysis
and
requirements.
A
The
informational
mac
address
randomization
analysis
document,
for
which
we,
both
for
both
we
have
a
baseline,
already
and
potentially
a
best
common
practices
document.
If
we,
if
we
can
find
solutions
that
are
relevant
to
the
to
the
problem
statement
defined
before
so,
with
that
we
move
on
to
discussion
on
the.
A
I
Pack,
the
deliverables
based
on
what
was
previously
stated.
So
what
we're
teeing
up
is
that
the
macro
problem
statement
is
that
previously
different
things
relied
on
static,
mac
addresses
and
now
they're
they're
kind
of
changing,
and
so
you
know
we
need
we
need
to.
We
need
a
mechanism
to
kind
of
deal
with
that.
So
we
know
that
macro
problem
statement.
We
don't
need
more
investigation
of
that.
The
challenge
is
that
on
a
per
protocol
basis,
we
need
to
explore
what
that
means
and
that's
the
intent
of
the
informational
document.
A
A
What
are
the
problems
that
are
being
faced
on
different
arena
with
the
respect
to
to
randomizing
the
mac
address,
for
that
we
are
going
to
analyze
different
use
cases
and
for,
for
instance,
we
we
have
talked
about
home
use,
case
roaming,
use
case
or
hotel
use
case,
enterprise
use
case
and
so
on,
which
are
different,
very
different
scenarios
that
require
different
analysis
of
of
the
of
the
identifiers,
the
users
and
so
on,
and
then
from
that,
we
the
ideas
to
the
right,
the
the
requirements
to
to
both
preserve
the
privacy
and
also
continue
delivering
the
the
services,
the
expected
services
from
from
the
user.
A
So
in
the
from
that
point
of
view
yeah
the
problem,
the
problem
statement,
ideally
would
include
all
those
and
as
well
as
potential
solutions
that
can
be
used
to
to
address
the
the
issues
that
may
be
experienced
these
days.
Does
that
does
that
answer
your
question.
I
A
So
the
analysis
document
we
before
maddiness,
we
started
doing
a
snapshot
because
the
the
mac
address-
randomization
topic
keeps
coming
back
every
every
year
or
so
after
after
the
work
started
in
2015
or
so
and-
and
the
question
is
always
like-
is
this
being
addressed
our
operating
systems
implementing
it?
What
is
it
breaking?
Is
it
breaking
everything?
No,
it's
actually
working
and
so
on.
A
So
so
we
wanted
to
just
provide
an
informational
snapshot
of
what
happens
today
in
the
different
for
and
everything
regarding
market
rates
randomization,
so
that
we
know
at
least
what's
going
on
in
that
that
document
for
that
we
have
a
baseline.
This
is
drax
uniga,
the
one
that
amelia
presented
an
update,
but
but
it
includes
not
only
itf
also,
it
includes
a
work
in
ieee
and
elsewhere.
A
So
even
some
some
some
information
about
what
has
been
implemented
in
certain
operating
systems,
for
instance,
so
so
again,
hundred
percent
information,
informational
and
just
providing
facts.
What
what
is
happening
today?
What
is
going
on
what
what?
What
is
the
status
so
so,
from
that
point
of
view,
it
complements
the
the
former
in
the
sense
that
the
the
the
former
will
say.
Okay
mark
addresses
are
changing,
but
it
may
get
into.
I
I
I'm
hypothetically
speaking
here.
A
Some
use
cases
are
experiencing
something
that
other
use
cases
are
not
experiencing
and
then
is
that
going
to
continue.
Is
that
going
to
evolve?
Is
that
the
problem
going
to
get
worse?
Is
the
problem
going
to
get
fixed
that
we
don't
know,
we
don't
have
an
answer
and
that
that
I
guess,
is
something
that
the
the
former
the
first
document,
the
problem
statement,
could
get
into
beyond
what
is
today
then
for
the
third
one.
The
best
common
practices
is
indeed,
as
we
we
heard
already.
A
There
are
a
couple
of
solutions
that
are
not
being
implemented,
so
we
need
to
make
a
a
detailed
analysis.
Is
this
a
is
this
an
actual
solution,
addressing
multiple
of
the
issues
that
we
are
talking
about?
Then
then,
let's
highlight
it
and
and
and
recommend
it
strongly
because
it
may
be
there,
but
no
one
is
using
it
or
one
seo
is
not
aware
of
it,
because
it's
been
developed
by
another
seo,
for
instance.
A
I
don't
know
that
that
that
ideally
would
be
the
work
of
this
working
group,
and
that
would
be
reflected
in
the
first
deliverable.
The
problem
statement
and
gap,
analysis
document.
F
C
Roman
question,
I
think
the
name
of
problem
statement
is
maybe
a
misnomer.
It's
more
like
a
current
situation.
What's
happening
right
now
and
you
have
a
draft.
This
is
not
mistaken.
That
states
yeah
on
this
operating
systems
on
this
device,
that's
changing.
As
far
as
I
know.
C
Every
time
you
associate
to
a
new
access
point
for
this,
and
this
reason
so
not
only
I
define
some
protocols,
but
we
need
to
say
as
well
whether
they're
implemented
and
getting
the
status
of
ieee,
bi
and
bh
could
be
interesting
as
well,
so
maybe
in
the
charter.
We
need
to
change
the
informational
problem
statement
into
something
else.
Then
problem
statement
here.
A
So
yeah,
if
that
helps
clarification
for
sure
we
have.
We
have
two
documents
right
now,
one
one
that
is
providing
the
snapshot
of
what
what
is
the
status
of
specifications
and
situations
in
different
sdos
and
as
well
as
operating
systems.
A
We
have
that
one
document
and
then
we
are
proposing
to
work
on
another
document
that
will
highlight
the
issues
that
are
being
faced
in
different
use
cases.
A
So
yeah
whatever
makes
those
two
documents
clear
from
from
the
content
point
of
view
and
and
changing
the
title
would
should
not
be
an
issue,
but
that's
something.
Definitely
we
can.
We
can
do
if
that
helps
date.
D
Yeah
so
same
point,
I
find
the
description
of
the
first
things
there
to
be
confusing.
If
not
overlapping,
one
approach
would
be
to
rename
both
of
them
to
say
you
know,
one
of
them
is
use
cases
and
the
second
one
is
actually
a
problem
statement.
Another
approach
would
be
to
combine
those
and
the
milestones,
because
what
working
groups
are
allowed
to
do
should
this
become
a
working
group
is
that
you
could
have
multiple
documents
that
address
the
same
milestone.
D
It
says:
okay,
well,
the
working
group
decided
to
take
this
milestone
and
split
into
two
documents
and
not
bake
into
the
charter
that
these
have
to
do
that
have
to
be
had
to
be
two
different
documents
right,
so
you
could
combine
those
two
and
say
they're.
Both
aspects
of
the
problem
statement
only
put
one
in
a
charter
that
we've
done
a
couple.
Other
working
groups.
J
Hi
yeah,
I
I
mean
I'm
whether
the
first
two
or
one
or
two
documents
or
so
forth.
I
think
that's
all
fine.
I
think
it's
good
to
describe
the
issues
people
are
encountering
and
how
they're
done,
but
I'm
still
a
little
confused
about
what
happens
after
that.
You
know.
Is
there
going
to
be
something
developed?
That's
an
alternative
to
the
way
people
use,
fixed
mac,
addresses
or
recommendations
to
not
use
random
mac
addresses,
or
I
I'm
not
exactly
sure
what
the
step
is
beyond
sort
of
providing
information
on
the
the
problem.
A
So
for
that,
I
think
your
question
and
I
would
maybe
defer
to
jerome
to
to
complement,
but
I
think
that
that
is
what
is
being
discussed
in
nitric,
booleago,
2,
bh
and
bi,
so
it
was
already
addressed
by
802e
in
the
sense
that
they
were
highlighting
privacy
issues,
but
bh
and
bi
are
specifically
talking
about
what
to
do
with
the
mac
address,
because
that's
their
real.
A
What
we
want
to
do
here
is
assuming
that
mac
addresses
are
changing
now
and
it's
not
no
longer
a
long,
lasting
identifier
that
we
can
rely
upon
to
provide
network
services.
What
do
we
do
in
case?
Services
are
broken,
so
it's
it's
more
along
those
lines
like
what
what
happens
with
the
with
the
services,
the
network
services
that
were
provided
either
connectivity
or
otherwise
that
were
provided
some
of
them,
relying
on
on
the
mac
address
associated
to
one.
J
A
I
trip
probably
probably
an
italy
document
or
a
wba
document
saying
this
problem
can
be
solved
if
you
implement
this
specification,
in
which
case
we
would
be
done
by
that
time.
But
if
ever
we
find
out
that
there's
one
use
case
that
is
not
being
addressed
by
by
existing
solutions
or
the
existing
solutions
are
not
sufficient.
Then
then
we
are
going
to
ask
the
question:
do
we
need
to
do
something
else?
And
if
so,
is
that
something
that
we
would
need
to
do
in
the
etf?
A
You
I
see
your
camera
on.
I
guess
you
want
to
say
something.
K
Can
you
hear
me
now?
Yes,
okay
yeah,
I
just
want
to
add
on
like
what
we're
expecting
from
the
working
from
the
working
perspective.
So
with
all
the
use
cases
we
laid
out
everything
jurong
did
a
good
job
and
show
all
the
scenarios
here
we're
expecting.
We
know
that,
like
we're
living
in
the
world
that
mac
address,
randomization
is
going
to
happen.
K
We
we're
just
looking
for
some
guidance
or
like
index
or
any
like
guidelines
when
we
try
to
implement
a
service
here,
we
can
like
read
community
because
it's
the
web,
the
mac,
is
in
the
link
in
the
link
layer.
It
will
impact
higher
than
just
a
link
layer,
this
application
stuff
today
they
really
they
realize
they
still
rely
on
the
mac
addresses.
So
I
think
that
this
is
more
like
try
to
get
the
community
together.
K
This
is
a
real
problem
and
we
just
try
to
use
this
as
a
platform
to
try
to
solve
this
problem
cohesively.
So
then,
rather
than
like
everybody
try
to
invent
their
own
solutions,
then
yeah
then
we'll
be
living
in
a
really
fragmented.
K
A
Yeah
thanks
a
lot
for
that
glorification.
I
haven't
been
able
to
follow
up
all
the
details
on
on
the
on
the
chat,
but
if
there
are
any
other
questions,
we
still
have
a
couple
of
minutes
before
moving
on
to
the
to
the
to
the
poles.
A
So
so
far,
we
we
have
got
some
some
good
feedback
on
on
how
to
clean
the
the
charter,
specifically
specifically
about
the
deliverables.
So
I'm
assuming
that's
something
we
can.
We
can
address
on
the
mailing
list
and
by
the
way
we
do
have
a
mailing
list
madina's
in
the
ietf.
So
please
make
sure
you
join
if
you
are
interested
in
this
topic.
Ideally,
we
would
like
to
to
clean
that
text
openly
and
then
before
proposing
it
eric.
C
I
just
wonder
whether
the
participants
in
this
buff
want
also
to
discuss
the
charter.
I
mean
the
first
paragraph,
the
second
paragraph,
the
third
paragraph
and
the
fourth
paragraph,
not
only
about
the
deliverables,
so
I
would
love
to
get
some
more
questions
or
interaction
on
the
previous
paragraph.
Maybe
the
first
one
is
pretty
obvious
right,
so
we
can
skip
it,
but
the
others
maybe
not.
A
A
A
So
that
would
be
the
the
scope
of
the
group
and,
and
this
next
slide,
the
other
intention
of
the
group
is
to
do
the
the
inter
seo
coordination
and
and
also
to
be
a
short
time
frame
group
so
having
madina's
as
their
focal
point
for
interacting
with
with
these
different
seos
helps,
because
if
we
split
it
across
multiple
working
groups
inside
ietf,
it
could
be
cumbersome.
A
Even
though
we
have
the
iab,
I
triple
eight
or
two
coordination,
and
we
also
have
discussions
with
wba
having
a
central
focal
point
in
the
in
the
atf
would
be
useful
to
to
concentrate
these.
These
discussions
allegations
and
so
on.
A
So
I
guess
those
would
be
the
the
two
other
pieces
of
important
content
in
the
draft.
Besides
the
deliverables,
roman.
I
Text
and
threading
it
across
the
deliverables.
Could
you
just
help
me
help
me
make
a
couple
of
things
concrete,
because
I'm
struggling
just
a
little
bit.
We
have.
We
have
mac,
address
randomization,
widely
deployed
in
a
lot
of
modern
operating
systems
and
we're
talking
about
making
sure
we
specify
the
requirements
for
services.
I
Could
you
help
me
understand?
Who
is
the
consumer
of
those
requirements
and
maybe
a
few
examples
of
what
services
we're
talking
about,
because
I
guess
a
naively
I
had
a
naively
I
have
in
my
head.
Is
the
future?
Is
here
so
you
know
things
are
clearly
breaking
if
it's
kind
of
a
problem,
so
we
talking
next
gen
tech
help
me
contextualize
it
please
thanks.
A
Sure
so
I
guess
maybe
I
would
refer
to
the
to
the
to
the
buffer
proponents
you
or
someone
else
you
when,
when
we
had
the
first
buff
you
you,
you
drove
us
through
several
use
cases
where
some
of
the
services
you
were
used
to
providing
were
breaking
now
that
these
mac
addresses
were
being
randomized.
K
I
think
I'm
happy
to
yeah
I'm
happy
to
start
and
then
definitely
welcome
other
input
from
the
participants.
So
you
the
way
that
today,
yes,
some
of
the
new
android
os
and
apple
os
start
doing
the
randomization,
but
the
way
that
they
do
it
is
they,
as
of
today.
The
implementation
is
already
driven
for
about
the
implementation.
So
today
the
implementation
is
when
they
attach
to
the
same
ssid
they
make
they
make
the
they
make
the
agreement
as
of
today
yeah.
K
They
will
keep
the
mac
address,
not
changing,
so
that
will
at
least
like
keep
the
existing
services
not
breaking,
but
this
is.
But
there
is
no
guideline
saying
that
tomorrow,
when
they
upgrade
to
another
os
and
due
to
any
security
reason,
and
we
fully
anticipate
that
they
should
start
like
doing
more
like
time
time
based
on
randomization.
K
If
we
start
seeing,
but
because,
like
we
have
the
current,
like
semi
or
pseudo,
persistent
mac
address
per
ssid,
so
most
of
the
applications
working
today.
But
if
let's
say
we
have
start
like
using
time
time
based
randomization
like
dhcp
restoration,
hospitality
like
using
the
mac
address
on
the
airplane
or
in
the
in
the
hotel,
those
simple
use
cases
will
break.
A
Yeah
and
and
just
to
to
spell
them
out
from
the
ones
I
recall
where,
indeed
like
hotel
services
registering
to
to
getting
wi-fi
throughout
your
your
stay
in
a
hotel
or
providing
support
right,
like
connectivity,
support
service
customer
service
support,
based
on
your
connection
as
well
as,
of
course
authorized
access
to
to
a
specific
network.
A
Many
of
those
rely
on
on
the
mac
address
and
and
yeah.
If,
when
you
start
having
like
pseudo-random,
addresses
some
of
these
services,
don't
work
anymore.
A
A
So
there
are
a
few
questions
that
we
would
like
to
get
answer
from
the
community
and
you
have
them
here
in
front.
So
first
is
you
think
that
the
problem
statement
is
clear,
well-scoped
solvable
and
useful
to
solve.
A
The
second
question
is:
are
people
willing
to
participate,
meaning
review
documents
or
comment
on
the
mailing
list
or,
of
course,
author
new
documents
that
that's
always
a
possibility?
Of
course
this
is
an
open
group
and
finally,
is
their
support
to
form
a
working
group
with
this
charter
from
the
community.
A
Okay,
so
if
they
are
not,
then
you
have
a
show
of
hands
tool
on
the
top
rightish
of
your
screen.
A
C
Ngc
this
is
eric
again.
This
story
is
kind
of
confusing,
so
I
would
suggest
because
do
not
race
and
means
either.
I
have
no
opinion
or
I
think
the
statement
is
false.
So
if
you
don't
mind
after
these
questions
has
been
asked
and
answered,
please
ask
the
reverse
questions.
Does
the
community
think
that
this
problem
statement
is
unclear
or
non
noise
scope
or
non-solvable
or
not
useful
to
solve,
and
then
we
will
see
a
clear
number,
because
maybe
people
do
not
raise,
and
maybe
they
have
no
opinion.
A
A
A
So
I
suggested
then,
let's
ask
the
question
reversed:
does
the
community
think
that
the
problem
is
unclear
not
well
called
scope,
unsolvable
or
unuseful?
If
you
think
so,
please
raise
your
hand.
A
So
in
this
case
now
we
have
36
people,
so
the
numbers
are
similar.
I
guess
the
the
same.
Seven,
it's
probably
the
the
answer
to
your
question.
Eric.
A
We
have
23
29
people,
thinking
that
the
problem
is
clear:
well,
scope,
solvable
and
useful,
and
some
seven
people
thinking
otherwise.
A
A
F
Cube
jerome,
you
just
a
quick
comment
on
on
some
conversations
I
see
in
the
chat
I
wanted
to
to
underline
that
in
the
ieee
802
group.
Some
documents
are
not
visible
to
all
in.
F
The
drafts
are
not
accessible
to
people
outside
of
the
working
group
or
the
task
group,
and
that's
because
the
document
is
not.
You
know
ready
for
consumption
outside
of
the
people
who
have
not
participated
in
the
conversations.
However,
all
the
contributions
that
anyone
makes
the
group
are
visible,
so
this
could
be
a
useful
for
those
who
are
interested
in
that
aspect,
but
I
would
like
to
also
underline
that
the
8
to
11
working
group
is
going
to
only
work
on
the
11
problem,
which
means
that
this
is
between
the
station
and
the
access
point.
F
Anything
beyond
is
out
of
scope,
mostly,
which
means
that
you
know
in
in
the
issue
that
you
were
were
raising
about,
for
example,
parental
policy,
parental
control.
When
you
have
this
48
in
the
u.s
of
parents,
use
that
technique
where
they
control.
If
young
children
access
the
internet
beyond
a
certain
time
should
be
sleeping
instead
of
watching
videos
and
if
mac
changes,
those
policies
are
challenging.
Many
cases.
F
Dhcp
is
the
same
thing.
The
11
today
specifies
and
again
it's
very
wi-fi.
There
may
be
some
other
standards
that
do
not
say
that
that
you
cannot
rotate
your
mac
if
you
already
have
established
a
communication,
an
association
to
an
access
point
to
make
it
simple,
but
they
don't
say
that
you
cannot
disconnect
every
10
seconds
if
you
want
and
of
course,
if
you
do
that,
you
may
be
changing
your
mac
every
10
seconds,
which
is
likely
to
post
some
challenges
into
some
dhcp
scope.
F
Dimensioning.
So
you
know
all
these
kind
of
of
problems
are
likely
to
be
completely
beyond
the
scope
of
the
82
11
test
group,
because
you
know
that's
a
service
which
is
beyond
the
access
point.
So
you
know,
I
see
that
you
know
there
are
some
complementary
work
that
happens
between
the
stos,
but
also
see
that
there
are
some
overlaps
that
do
not
exist.
F
A
A
Who's
willing
to
review
documents
or
to
participate
in
this
working
group
actively
either,
as
I
said,
reviewing
or
why
not
writing
drafts
and,
of
course,
commenting
on
the
mailing
lists.
A
L
A
I
don't
think
that
we
need
the
reverse
answer
in
this.
The
sorry
the
reverse
question
in
this
in
this
case,
unless
some
someone
thinks
otherwise.
A
Eric
so
in
that
case,
maybe
we
can
go
to
the
to
the
next
question.
B
For
for
that,
maybe
we
can
just
rephrase
the
question
that
if,
if
there
is
support
raise
hand
and
if
there
is
not
do
not
raise
hand
to
make
it
maybe
clear
like
something
like
this,
but
I
can
change
the
question
if
you
prefer
to
ask
two
questions.
A
For
me
would
be
fine,
I
don't
know
eric,
could
you
have
a
preference.
D
I
just
want
you
to
clarify
when
it
says
the
following
charter:
is
that
referring
to
what
was
on
the
slide,
where
we
had
feedback
of
potential
amendments?
To
that?
In
other
words,
are
we
is
this
a
as
it
was
shown
on
the
slide.
A
No
that
that
I
think,
should
not
be
the
following:
it's
is
the
the
eventual
charter
that
should
be
agreed
by
by
the
working
group
on
the
middle
list,
at
least.
D
A
C
And
we
all
know
that
the
charter
will
be
modified
before
creating
the
working
group
right,
there's
a
complete
process
where
the
itf
community
is
involved
there
so
and
rest
assured,
dave
and
others
that
the
charter
will
fit
the
community
and
not
be
the
exact
one.
I
mean,
except
there's
a
miracle
that
everyone
agrees
on
this
one,
but
I
have
doubts
it's
pretty
good
draft,
but
it's
not
complete.
A
A
So
with
that
assumption,
we're
going
to
give
people
a
couple
of
seconds
so
support
to
form
a
working
group
with
a
charter
with
an
agreed
charter.
Please
raise
your
hand
if
you
support
forming
a
working
group
with
an
amendment
charter
or
do
not
raise
your
hand
if
you
are
against
forming
a
working
group.
M
A
C
No,
I
simply
wanted
to
say
that
the
last
questions
appears
to
be
clear
to
me.
But
again
it's
not
a
decision
done
today
to
create
a
working
group
right.
It
will
be
done
by
the
complete
atf
community,
but
I
see
30
out
of
34
votes
to
work
on
this.
As
there
is
a
problem
we
need
to
work
on
it,
while
obviously
about
the
problem
statement
and
the
charter
draft,
it's
less
clear
who
the
proponent
and
the
chairs
of
this
buff
will
need
to
work
more
with
the
isg
and
the
community
to
refine
the
charter.
C
A
Thanks
thanks
for
that
clarification
eric,
so
indeed
I
guess.
As
next
steps,
we
need
to
to
clean
the
wording
on
the
charter,
and
for
that
we
are
going
to
kick
again
the
discussion
on
the
on
the
medina's
mailing
list
so
that
we
we
can
get
a
crisp
charter
agreed
by
the
by
the
community
by
rough
consensus,
and
ideally
that
would
be
the
one
submitted
to
the
iesg
for
consideration
on
creating
a
new,
a
new
working
group.
A
M
Well,
I'm
very
sorry
because
I
missed
the
a
big
part
of
the
conversation
due
to
network
problems.
So
please,
just
let
me
know
what
I'm
asking
is
redundant,
I'm
basically
a
little
bit
confused
like.
I
completely
agree
with
this
review
of
the
charter
and
and
and
yeah
and
the
statements
and
the
timelines,
but
I'm
not
quite
understanding.
M
How
does
the
draft
the
current
draft
fit
into
it
like,
fundamentally,
I
have
a
concern
about
the
part
where
privacy
for
home
networks
is
is
being
described
as
not
big
in
requirements
like
if
there
is
not
a
big
requirement
on
privacy
for
home
networks,
given
that
they
are
that
home
networks
are
trusted,
for
example,
but
there
are
some
other
parts
that
I'm
a
little
bit
concerned
about.
So
does
my
question
make
sense,
or
should
I
elaborate
a
little
bit
more.
A
No,
I
I
think
it's
it's
it's
a
very
question,
and,
and-
and
you
didn't
miss
that
part
because
we
did
not
discuss
the
the
the
content
of
the
of
the
of
the
drafts
in
detail,
the
purpose
of
the
buff
was
to
to
to
identify
whether
there
were
issues
that
we
wanted
to
work
on
and
if,
if
that
work
would
be
useful
for
the
community,
so
the
content
of
the
draft
will
be
definitely
up
for
discussion
and
complete
review.
Once
we
have
a
working
group.
A
That
draft
is
it's
an
individual
draft
at
this
moment
and
it
hasn't
been
adopted
by
by
any
working
group
at
all.
So
so
all
that
specific
content
on
the
draft
is
up
for
discussion
and
and
your
your
the
details
you
mentioned
would
be
addressed
at
a
later
point.
K
Yeah,
I
just
want
to
follow
up
what
the
previous
question,
so
we
when
we
say
here
the
draft
when
we
when
we
wrote
the
drop,
we
are
standing
from
the
user
point
of
view
to
say
when
the
user
feel
trust.
It's
not
it's
not
talking
about
from
the
technology
point
of
view.
There
is
no.
We
are
not
saying
that
hey
you're
at
home,
then
then
we
don't
do.
We
are
not.
K
We
are
not
value
privacy
as
a
very
important,
very
important
point
we're
just
saying
that
from
the
user
perspective,
when
they
were
home,
they
will
feel
that
it's
a
trusted
network
how
to
address
that
is
beyond
the
scope
of
this
drought.
But
at
this
point
we
just
discussed,
like
from
the
user
perspective,
how
he
feel
about
like
the
home,
how
he
feels
about
using
the
devices
at
home.
M
Thank
you
both
in
that
absolutely
I
will
reserve
my
reviews
and
and
concerns
comments
for
later.
Thank
you
for
the
clarification.
A
Thanks,
joey,
and
and
indeed
that
that
is
taking
us,
you
have
interest
in
participating
and
you're
willing
to
contribute,
which
is
great,
that
that's
a
question
that
we
we're
trying
to
get
an
answer
for
so
indeed,
those
type
of
feedback
are
exactly
what
we
would
like
to
hear
and
and
for
that
please
join
the
the
matina's
mailing
list
and
and
send
your
comments
over
there.
A
So
great.
So
thank
you
very
much.
Everyone
for
participating
into
this
buff
and
you
will
be
hearing
from
us
soon
take
care.