►
From YouTube: IETF-MADINAS-20230511-1400
Description
MADINAS meeting session at IETF
2023/05/11 1400
https://datatracker.ietf.org/meeting//proceedings/
D
A
A
As
usual,
the
typical
reminders,
this
session
is
probably
being
recorded,
I'm,
not
sure
I
guess
so.
The
interviews
are
also
recorded,
but
I
don't
know
to
be
honest,
they're
not
well
that
I
guess
you
are
all
familiar,
but
in
case
you
are
not
familiar.
Please
read
it
carefully,
read
it
well
for
your
own
understanding
and
then
I
think
we
have
some
interim
meeting
tips
using
meteco
I.
Think
at
this
point
we
are
all
familiar
with
mythical
but
in
any
case
make
sure
your
audience.
A
Video
are
off
unless
you
are
presenting
or
asking
a
questions,
and
usually
using
a
headset
is
strongly
recommended
to
avoid
any
Eco
Echoes
and
this
type
of
things
in
terms
of
resources.
We
have
the
agenda.
That
is
very,
very
simple
in
this
case,
in
the
sense
that
we
are
concentrated
on
the
BCP
document,
although
we
will
also
have
an
update
from
i33
that
if
we
think
it's
very
useful
for
for
Malin
for
Marinas,
but
the
main
discussion
would
be
the
BCP
document.
A
C
A
Okay,
thanks
perfect
and
well
you
see
that
the
the
URL
that
is
on
the
slide
is
from
the
past
meeting.
I'll
I
think
you
can
access
the
the
right
link
in
the
in
the
in
the
data
tracker,
but
I
will
put
it
already.
You
put
it
already:
Juan
Carlos,
okay,
perfect
in
the
chat
and
well.
You
can
also
join
the
the
chat
room
but
I
think.
Well
probably
we
are
all
here
in
the
in
the
medical.
Oh
sorry,
in
the
mythical
row,
sorry
I
click
on
the
wrong
button.
A
A
B
So
I
think
it'll
be
good
to
have
this
as
a
wrap
up
to
to
understand
how
we
can
collaborate
with
with
IEEE,
but
I
just
wanted
to
say
it
now,
because
the
topic
may
come
up
during
the
BCP
part,
but
just
bear
in
mind
that
we
will
have
also
10
minutes
to
discuss
it
specifically
about
that
identification.
Part
at
the
end
with
without
Tripoli,
and
then
we'll
have
some
some
more
minutes
to
discuss
how
we
want
to
move
forward.
So
something
to
bear
in
mind.
A
A
B
F
Right,
okay,
thank
you!
That's
working!
So
thank
you
and
good.
So
good
morning,
everybody
so
I'm
Jerome
one
of
the
two
co-authors
of
that
PCP.
So
there
are
two
of
them.
That's
why
I'm
seeing
one
of
one
of
them
next
slide,
please
you,
you
may
remember,
let
me
see
if
I
can
yeah.
Thank
you.
That's.
In
the
last
meeting
we
were
discussing
moving
out
of
the
use
case
documents
some
of
the
elements,
namely
section
7,
to
push
it
into.
F
F
You
know
all
these
different
Elements,
which
are
you
know,
the
various
places
like
home,
the
managed
residential,
the
Enterprise,
all
these
environments
and
summarize
there
what
the
practice
the
expected
practice
of
RCM
is
is
to
be
so,
for
example,
it
will
be
most
of
the
time.
You
trust
the
others
users
to
see
your
Mac,
but
you
may
be
seen
from
the
outside
in
their
Pharmacy
and
maybe
they're
in
an
MDM
type
of
environment.
The
Enterprise
need
to
track
devices.
F
F
As
a
second
part,
that's
section
seven,
so
you
may
remember
that
section
seven
was
you
know
showing
how
WPA
2v3
can
protect
some
of
the
data
payload
over
the
wireless
link,
but
not
the
MAC
address
itself
how
things
like
dot
1X
can
allow
for
the
authentication
of
the
machine
or
the
user,
which
in
an
RCM
X
may
be
sufficient.
You
know
to
assert
the
identity
of
of
the
device
that's
connecting.
F
We
also
were
discussing
how
up
and
roaming
could
be
useful
in
public
venue,
especially
as
it
allows
for
optification
of
the
identity
to
the
local
venue.
But
you
know
still:
identification
of
the
user
will
be
nice
in
an
RCM
context.
So
that's
that's
the
skeleton
of
this
document,
but,
as
we
were
discussing
this
documents
in
the
previous
document
in
the
previous
meeting,
as
you
know,
Michael
who's
probably
going
to
spend
more
of
of
a
meeting
time
there
and
also
started
doing
some
more
extensive
work,
proposing
as
well
BCP.
F
F
D
C
So
we
have
three
points
here:
identity,
Network
and
application
services
and
examining
the
effect
of
RCM
schemes
on
them.
Analyzing
various
existing
identities
beyond
the
MAC
address
that
can
be
used.
I,
don't
really
know
that
there
are
any,
but
I
I.
Think
that
some
words
we
need
to
talk
about
that
and
I.
You
know
I.
Think
number
three
is
interesting.
The
best
the
best
kind
of
identity
is
one
you
don't
need.
C
Then
it
says
we're
going
to
produce
a
BCP
recommend
the
means
reduce
the
impact
of
RCMP
in
the
documented
use
cases.
So
it
implies.
We
better
have
some
documented
use
cases
and
to
mitigate
and
that
the
Privacy
achieved
with
RCM
is
not
compromised.
So
that
means
that
introducing
some
other
long-term
identifier
that
everyone
can
see
is
not
actually
very
useful
and
I
have
some
concerns
about
some
proposals,
but
I.
Don't
have
a
lot
of
details
at
this
point.
B
C
C
C
C
If
you're
going
to
ask
questions,
so
you
may
always
want
to
do
pre-station.
So
we
had
all
these
terminology
that
I
proposed
about
how
often
you
change
your
Mac
address.
You
know
whether
it's
per
never
to
you
know
every
12
hours
or
something
and
we
may
want.
We
probably
need
to
add
some
language
that
says
the
talks
about
pre-association
Association
and
that
what
kind
of
policies
we
want
on
on
each
and
whether
they're,
linkable
or
not
so
I
think
that's
an
important
thing
to
to
add
to
the
conversation
as
we
go
forward.
C
So
this
is
how
I
see
the
three
documents
going
together.
So
what
one
is
that
I'm,
not
I,
think
that
at
least
one
of
the
two
documents
that
are
adopted
right
now?
Actually
they
have
very
similar
names,
one
of
which
says
use
cases
and
requirements
and
I
think
that
we
need
to
drop
the
words
requirements
from
that
document
and
probably
change
the
title
a
little
bit.
So
the
two
documents
a
little
more
clear
that
they're
different.
C
So
in
my
mind,
the
first
document,
which
is
use
cases
needs
to
detail
a
bunch
of
things
about
how
static
Mac
addresses
have
been
used
to
provide
some
service.
X
call
it
Amelia
has
been,
and
some
others
have
been
working
the
IEEE
and
have
a
document
which
I
I
understand
is
a
bit
stuck
at
this
point
and
I
want
to
move
my
camera.
This
way
that
way
there
we
go
and
it
actually
details
a
bunch
of
things
that
I
didn't
know
about,
which
was
very
interesting.
C
For
instance,
I'll
talk
about
the
next
slide,
airport
security
queue
length
and
different
uses
of
this,
and
then
I.
Then,
in
my
mind,
the
RCM
document
needs
to
then
go
through
these
use
cases
and
it
for
each
essentially
for
each
policy
that
the
device
could
adopt
and
remembering
that
the
devices
are
adopting
these
policies
independently
of
the
use
case.
So
device
has
a
particular
policy.
C
It
may
be
per
network
if
it
can
figure
that
out,
but
then
the
pre-association
part
is
how
it,
how
does
it
determine
what
network
it's
on?
Sometimes
you
know
devices
also
use
GPS
or
something
like
this
to
determine
where
they
are
as
to
whether
they
feel
safe
and
essentially
to
to
look
at
the
impact
of
the
different
policies
on
that
application.
So
in
some
cases
it
just
is
no
effect.
I
mean
it
doesn't
matter.
In
other
cases,
it's
completely
failure
of
the
service,
and
then
the
BCP
document
needs
to
then
say.
C
C
I
posted
an
email
about
this
and
I
guess:
I
received
a
fair
number
of
plus
ones,
a
bunch
of
them
unit
cast
because
people
didn't
want
to
disrupt
the
conversation
but
I'm
I'm.
Another
another
slide
about
this,
explaining
it
more
detail
but
I'm
interested
to
hear
people's
reaction
to
this
division
of
text.
B
At
least
from
my
side
that
there's
I'm
I
agree
with
the
flow
of
starting
from
use
cases
I
think
we
have.
We
have
to
explain
and
explain
the
the
different
policies.
I
I
think
that
that
is
actually
great
and
a
good
Advance.
We
need
to
define
the
requirements
so
that
we
can
clearly
see
if
the
PCP
responds
to
those
requirements
right.
So
so
we
are
deriving
I.
C
B
C
B
B
Let
me
try
again
and
then
let
me
finish
because
I
started
describing
a
use
case,
and
then
you
started
changing
the
use
case,
so
that's
probably
where
we're
not
getting
together.
So
my
use
case
is
on
a
managed
Network
listener
and
Enterprise
Network
high
security,
where
you
need
to
identify
the
user
to
join
that
Network,
then
you
have.
B
You
can
derive
a
high
higher
requirement
to
identify
the
user
to
join
that
Network
to,
however,
if
there's
next
to
it,
there's
another
Network
that
it's
public
and
that
does
not
require
a
high
level
of
security
and
has
no
interest
whatsoever
to
identify
the
user.
But
just
has
to
know
how
many
users
are
there,
then
their
requirement
would
not
apply
to
that
use
case.
So
so
that's
that's
what
I'm
saying
I.
C
B
C
G
Excellent
well
so
this
was
one
of
the
discussions
that
we
were
having
in
the
previous
couple
of
weeks
between
media
Roman
and
Michael.
How
exactly
to
define
the
use
cases,
because
we
currently
have
a
a
set
of
use
cases
use
case
descriptions
in
existing
madina's
documents,
namely
the
use
cases
document
draft
Madness,
use
cases
document.
But
then
we
also
have
the
use
cases
as
defined
in
the
IEEE
802
.11
task.
G
So
it
might
not
be
an
obligation
on
on
an
end
user
as
it
were,
to
have
their
grocery
store
path
tract
using
a
MAC
address,
or
any
equivalent
means
it
might.
It
might
be
that,
in
order
for
such
tracking
to
occur,
you
need
some
form
of
consent
or
optional
mechanism
that
the
end
user
can
approve
through
their
device
and
so
I
think.
We
also
need
to
reflect
on
regardless
of
how
we
structure
the
best
current
practices
document
in
terms
of
use
case
hierarchies
policy.
Descriptions
for
how
Mac
addresses
are
randomly
changed.
G
We
might
want
to
reflect
on.
Do
we
want
to
have
real
life?
Proof
of
any
of
these
policies
being
deployed
in
practice,
for
instance,
do
we
know
that
there
is
a
per
boot
Mac
address
change
policy
out
there
in
the
wild?
Has
anyone
seen
a
per
session
Mac
address
change
policy
in
practice?
Do
we
know
of
any
grocery
store
path?
Tracking
occurring
like
do
we
want
to
have
this
like
realistic?
G
C
Of
course.
That
then
requires
that
the
the
pre-association
and
The
Association
address
be
the
same,
and
it
clearly
is
the
user
is:
has
some
potential
consent
there,
because
they
may
say?
Oh
yes,
for
this
network,
I
want
to
do
this
kind
of
thing,
and
I'm
and
I
have
a
relationship
with
that
Network
and
I
I'm
happy
to
do
that
right,
but
the
exact
same
pattern
is
occurring
in
the
grocery
store,
an
airport
queue
sizing
thing
where
in
fact,
all
they're
really
doing
is
counting.
C
H
Can
you
hear
me
now
yep,
okay,
I'm,
just
purely
coming
from
operate
opponent
will
so
today
you
look
at
the
use
cases
and
most
of
the
use
cases
will
in
the
end
about
the
trust
level,
and
when
you
look
at
the
trust
level
today
at
least
I
mean
it
could
be
in
the
future.
Things
like
we
will
have
more
Technologies
available
for
us
to
do,
but
at
least
like
from
today
what
we
look
at
it.
You
have
WPA
psk,
you
have
WPA
Enterprise.
H
H
Suggestions
like
for
the
working
will
look
at
it
is
how
we
are
going
to
call
how
we're
going
to
define
the
requirement
to
map
the
use
case
to
the
to
to
the
trust
level.
So
in
this
case
the
trust
level
could
be
like
what
you
says:
I
I
trust
this
level
and
how
we
can
I,
then
I
mean
how
we
can
identify
a
network
that
is
like
beyond
the
scope
at
this
point.
H
We
may
not
talking
about
this,
but
then,
if,
let's
say
I'm
in
in
the
office
building-
and
this
is
now
the
the
work
machine
that
I
connect
to
the
network,
there
will
be
a
set
of
requirements
that
we
need
to
satisfy.
We
need
to
Define
is
we
need
to
Define
in
order
to
have
a
BCP
to
map
to
the
requirement?
So
my
suggestion
is:
is
there
any
way
that
we
will
be
able
to
at
least
separate
or
Define
the
use
cases
by
the
trust
level,
and
then
by
the
trust
level?
H
I
will
say:
Mutual
I
mean
we
probably
need
a
way
that
to
say
yeah
you
as
a
client.
You
trust
this
network,
and
then
you
know
that
this
is
for
sure
the
network
that
I'm
joining
at
the
same
time
the
network,
and
we
have
a
lot
of
technology
today,
we
can
tell
that
the
network
will
authenticate
the
user
before
that
before
before
the
network
lab
the
usage
to
join
right.
C
And
and
I
think
that
that
we
also
have
a
chicken
and
egg
problem
where
you
might
be
willing
to
reveal
your
identity
to
the
network,
if
you
were
sure
it
was
the
correct
network,
but
you
can't
know
it's
the
correct
Network
until
you
review,
reveal
your
identity
to
the
network
or
an
identity
to
the
network
right
and
right
and
I.
Think
the
other
side
is
that
that
we
do
not
have
a
way
of
a
priori
signal
signaling
from
the
network
to
the
user.
C
H
C
Why
isn't
my
iPhone
getting
on
my
home
network?
They
call
up
the
the
the
you
know.
Customer
service
and
the
customer
service
gets
some
list
of
Mac
addresses
today
they
get
Mr
Mac
addresses
through
tr-79
of
what
the
home
router
is
and
they're
able
to
look
and
go.
Oh,
this
one's
an
Apple
device
because
of
the
prefix
and
it
seems
to
keep
trying
to
connect,
but
it's
clearly
got
the
wrong
password
and
the
person
says:
oh
well,
okay,
okay,
they
figure
it
out
right.
C
So
in
that
context
the
user
hasn't
necessarily
consented
to
a
use
case
that
involves
the
home,
router
tracking
them
by
their
pvom
right,
which
is
their.
You
know
the
oui
provided
address,
which
would
actually
be
the
best
scenario
right,
but
but
they
have,
they
haven't
participated
consciously
in
saying
oh
I'm
good
at
the
requirement
for
me
to
now
get
customer
support
is
that
when
I'm
on
my
home
network
I,
don't
hide
my
vendor
ID,
so
they
can
figure
out
and
help
me
right.
H
B
No
well
I'm
just
saying
that,
for
that
specific
use
case,
I
I
can
see
the
description
of
the
use
case
and
the
requirement
as
you
just
described.
That's
that's
what
I
meant
before
by
use
case,
then
the
right
requirements
like
if
you
say
you
cannot
hide
I'm,
not
agreeing
with
it.
I'm
just
saying
that's
a
requirement.
I
would
derive
from
that
use
case
you.
You
cannot
hire
your
your
UI.
D
H
So
the
use
case
for
me
is
just
like
you,
you
can
I
mean
like
what
you
said.
I
mean
I
mean
we
can.
Debate
in
Maryland
is
saying
that
this
is
the
white
use
case
or
not,
but
that's
exactly
you
just
write
down
a
use
case,
and
this
is
the
use
case
and
in
order
to
satisfies
this
use
case,
this
will
be
the
requirement.
C
C
H
B
H
E
Can
you
hear
me
yeah,
yes,
I,
think
it's
working
good
good
thanks
for
having
me
the
one
thing
that
we
ran
into
in
the
IEEE,
which
might
be
a
helpful
kind
of
path
already
I've
been
down
for
you
guys
is,
as
we
were
starting
to
list
out
these
requirements.
We
discovered
that
kind
of
each
of
them
was
a
different.
Let
me
call
it
dimension
for
lack
of
a
better
word
around
this
question
of
what
information
is
shared
into
whom
you
know
the
this.
E
E
Agreed
but
that's
why
I'm
saying
so
we
drew
out
all
these
different
dimensions
and
another
dimension
is
time.
So,
for
example,
let's
say
yes,
I
can
be
tracked,
but
while
I'm
being
tracked,
I'm
Anonymous,
you
don't
know
it's
me,
you
just
know
it's
some
device
that
is
walking
through
the
grocery
store
and
by
the
way
you
can
only
track
me
for
five
minutes.
30
seconds
pick
something
before.
E
If
there's
a
duration,
Factor
there's
an
amount
of
information
exposed
Factor
right,
all
these
different,
like
I,
say
Dimensions
to
the
question,
so
you
come
back
around
to
well.
Actually,
is
it
a
concern
that
a
third
party
can
track
me
if
they
have
no
idea
who
I
am,
and
they
can
only
do
it
for
30
seconds?
Do
I
care,
you
know
I,
don't
know,
but
it
really
helps
to
divide
these
things
into
these
different
measurements.
C
So,
jumping
up
a
level
here
back
to
what's
on
this
slide,
this
is
was
intending
to
kind
of
illustrate
what
the
different
documents
would
contain.
So,
first
of
all,
we
describe
the
use
case
when
you
describe
it
independently
of
RCM,
what's
happening
today,
how
our
Mac
address
is
being
used
in
a
particular
application
or
or
situation
the
IEEE,
this
IEEE
document
that
Emilia
was
working
on
and
I
think
a
few
others
has
actually
a
lot
of
interesting
stuff
in
places
that
I,
I
didn't
even
know
that
was
happening.
C
Airport
Q
sizing
was
a
surprise
to
me,
but
totally
makes
sense
when
I
think
about
it
and
and
then
and
and
then,
as
you
said,
the
the
several
said,
so
that
leads
to
a
requirement
that
the
MAC
address
be
track,
be
trackable
or
constant,
for
you
know
five
minutes
ten
minutes
or
that
the
user
isn't
knows
about
it
or
or
something
like
this
right
and
then
the
RCM
document.
The
idea
is
that
it
then
says
for
each
one
of
these
use
cases
or
categories
of
use
cases
if
we
wind
up
with
categories.
C
C
Is
you
wind
up
with
with
the
belief
that
there's
more
people
in
the
airport,
you
know
security
queue
than
actually
are
there
right
and
and
if
you
are
just
every
pre-association,
for
instance,
if
what
that
was
a
new
random
Mac
address,
for
example,
and
that's
how
we
were
counting
that
might
wind
up
with
a
fairly
large
wrong
out
and
things
would
be
wouldn't
work.
Amelia.
C
C
B
E
E
Here
we
go
is
that
working
excellent,
okay,
all
right!
So,
first
off
just
a
couple
of
caveats:
I'll
point
out
that
per
the
IEEE
rules,
I
am
actually
the
chair
of
the
tgbh
working
group
or
a
test
group.
That's
working
on
this
stuff
inside
of
dot
11,
but
I
am
not
here
representing
that
group
here
as
a
personal
individual.
So
these
are
my
opinions.
That's
an
IEEE
rule
that
I
have
to
make
that
clear,
but
I'll
try
to
get
through
that
fairly
quickly.
Where's
the
next
slide
button.
E
E
The
test
group
BH,
which
is
the
one
that
a
chair
is
focused
specifically
on.
We
know
that
there
are
devices
in
the
world
that
are
using
randomized
Mac
addresses
now
and
are
doing
it
obviously
for
privacy
reasons,
but
we
actually
don't
care.
Why
they're
doing
it?
The
fact
is,
they're
doing
it
and
given
what
they're
doing
they
are
quote,
unquote,
breaking
some
use
cases
or
some
facilities
that
are
part
of
Dot
11.,
and
we
are
looking
at
very
reactively.
How
do
we
respond
to
the
fact
that
this
is
happening?
E
And
what
do
we
want
to
do
or
need
to
do
to
bring
back
facilities
that
used
to
work
when
Mac
addresses
were
stable
and
have
those
facilities
still
work,
but
without
causing
any
new
kind
of
stable
identity
to
be
leaked?
So
I
think
we
have
a
very
similar
scope
to
the
scope
slide.
That
I
was
just
seeing
that
I
think
you
guys
are
working
on
and
at
a
very
high
level.
E
E
The
separate
group
that's
going
on
is
called
tgbi
and
that's
a
separate
activity
but
happening
in
parallel,
and
they
have
tackled
the
kind
of
much
broader
scope
of
sort
of
everything
else.
So
what
else
is
going
on?
That's
leaking
personal
information
and
can
result
in
tracking
and
other
such
things
and
with
within
the
8-2-11
scope,
which
is
a
bit
narrow.
So
it's
another
challenge
that
we
have
what
can
be
done
or
what
should
be
done
to
protect
that
information.
E
E
So
I'm
going
to
focus
for
the
rest
of
this
pretty
much
on
the
tgbh
stuff,
one
because
I'm,
obviously
closer
and
more
familiar,
but
also
because
it's
more
mature
and
coming
along
and
I
think
has
a
more
direct
impact
and
connection
to
this
group
within
tgh
in
that
draft
1.0.
That
I
was
just
describing
that
I
hope
we'll
we'll
get
out
next
week.
We've
basically
split
the
mechanisms
that
we're
looking
at
and,
like
I,
said
we're
being
very
reactive.
E
So
actually,
let
me
pause
here.
I
didn't
put
it
in
this
deck
and
probably
should
have
in
hindsight
after
this
conversation,
but
clearly,
if
there's
anything,
we
can
do
to
collaborate
on
the
path
we've
been
down
to
identify
those
use
cases
turn
those
into
hesitate
to
use
the
award
requirements
but
to
turn
them
into.
E
You
know
some
reaction
to
the
specific
use
cases
and
breaking
it
down,
like
I,
said
earlier,
trying
to
to
figure
out
the
dimensions
of
the
problem
and
so
forth.
If
any
of
that
background
material
is
helpful,
that
would
be
a
really
good
place
to
collaborate,
but
we
within
the
group
have
kind
of
moved
past
that,
like
I,
say
to
Solutions.
E
So
all
kind
of
all
of
that
I
think
is
a
good
place
for
us
to
be
collaborating
between
these
two
groups
in
the
solution
space.
I'll
jump
to
that,
though,
we've
come
up
with
two
large
buckets.
If
you
will
or
categories
for
the
solutions.
One
of
them
is
this
concept
of
What's
called
the
name
doesn't
really
mean
anything
but
a
called
a
device
ID
just
so
you've
got
a
handle
to
hang
on
it.
This
is
a
case
where
the
network
itself
allocates
some
identifier
to
a
device.
E
It
can
do
that
either
after
it
has
done
some
real
type
of
security,
negotiation,
1X
or
something
like
that
and
does
in
fact
know
who
the
user
is
or
up
to
the
network.
If
it
doesn't
care
that
much,
it
can
allocate
and
identifier
much
more
randomly,
but
just
give
the
device
some
identifier
that
will
be
stable
for
an
interesting
period
of
time,
it's
up
to
the
network,
what
it
wants
to
do
and
what
this
information
means.
E
There's
that
information
then
is
communicated
down
to
the
device
only
inside
of
a
secured
communication.
So
it's
part
of
a
you
know
the
encryption
exchange
well,
security
negotiation
is
going
on.
So
there's
no
ability
for
a
third
party
to
understand
or
track
this
ID
or
even
see
it
so
again,
kind
of
in
either
of
those
cases.
The
ID
might
mean
something
real
with
a
real
user
or
it
might
just
be
a
random
thing,
but
it
doesn't
matter
because
third
parties
can't
see
it
anyway.
E
You
see
me
this
is
the
MAC
address
that
I'm
going
to
use,
so
the
device
allocates
a
randomized
address
more
like
it
does
today
it's
going
to
use
that
address
for
its
Transmissions,
but
it's
going
to
use
it
for
its
Transmissions
at
some
future
time
talking
to
the
network,
and
presumably
the
network
knows
who
that
device
is.
While
it's
doing
this
because
it
told
it
on
the
previous
connection.
E
If
you
get
me,
this
is
kind
of
a
a
chain
of
events
right
that,
once
the
network
has
established
that
it
understands
the
device
a
first
time
through
some
hopefully
secured
mechanism,
then
from
then
on.
You
can
follow
this
daisy
chain
of
saying,
okay
I
when
I
see
some
random
address
in
the
future.
I
will
know
that
that's
that
same
device,
so
this
allows
the
device
to
use
that
Mac
address
as
its
way
of
communicating,
which
makes
it
much
easier
to
provide
the
information.
E
E
So,
for
example,
one
of
the
behaviors
that
we
do
know
about
make
sure
you
guys
are
aware
of
is
a
lot
of
the
devices
that
are
out
there
today
are
using
a
completely
random
Mac
address
when
they
are
just
scanning
around
looking
for
a
network,
and
that
address
is
in
fact,
being
randomized
very
quickly,
probably
almost
on
every
scan.
It
will
pick
a
different
address
since
there's
no
ability
to
track
the
device
over
time,
let
alone
have
any
clue
what
what
device
identity
that
actually
is.
E
But
once
the
device
decides
that
there
is
a
network
of
interest
and
is
planning
to
attach
to
that
Network,
then
it
might
send
its
probes
using
this
identifiable
Mac
address
so
that
the
network
can
say.
Oh
okay,
I
recognize
that
this
is
device.
That's
going
to
attach.
It's
one
I
do
understand
to
know
about.
E
You
know
a
user
coming
home
to
their
home
network,
for
example,
and
can
then
take
the
appropriate
pre-association
actions
to
help
the
device
get
get
onto
the
network.
Whether
or
not
it
uses
that
same
Mac
address.
Once
it's
attached
is
kind
of
a
separate
question.
The
device
can
rotate
that
address
kind
of
again,
that's
at
its
discretion,
so
both
of
these
games
result
in
being
able
to
identify
the
client,
certainly
while
it's
Associated,
but
also
for
some
pre-association
schemes,
using
the
different
mechanisms
that
I
very
highly
level
described
and
based
on
work.
E
That
was
done
in
eight
or
two
11,
a
z
which
is
creating
a
an
authentication
and
secure
mechanism
for
exchanging
some
limited
amounts
of
information
pre-association,
so
we're
leveraging
that
same
work,
and
that
was
actually
done
for
for
ranging
activities
you
know.
Device
location
activities
was
the
key
that
AZ
was
working
on,
but
we're
trying
to
leverage
their
work
and
I
know
I
need
to
hurry
up
so
anyway.
Just
to
give
you
an
idea
where
we
are
and
what
I
think
our
next
steps
ought
to
be
between
the
groups.
E
My
personal
opinion
anyway,
like
I,
said
tgbh,
is
looking
at
targeting
draft
1.0
out
of
the
meeting
next
week.
We're
hopeful
the
rest
of
the
the
list
here
of
our
plan
is
somewhat
optimistic,
but
I
don't
think
it's
too
far
off
that
we're
hoping
we'll
do
it.
A
working
group
letter
ballot
between
May
and
July
meetings
of
IEEE
and
assuming
we
can
get
some
success
level
out
of
that,
then
I
think
it
would
be
appropriate
for
us
to
share
the
actual
draft
and
Dorothy
Stanley.
E
The
first
reference
there
I
think
that's
the
one
that
this
has
been
referenced
on
this
call,
but
if
not,
that
I
think
is
an
interesting,
useful
document
where
we
went
through
then
down
this
path
of
trying
to
identify
use
cases
and
the
implications
of
the
use
cases.
We
also
had
to
take
the
further
step
of
which
of
these
are
within.11
scope,
and
so
several
of
them
we
punted
and
said
yeah.
E
That's
an
interesting
problem,
but
it's
not
our
problem
to
solve,
but
some
of
them
we
said,
are
within
our
scope
to
solve
and
that's
what
we're
attempting
to
do
within
our
draft,
so
that's
kind
of
where
we
are
and
going
back.
My
recommendations
are
that
we
do
start
trying
to
share
this
work
with
iatf
and
I
would
say
as
soon
as
we
can
and
I
will
work
with
Dorothy
and
and
the
chairs
here
and
figure
out
how
we
can
start
share
our
drafts
as
soon
as
possible.
Thanks.
B
Thank
you
very
much,
Mark
yeah,
just
to
close
on
that
I
agree.
I
think
it
makes
a
complete
sense
to
share
the
draft,
especially
if
something
comes
out
next
week
from
the
Triple
A
to
11
meeting
in
Orlando
and
yeah.
We
will
also
do
whatever
is
needed
to
so
that
people
in
madinas
can
can
get
access
to
that
document,
and
so
that
that
is
our
next
step.
That
is
I
think
we
can.
B
We
can
assume
it's
happening
for
delegation
I,
guess
we'll
we'll
see
if
it's
needed
or
how,
how
much
need
we
have
for
a
formal
liaison
for
now.
What
you
just
gave
to
to
Martinez
is
is
very
useful
and
and
I'm
pretty
sure
it's
will
be
appreciated.
So,
of
course,
if
in
the
future
you
can
provide,
an
update
will
be
great.
If,
if
we
need
to
design
someone
specifically
to
to
do
the
liaison,
we
can
do
that
I,
don't
think
we
in
in
night
ETF
we
require
such
a
formality.
B
What
would
the
level
of
details
you
provided
it's
super
good,
but
we
can.
We
can
work
that
out
if
it's
needed,
especially
from
from
the
IEEE
side
and
then
I
guess.
The
question
is
also
there's
a
lot
of
food
for
thought
now
about
how
to
advance
for
for
next
steps
from
both
groups.
I'm,
not
sure
we
will
reach
a
conclusion
in
two
minutes.
B
Probably
we
will
continue
the
discussion
on
the
middling
list,
but
for
now
the
last
two
minutes
I
would
just
like
to
open
the
mic
to
to
hear
people's
reactions
to
to
the
presentations.
After
what
we
just
heard,
the
proposal
for
the
documents,
the
way
11bh
is
trying
to
work
out
the
identifiers
and
how
we
can
work
together.
Does
anybody
have
any
any
quick
reaction
to
that.