►
From YouTube: IETF112-MADINAS-20211110-1200
Description
MADINAS meeting session at IETF112
2021/11/10 1200
https://datatracker.ietf.org/meeting/112/proceedings/
B
B
So
the
usual
etiquette
for
the
virtual
meeting.
Please
join
the
cube
before
participating
and
meet
your
mic
unless
you
are
speaking
ideally
turn
off
your
video.
Unless
you
are
speaking
as
well,
if
you
have
any
questions
or
doubts
about
how
to
use
mythical,
you
can
use
those
links
next
slide.
Please.
B
B
Very
importantly,
as
a
participant,
you
agree
to
work
respectfully
with
other
participants
and
if
you
have
any
issues
or
feel
harassed,
please
contact
the
office
man
next
slide.
Please
a
note
on
that.
A
brief
reminder
from
the
ietf
guidelines
of
conduct,
so
idf
participants
extend
respect
and
courtesy
to
the
colleagues
at
all
times.
So
please
be
mindful
of
this.
Whenever
you
participate
or
provide
any
technical
criticism,
we
have
all
in
personal
discussions.
So
we
talk
about
technology
and
not
about
personal
issues.
B
C
A
B
B
Then
we're
going
to
move
to
the
status
update
from
other
seos,
starting
from
the
wba
moving
on
to
802.1
802.11.,
then
we're
going
to
start
talking
about
the
the
two
drafts
that
we
have
at
hand,
the
first
one
being
the
randomized
and
changing
mac
addresses,
use
cases
by
jerome
and
then
the
mac
address,
randomization
amelia
will
present
and
then
we're
going
to
talk
about
next
steps.
Any
questions
or
comments
on
the
agenda.
B
We
presented
also
the
network
and
application
service
related
issues
that
were
related
to
to
this
mac
address
randomization,
and
the
idea
was
to
identify
whether
any
actions
were
required
at
the
ietf,
and
we
identified
at
least
these
three,
which
is
the
coordination
with
other
ratios,
documentation
of
use,
cases
and
identification
of
existing
solutions
and
gaps,
and
therefore
we
got
charter
next
slide.
Please.
B
B
B
B
We
are
chartered
to
work
on
a
bcp
that
will
recommend
means
to
reduce
the
impact
of
rcm
on
use
cases,
while
of
course
still
ensuring
the
privacy
achieved
with
rcm
is
not
compromised
and
also
we
are
chartered
to
work
together
with
other
ietf
working
groups
which
have
identified
many
like
dhc
or
interior,
as
well
as
liaise
with
other
seos,
and
also
we
have
identified
a
triple
eight
of
two,
the
wireless
broadband
alliance
wba
and
we
have
already
started
some
some
discussions
with
them.
That
will
be
reported
right
after
this.
B
So
as
far
as
deliverables,
we
have
the
documents
about
the
current
status
or
our
current
state
of
affairs
and
informal
use
information.
Also
our
use
case
and
identity
requirements
document
and
an
information
on
mac
address,
randomization
currents,
state
of
affairs
document.
Then
we
have
two
drafts
that
try
to
respond
to
those
so
we'll
talk
about
them
and
the
idea
is
to
adopt
them
by
the
working
group
and
also
we
have
a
will
be
working
later
on
on
a
bcp.
D
D
So
the
next
objective
analyze
and
look
at
the
currently
available
solutions.
That's
because
we're
a
high
level
organization,
that's
largely
what
we've
been
doing,
then
of
course
liaise
with
other
standards.
Organizations
such
as
yourselves
and
then
at
the
end
of
it
all,
explain
and
recommend
technologies
that
are
ideally
are
already
present,
so
that
people
who
are
using
mac
addresses
at
the
moment
can
move
on
to
something
more
appropriate.
D
So
we've
we've
looked
at
a
number
of
use
cases
for
where
the
mac
address
is
currently
or
has
been
used
as
a
long-term
identifier
and
where
this
is
going
to
cause
issues
with
service
and
we've
previously
liaised
the
document
with
you
covering
those
yeah.
Following
on
from
that,
we
we've
gone
through
those
use
cases
and
looked
at
the
various
requirements
that
they
present
in
terms
of
you
know
the
uniqueness
of
the
identity,
identity,
it's
its
scope
and
duration.
D
D
D
Clearly,
starting
with
the
802.1x
based
authentications,
wpa2
or
3
enterprise
passpoint,
and
over
the
top
of
that
open
roaming,
we've
also
looked
at
the
private
pre-shared
key
device.
Fingerprinting
and
other
proprietary
external
identification,
such
as
where
an
app
or
a
website
is
used
to
identify
the
user,
and
that's
then
communicated
back
to
the
wi-fi
network
to
either
allow
access
to
certain
resources
or
maybe
to
set
up
perhaps
something
like
a
particular
quas
level.
D
D
D
So
those
are
the
network
types
that
we're
talking
about
here
and
we've
in
the
process
at
the
moment
of
looking
at
each
of
those
currently
available
solutions
and
suggesting
which
of
them
might
be
preferable
for
which
network
type.
Alongside
that
yeah,
we
find
that,
obviously,
not
not
everything
that
we
used
to
do
with
mac
is
covered.
D
We
we
have
no.
I
no
means
of
identifying
that
that
device
belongs
to
the
network
and
perhaps
should
have
been
attempting,
but
equally
we
don't
want
to
be
connect.
Collecting
information
about
devices
that
have
no
relationship
with
the
network
and
shouldn't
be
connecting
anyway,
and
it's
it's
very
hard
to
distinguish
those
two
and
and
without
the
mac.
Currently
we
don't
have
a
solution
for
that.
D
D
D
B
D
We
certainly
we're
not
considering
that
the
mac
address
is
the
best
way
most
of
the
solutions
at
the
moment
for
larger,
more
public
networks.
Hospitality
enterprise,
we're
suggesting
that
one
of
the
802.1x
based
methods
is
the
way
to
go
for
home
networks.
There
may
be
some
applicability
for
ppsk
or
even
device
fingerprinting,
but
neither
of
those
are
standards,
and
we
don't
really
like
recommending
non-standardized
solutions.
F
B
All
right,
so
I
talking
with
you
thanks
tina
for
that
question
and
indeed,
as
you
can
see,
there's
quite
a
bit
of
overlap
on
the
on
the
use
cases
identification.
But
this
is
rather
a
good
thing,
seeing
that
wba
has
taken
a
good,
quick
start
at
the
at
the
issue.
So
the
point
is
here
not
to
reinvent
the
wheel,
but
rather
to
to
work
together
to
make
sure
that
we
consider
the
use
cases
that
have
already
been
identified
by
wba.
B
B
So,
yes,
I
guess
to
work
together
with
wba
and
as
tim
mentioned,
that
we
have
the
the
means
to
to
also
work
with
the
liaisons
to
make
it
official.
If
ever
we
need
to
get
access
to
some
documents
or
we
can
reference
them
and
put
information
in
our
draft
or
something
like
that,
but
but
for
sure
we
want
to
share
information
and
make
sure
that
we
work
together
with
them.
B
B
H
B
G
G
But
I
as
the
chair
because
I'm
the
chair.
I
have
to
give
this
disclaimer
that
that
this
is
a
personal
presentation
and
is
not
a
formal
presentation
of
ieee
or
the
eight
or
two
dot
working
8301
working
group,
because
they
have
not
approved
this
presentation,
but
be
that
as
it
may.
This
is
my
view
of
the
situation
in
in
802.1
and
just
to
give
you
a
quick
background
of
of
what
802.1
is
within
within
ieee
we're.
G
G
This
is
the
organization
on
the
right
of
the
of
the
802.1
working
group.
Most
of
our
work
right
now
is
focused
on
time-sensitive
networking.
However,
we
do
have
work
on
security,
which
I'll
mention
and
we
do
have
architecture
work
that
has
happened
in
the
past
and
we'll
start
up
again
and
we
currently
have
a
study
project
underway
in
our
industry
connections,
activity
nendica.
G
So
just
I
guess
a
brief
background
if
you
will
on
the
the
reference
model-
and
this
is
a
reference
model
that
is
defined
within
ieee
standard
802,
which
is
our
base
overview
and
architecture
standard
and-
and
this
defines
the
interfaces
between
the
different
layers
with
the
terminology
of
access
points.
And
so
you
see
physical
access
points
and
mac
access
points
and
and
so
on,
and
the
the
mac
address
is
defined
at
the
the
mac
address
point
and
is
common
to
all
802
technologies.
G
G
The
individual
group
address
identifies
whether
it's
an
individual
address,
which
is
the
typical
case
or
a
group
address
which
is
like
a
broadcast
address,
and
then
the
universal
and
local
bit
identifies
whether
it's
universally
administered,
which
means
the
ieee
registration
authority,
assigns
that
number
or
whether
it
is
locally
administered
and
locally
locally,
was
originally
not
so
defined,
but
was
recently
defined
and
I'll
talk
about
that
in
a
minute.
You
can
see
that
the
the
way
that
the
address
is
structured
is
that
a
subset
of
the
address
is
a
so.
G
This
is
for
the
universal
addresses.
A
subset
of
that
address
is
assigned
by
the
registration
authority,
the
ieee
registration
authority
that
currently
assigns
addresses
in
either
large,
medium
or
small,
depending
on
how
many
universal
addresses
that
that
are
desired
for
the
use
case.
So,
whether
it's
you
know,
4,
000
or
so,
or
up
to
16
million
per
per
block.
G
G
So,
just
back
again
on
the
on
the
registration
authority
committee
and
identifying
the
the
registries,
and
so
this
is
the
the
registry
that
ieee
maintains,
indicates
that
standard
802
is
the
the
standard
definition
for
what
a
mac
address
is
number
one
and
for
what
the
different
assignments
that
are
given
here.
You
see
with
the
the
mal
mam
and
mas
and
the
showing
here.
G
This
is
a
48-bit
address
and
then
the
the
different
local
extensions
that
a
particular
you
know
vendor
or
manufacturer
who
acquires
so
the
mal.
They
would
then
have
24
bits
to
assign-
and
you
know,
assign
it
to
16
million
odd
different
devices,
and
so,
in
addition
to
the
mac
address,
there
are
other
identifiers
that
are
also
defined
in
standard
802,
including
the
company
id
oids,
the
urns
and
and
so
forth.
G
G
And
so
that's
the
the
global
space,
and
then
you
see
the
the
other
four
quadrants
that
I
had
just
mentioned,
which
have
which
this
is
an
organization,
an
optional
organization
of
the
local
space,
to
help
the
administrators
assign
addresses
in
that
space.
One
of
the
activities
that
we
have
underway
as
well
in
802.1
is,
is
a
protocol
that
would
allow
administrators
to
actually
assign
mac
addresses
to
devices
on
on
boot
up,
and
so
that's
that's
another
activity
we
currently
have
under
underway.
G
However,
if
the
local
space
is
used,
it's
the
administrators
of
that
network
responsibility
to
ensure
uniqueness
and
if
there
is
not
unique,
addresses
there,
there
is
a
potential
of
of
disruption
of
the
network
because
of
that,
and
so
and
as
I
had
mentioned
before,
the
randomization
was
intended
for
the
for
the
administratively
assigned
space.
One
thing
I'd
like
to
note
is
that
we
have
currently
a
study
underway
within
our
industry
connections,
activities
on
an
evolved
link,
player
architecture.
G
One
of
the
topics
within
the
discussion
is
on
mac
addresses
and
the
specific
mapping
of
single
or
multiple
mac
addresses
to
to
mseps
from
an
architecture
perspective,
so
that
maybe
may
be
interesting
to
this
group
going
forward.
So
so
that's
the
the
mac
address
status.
Just
to
give
you
an
update
now
on
some
of
the
security
aspects
that
that
we're
working
on
here,
I
I
just
gave
a
background
on
a
mac
sec,
which
is
security
and
privacy.
G
How
can
we
protect
against
them,
and
so
this
is
a
intended
as
a
consistent
approach
for
all
eight
or
two
developers,
and
so
it's
it's
a
worthwhile
background
information
on
the
threat
model
so
on
on
mac
sec
itself.
That
is
intended
as
as
encryption,
so
data
data
protection
and,
of
course,
counters
to
some
man
in
the
middle
attacks
that
that
had
been
identified
some
time
ago.
G
This
is
specifying
enhancements
to
mac
security
that
reduces
the
ability
for
observers
to
to
information,
infer
information
about
a
particular
stream
based
on
the
size
and
the
user's
identity,
and
so
the
way
that
it
does.
That
is
that
it
encapsulates
the
entire
frame,
including
the
the
mac,
addresses
and
and
pads
the
data
out,
and
so
that,
for
example,
you
would
have
a
consistent,
steady
stream
of
traffic
from
the
user
to
an
endpoint,
no
matter
what's
been
being
transmitted.
G
So
that's
an
activity,
that's
currently
underway
and
just
as
a
and
as
an
example,
this
is
a
diagram
of
the
the.
What
that
user
frame
encapsulation
would
be
in
this
maxsec
privacy
frame,
where
you
see
that
it's
first
encoded,
you're
encoding
the
whole
frame
and
adding
a
a
special
one-time,
new
essay
mac
address
to
the
front,
and
then
so
that's
the
privacy
step
and
then
encrypting
the
whole
thing.
And
so
so.
G
This
allows
the
both
a
confidentiality
and
a
protection
hiding
the
user's
mac
address,
as
well
as
the
original
frame
sizes.
From
everyone
from
the
from
where
this
is
encrypted
to
the
to
the
endpoint,
where
it's,
where
it's
decrypted
and
so
because
and
the
reason
that
this
was
done-
is
that
there's
actually
solutions
to
do
this
already,
but
it
was
we.
G
So
that's
all
that
I
had
to
to
summarize
happy
to
take
some
questions,
and
this
is
a
a
summary
of
some
some
additional
information.
If
you
want
to
find
out
about
the
the
dot
one
working
group
and
the
work
underway
and
either
nandica
that
I
mentioned
or
the
security
group,
the
802.1
standards
are
freely
available
through
the
the
get
program
on
explore.
G
I
Actually,
we
would
like
the
other
way
we
would
like
to
try.
We
would
like
for
industrial
uses,
we'd
really
like
to
have
more
clear
identities
or
iot
devices,
and
specifically,
what
we're
wondering
is
you
know
with
the
ieee
ever
going
to
a
situation
where
they
would
issue
cider,
like
certificates,
saying
that
this
manufacturer
owns
this
particular
address
space
and
that
would
allow
them
to
issue
certificates
with
mac
addresses
in
them
as
the
I,
as
the
mostly
industrial
iot
device
identity.
I
G
I
So
that's
what
we
do
have
is
that
what
you
were
well,
we
would
be
using
one
ars.
The
problem
is:
what
is
the
identity?
That's
being
asserted,
because
the
only
thing
we
can
see
over
the
network
is
the
mac
address,
and
so
we
would
really
like
it
if
there
was
a
trust
path
up
to
the
ieee
that
allowed
us
to
validate
that.
You
know
a
particular
oui
was
assigned
to
particular
vendor
and
that
that
vendor
had
issued
a
certificate,
and
this
is
kind
of
the
opposite
of
of
randomized
mac
address.
I
G
G
Right,
so
so
what
we're?
What
we're
working
on,
which
I
didn't
highlight
here-
a
protocol
called
one
cq,
is
mac,
address,
assignment
and,
and
that
is
one
of
the
options
within
that
is-
is
a
trust
relationship
on
that
assignment.
But
but
this
isn't
it's
not.
I
guess
it's
not
decided
yet
whether
ieee
would
be
one
of
the
trusted
assigners.
I
Yeah
they're
not
confident
to
do
that,
and
they
don't
have
the
ability
to
install
the
certificate
before
the
device
is
onboarded.
But
the,
but
part
of
this
is
also
is
to
provide
some
anchor
for
all
of
the
the
nice
security
and
the
privacy
enhancements
that
you
did
provide
and
so
that
they
all
would
look
the
same
at
layer
at
a
layer
two.
We
would
do
all
our
layers
to
security
and
we
would
hide.
We
would
hide
the
real
real
identities
in
some
cases,
but
without
a
strong
anchor.
G
I
mean
which
is
pushes
for
that
done
on
on
a
higher
level,
and-
and
I
can
take
that
back
to
the
group
and
see
if
that
that's
an
ecosystem,
that
is
that
we'd
like
to
encourage
to
be
created
within
ieee.
I
mean
that
would
be
a
registration
authority,
a
piece,
but
we
can
look
at
that
because
I
mean
what
we
have.
The
focusing
on
has
been
the
protocols
which
I've
been
talking
about
like
with
ar
and
cq
and
such.
B
J
All
right,
so,
thank
you,
everyone.
Let
me
try
to
send
my
video
and,
if
it
crashes,
I'll
I'll,
stop
all
right.
So
thank
you,
glenn
for
this
presentation
and
and
following
on
his
lead,
I
should
say
that
this
is
also
a
personal
view.
As
a
part,
I
see
active
participant
in
these
two
groups,
not
an
official
liaison
or
anything
like
that.
J
So
that
idea
has
been
present
along
with
the
idea
of
privacy
for
for
a
while
and
in
the
year
2018
that
practice
of
randomized
mac
address
has
been
observed
and
studied
a
little
bit
in
the
context
of
a
document
called
8-11
aq,
which
is
like
many
of
the
other
amendments.
You
know
improvements
to
the
standard
that
are
made
every
now
and
then
and
then
integrated
later
in
the
standard,
and
what
a211aq
says
is
that
you
can
use
this
randomized
mac
address.
J
You
know
there
is
no
obligation
to
use
the
burned
in
mac
address
in
your
device
if
you're
not
associated,
but
if
you
are
associated
and
what
we
call
you
maintain
a
state
with
an
access
point.
You
cannot
change
your
mac
address
within
that
context,
because
you
would
be
breaking
your
state,
so
you
break
the
state
and
then
you
you,
you
restart.
So
that
was
one
thing
that
was
looking
at
rcm,
but
at
the
same
time
you
know
this
idea
of
privacy,
nato,
2.11
and
rcm.
J
You
know
was
becoming
a
more
important
issue
that
drove
the
creation
of
two
groups:
first,
a
topic
interest
group
and
then
a
study
group.
It's
the
normal
progression
in
the
8011
world,
where
you
know
a
group
of
people
are
interested
in
a
topic
that
may
become
some
work
and
that
was
in
2019
and
2020
and
then
in
the
end,
the
outcome
of
that
study
group
was
the
creation
of
two
subgroups
working
test
groups
in
1811,
8011,
bh
and
8.11
bi.
J
J
What
do
we
need
to
do
to
maintain
services
in
that
context?
Are
there
things
that
are
going
to
break
if
devices
change
the
mac
address
and,
of
course
you
know
the
answer,
maybe
no
in
most
cases,
but
there
may
be
some
cases
where,
yes,
you
know
some
services
that
were
possible
before
mac
addresses
were
randomized
and
rotating
would
not
be
possible
anymore.
So
the
goal
of
802.11
ambh
is
to
come
through.
J
You
know
the
the
use
cases
where
we
think
that
maybe
services
might
be
broken
in
the
802.11
sense
by
this
rotation
of
mac
addresses
and
you'll
see.
If
we
can,
you
know
provide
some
recommendation:
how
how
to
fix
that
it's
intended
to
be
a
short
term
quote
quote
group.
The
expectation
is
that
by
2023-ish,
which
you
know
pretty
fast
in
these
standard
groups,
they
should
come
with
some
text.
J
You
know,
for
you,
know,
remediation
of
whatever
might
be
broken,
of
course,
and
you
know
pushing
aside
and
listing
what
we
think
is
not
broken
as
we
speak.
You
know
we
we're.
We
spend
quite
some
time
looking
at
the
use
cases
that
we
should
be
tackling.
You
know
what
is
really
broken
by
rcm.
I
know
in
many
cases
we
find
that
some
services
are
not
in
802.11.
J
You
know
you
do
additional
stuff
on
top
and
you
just
write
on
the
fact
that
you
had
the
mac
address,
so
you
use
that
stuff
to
identify
your
device,
but
that's
nothing
to
do
with
a2.11.
So
there
are
plenty
of
cases
that
came
up
initially
as
potential
candidates
that
we
simply
pushed
aside,
say
well
that
that
is
not
an
eight
to
11
function.
J
You
just
happen
to
take
the
opportunity
of
using
the
mac
to
identify
a
machine
or
even
worse,
a
user,
and
you
think
the
mac
is
a
good
way
of
doing
that,
and
it's
not
so
plenty
of
things
are
left
aside,
and
this
is,
I
think,
important
for
us
in
madinas,
because
in
particular
anything
which
is
above
80.11
on
the
mac
layer
is
not
necessarily
something
that
8.11
needs
to
solve.
You
know
we're
not
dealing
with
dhcp
dns
whatever,
so
that
is
something
I
think
important
for
our
group
here
to
to
keep
following.
J
You
know
you
place
a
a
a
call
and
then
the
service
breaks
at
some
level.
You
call
it
support
and
say:
well
phone
was
not
working
yesterday
and
they
asked
you.
Okay.
What's
your
machine
ip
about,
I
don't
know
it
was
yesterday.
What's
your
mac
address,
I
don't
know
it
was
yesterday
it
changed.
So
you
know
that
kind
of
service
is
not
directly
a2.11,
but
we
do
see
why
a211
is
involved
in
that
idea
of
saying.
J
But
you
know
many
others
are-
are
not
involved
there
and
there
is
this
other
group,
which
is
eight
to
eleven
bi.
So
bh
again
is
surviving.
You
know,
eight
to
11
with
rcm
is
anything
breaking
811
bi
is
more
around
enhanced
service
with
data
privacy
protection.
So
the
idea
is
to
say
wi-fi
a2.11
any
of
these
radio
technologies.
J
Has
this
characteristic
that
if
you're
in
range
of
the
signal
you
may
be
able
to
observe
what's
going
on,
whereas,
as
we
were
discussing
the
chat
before,
if
you're
on
a
wire
cable
to
to
a
switch,
you
know
you
may
be
able
to
read.
What's
going
on
the
cable
from
the
electromagnetic
field,
it's
very
short
range,
you
know,
but
really
you
know,
you'll
see
it
only
if
you
are
on
the
wire
or
if
you
are
in
the
switch
in
it
to
11.
J
So
it's
a
common
question
that
comes
is
what
is
the
relationship
between
bh
and
bi,
so
bi
is
not
necessarily
looking
at
rcm
itself,
although
rcm
being
the
reason
because
of
privacy
concerns
that
it
happened.
You
know
there
is
kind
of
a
relationship
that
keeps
you
we
keep
playing
along
in
these
two
groups
and
of
course,
sometimes
the
ball
bounces
from
one
group
to
the
other,
because
it's
more
you
know
the
field
of
one
or
the
other.
J
But
the
group
of
the
goal
of
bi
is
to
say
what
should
we
improve
in
82.11?
If,
if
there
are
some
things
in
2011
that
have
impact
on
privacy?
So
can
we
not
list
those?
Is
there
something
we
can
do
about
it?
So
the
goal
of
bi,
of
course,
as
you
can
see,
is
deeper
than
bh
and
therefore
it's
a
work
stream
is
intended
to
be
longer.
J
We
expect
some
publication
by
2025
two
years
more
than
the
811
bh,
so
at
this
stage
in
the
bi
group,
what
we're
trying
to
do
is
to
list
the
privacy
related
issues
with
a2011
and,
as
you
can
guess,
you
know
there
are
plenty
first.
You
know
there
are
some
elements
that
we
reuse
from
one
association
to
the
other.
J
If
we
want
to
reassociate
and
come
back
to
an
access
point
to
expedite
the
process,
there
are
plenty
of
things
that
we
can
really
say
to
be
recognized
by
the
infrastructure
and,
of
course
this
could
be
indications.
There
are
tons
of
things
in
the
frame
at
the
mac
layers.
Clan
was
describing
it,
but
even
that
lower
layer
that
we
tend
to
use
which
are
mechanical.
J
That
may
be,
you
know,
usable
to
identify
a
particular
station
in
the
crowd.
So
all
these
things
are
things
that
we
are
trying
to
list
as
we
go
along
at
the
same
time.
You
know
because
the
problem
is
not
entirely
new.
There
has
been
quite
some
thoughts
already
on
some
privacy
issues
in
8011,
so
we
see
also
some
proposal
coming
up
in
the
group
about
you
know,
fixing
some
points,
issues
that
have
been
known
or
identified
for
a
while.
J
J
So
the
goal
is
that
by
march
20
22-ish
we
should
have
a
good
idea
of
what
the
use
cases
are
and
what
is
broken
in
terms
of
or
what
is
at
risk
in
terms
of
privacy
in
eight
to
eleven
from
there
try
to
get
some
requirement
and
some
proposal
to
try
to
work
on.
So
you
know,
I
think,
in
the
term
of
of
madness.
Both
of
these
groups
are
probably
very
interesting
for
us
to
keep
a
liaison
with.
You
know,
bi,
because
you
know
privacy
is
the
source
of
the
cause.
J
You
know
of
rcm.
It
seems
in
the
first
place.
So
that's
something
we
probably
want
to
keep
an
eye
on
and
bh,
because
it's
clear
that
things
that
bh
will
fix
will
probably
have
an
influence
on
what
you
know.
The
maddiness
recommendations
may
be
because
you
know
maybe
they'll
decide
to
have
a
stable
representation
for
the
mac
address
when
you
know
applicable
under
the
controller
of
the
user,
all
that
stuff.
In
that
case
you
know
there
may
be
some.
J
You
know,
resolution
of
issues
that
we
may
be
identifying
in
marines,
but
in
some
other
cases
they
may
say.
Oh,
this
is
not
our
problem
and
they
may
throw
their
things
on
on
our
laps,
and
we
may
need
to
be
aware
of
that
to
say.
Well,
maybe
then
we
need
to
tackle
that
here
in
the
itf
all
right.
Let
me
pause
here
and
see
if
we
have
any
questions
or
feedback
on
these
two
groups.
J
J
So
there's
definitely
you
know
in
interactions
and
the
essence,
because
we're
looking
at
the
same
problem
and
they
also
talk
a
lot
with
the
wi-fi
alliance,
where
there
are
some
security
groups
and
some
other
groups,
you
know
impacted
by
rcm
as
well,
but
you
know
I
would
say
that,
although
we
look
at
the
same
issues,
our
angle
is
probably
slightly
different.
But
yes,
we
talk
a
lot
yeah.
B
K
K
What's
that
221,
I
believe
glenn
with
a
pacific
vendor
that
that's
been
been,
I
think,
what's
parrot
is
using
their
sign.
Their
their
vendor
id
that
they
got,
and
so
they
would
associate
these
together
to
make
a
stream.
But
then
the
api
puts
a
pseudo
mac
address
up
to
the
application,
which
then
breaks
the
whole
intent
to
be
able
to
link
the
messages
together.
K
J
J
You
know
that
there
would
need
to
be
ask
a
question,
but
then
you
know
there
is,
of
course
this
difficult
question
how
many
times
you
ask
the
user
about
what
and
do
they
understand
the
question.
So
that's
one
of
the
things
where,
where
edward
bh
is
is
looking
into
you
know
the
is
there's
anything
that
breaks
but
we're
looking
at
the
8011
side.
What
you're
seem
to
be
looking
at
is
more
in
the
application
side
of
802.11.
M
N
Very
good
well
so
a
lot
of
the
in
many
of
the
updates
that
we've
heard
from
the
standards
development
organizations
in
this
section
and
the
problems
identified
are
or
the
use
cases
and
challenges
both
in
terms
of
identification
and
privacy.
Protection
are
overlapping,
and
so
maybe
this
is
a
broader
question
just
for
jerome.
N
So
do
we
have
something
like
a
foreseen
way
of
saying,
for
instance,
in
in
the
ieee
802.11
tgbi
working
group
that
well,
this
is
a
problem
that
is
not
suitable
to
be
solved
here,
but
maybe
we
should
be
solving
it
in
the
ietf.
And
similarly,
if
we
identify
here
in
modern
as
a
problem,
could
we
is
there
a
way
that
we
could
pass
that
either
down
2.11
or
up
to
wba,
etc?.
J
Yeah,
thank
you,
emily
and,
of
course,
you're
in
all
these
groups.
So
so
I
don't
know
the
answer,
but
thank
you
for
allowing
me
to
share
our
thoughts
yeah.
I
think
it's
it's
something
which
is
critical
for
us
here
and
continue
doing.
You
know,
liaison
with
a
bhbi
and
probably
dolby
and
wfa,
because
in
bh
for
example,
we
spend
a
lot
of
time
looking
at
use
cases
and
asking.
Is
that
something
that
breaks
with
rcm?
J
Is
it
something
that
breaks
and
we
care
about,
and
in
some
time
in
many
cases
the
answer
is
yes,
it
breaks
with
rcm,
but
we
don't
care.
So
it's
it's
important
that
you
know,
as
each
group
lists
the
possible
issues
we
keep.
You
know
sending
those
exchanges
back
and
forth
and
I'm
sure
that
it's
at
some
point
we'll
say:
well,
we
don't
think
it's
any
one
of
us
to
solve.
J
You
know
it's
it's
you
know
you've
been
using
the
mac
address
wrong,
stop
using
that,
but
in
some
cases
yeah
my
expectations
that
will
be
pushing
ball
from
one
side
to
the
other,
so
yeah
so
yeah.
I
think
liaison
between
these
groups
and,
of
course,
you
know
many
participants.
One
group
are
also
participants
of
the
others.
J
B
J
J
We
know
that
rcm,
you
know
the
fact
that
you
change
the
mac
address
that
is
used
to
identify
a
station
is
going
to
affect
services,
and
you
know
if
it
affects
services
for
the
station.
It
may
affect
the
user
experience
of
that
station.
So
we
try
to
understand
what
context
these
deals
with
and
what
is
the
requirement
for
that
kind
of
of
issue?
J
However,
we
also
found
that
a
very
common
problem
we
face
when
we
encounter
those
conversations
is
vocabulary,
and
you
know
I've
seen
in
the
chats
and
it's
a
typical
example
of
that,
where
you
know
we
use
terms
in
different
contexts
and,
of
course
it
becomes
very
difficult
very
soon
to
understand
each
other.
You
know
if
you
say
that
you
know
they
should
not
read
my
mac
address.
They
who
you
know
who
who
is
they?
J
You
know
if
we,
if
we're
not
specific
into
what
we're
defining,
then
it
becomes
very
difficult
to
make
progress,
because
we
keep
redefining
terms
all
the
time
and
each
person
has
a
different
term.
So
what
this
draft
does
first,
is
try
to
say:
can
we
define
a
little
bit
better?
You
know
the
environment
where
we
operate,
so
we
can
refer
to
the
same.
You
know
kind
of
structure,
environment.
When
we
talk
about
problems
and
solutions,
in
particular,
we
reuse
what
glenn
was
describing,
which
is
the
802
e.
J
You
know,
and
others
group
that
you
use
the
terminology
of
personal
versus
versus
managed
devices.
Your
personal
device
is
something
which
a
device
which
traffic
is
directly
relatable
to
a
single
user.
You
know,
if
you
have
your
smartphone
most
of
the
time
only
you
use
your
smartphone,
so
whatever
traffic
comes
from,
that
smartphone
is
likely
being
associated
to
you
directly,
and
you
know
personally
shared
service
devices
and
what
we
call
managed
devices
are
devices
which
traffic
is
not
necessarily
directly
associated
to
a
person.
Typical
example.
J
J
J
So
those
are
functional
entities
and,
of
course,
changing
the
mac
may
have
the
the
some
issues
and
there
are
also
some
human
related
entities
and
that's
where
probably
you
know
many
times.
We
we
talk
about
things
where
you
know
you
may
have
over-the-air
observers,
observers
on
the
wired
inside
the
network,
that's
the
ltlei
or
x
outside
of
network
utility,
but
also
some
entities
managing
network.
Like
you
know,
wireless
network
operators
or
networks
providers.
J
So
we
try
to
list
all
these
possible
actors
and
I
see
in
the
chat,
yeah
ipv6
dhcp.
You
know,
of
course,
we're
not
saying
we're
not
defining
functions
here.
We
are
listing
the
functions
where
we
have
entities
that
have
an
action
or
an
interest
in
in
the
the
mac
address,
then,
of
course,
moving
away
from
who
is
they
that's?
You
know
one
thing
that
can
be
useful.
J
We
also
try
to
look
at
where
the
mac
address
is
a
problem,
and
when
it's
not,
and
to
do
that,
we
need
to
define
two
elements.
One
is
what
we
call
the
trust
you
know
our.
Can
you
trust
everybody,
for
example,
are
there
environments
where
you
and
I'll
ask
the
question
again
at
the
end
of
this
presentation?
J
Are
there
environments
where
you
you
can
show
your
mac
address
without
the
fear
that
the
other
actors
seeing
your
mac
address,
are
going
to
be
using
that
mac
address
against
you
or
to
track
you
or
to
spy
on
you,
so
that
would
be
an
environment
where
you
have
a
full
trust
on
the
other
side
of
a
spectrum.
Of
course,
you
may
have
zero
trust.
You
know
a
place
where
you
say
I
don't
trust
anybody
here
and
that
could
be.
J
I
don't
know
the
mac
address
the
access
point,
for
example,
because
I
need
that
thing
to
make
me
connect
to
the
internet
without
billing
me
every
24
hours
every
time
I
change
my
mac,
but
I
don't
trust
you
know
something
behind,
so
there
may
be
some
areas
where
a
selective
trust
may
be
set
so
defining
which
level
of
trust
we're
seeing
for
each
environment
is,
I
think,
important
and,
of
course,
defining
those
environments.
Where
are
we
looking
at
for
the
mac
address
problem
is
important
because
the
requirements
and
the
exposure
might
be
different.
J
If
you
are
in
your
home,
you
know
the
exposure
is
probably
different
than
if
you
are
in
a
busy
airport
or
in
a
coffee
shop.
If
you
are
the
managed
residential
setting,
for
example,
you
know
these
places
where
there
is
an
itc
stand,
for.
You
know
extended
living,
for
example,
where
there
is
an
I.t
system
that
manages
the
wi-fi
they
may
have.
You
know
view
on
the
need
to
understand
what
mac
address
you
had.
That
is
different
than
if
you
are
an
enterprise
network,
for
example,
any
enterprise.
Are
you
bringing
your
own
device?
J
It's
your
personal
device
that
you
also
use
for
work,
or
is
it
an
enterprise
asset?
You
know
they
give
you
a
laptop
and
it's
their
laptop.
You
just
happen
to
use
it,
so
you
know
these
environments
have
different
assumptions
in
terms
of
not
only
privacy,
but
of
course
you
know
the
relation
of
knowing
who
is
doing
what.
J
But
you
can
read
the
draft
yourself
and
we
will
try
to
list
the
possible
steps
that
we
could
take
from
that
assumption
in
the
mighty
astro
group
to
try
to
see
where
our
services
are
affected
and
what
recommendations
we
we
can.
We
can
make
one
thing
I
would
like
to
add
here,
which
is
not
today
in
the
draft
and
I'll
come
back
on
the
next
two
slides.
Also
on
things
which
are
not
in
the
draft
is
that
iot
is
something
we
were
not
observing.
J
Looking
at
in
the
draft
and
final
conversation
we
had
earlier
today
here,
but
also
some
feedback
we
have
on
the
list,
it
seems
that
iot
might
be
an
interesting
case
to
look
into
you
know
either.
You
know,
as
a
michael
was
referring
to
a
strong
identification
enterprise,
but
also
you
know
what
is
the
effect
of
iot
changing
their
mac
if
it's
your
iot
at
home,
so
that
may
be
something
we
may
want
to
to
envision
as
well.
J
So
we
are
today
at
version
three,
and
I
would
say
that
since
we
posted
versus
three
of
the
draft
we
and
the
preparation
for
for
this
meeting,
we
receive
a
ton
of
feedback.
So
I'd
like
to
you
know
thank
everybody
who
took
the
time
and
care
to
read
this
document
and
provide
feedback.
We'll
of
course,
will
respond
to
it.
J
But
in
those
comments
I
think
there
were
two
things
that
I
think
would
be
worth
bringing
to
the
attention
of
this
group,
maybe
to
discuss
you
know
today
and
have
your
view
on
this.
One
is
a
full
trust.
You
know
this
environment
about
full
trust.
I
was
discussing
before
so
remember:
that's
the
environment.
In
the
draft
we
define
it
as
the
place
where
you
are
not
concerned
as
a
user
that
the
mac
of
your
personal
device-
you
know
your
your
smartphone,
for
example-
would
be
seen
by
others.
J
You
know,
there's
no
threat
to
you.
If
others
see
you
know
your
mac
address
and
others
could
be
services
around.
You
know
dhep
and
the
others
whatever,
but
also
users
in
range
of
you.
You
know,
looking
at
your
mac
and
being
a
naive
guy
living
in
the
us,
where
my
closest
neighbor
is
about
a
mile
and
a
half
away,
I
say
well,
probably
a
home
would
be
a
typical
example
there,
because
I
don't
really
care.
J
If
my
dog
sees
my
mac
address,
even
my
wife
or
my
kids,
I
don't
think
they
are
going
to
attack
me
and
all
the
services
where
the
mac
address
is
seen
to
me
is
going
to
be
in
my
house,
because
it's
going
to
be
my
dhcp
server
is
going
to
be
my
wi-fi,
etc.
So
I
tend
to
see
that
as
being
an
environment
where
full
trust
is
possible.
In
the
early
conversation
of
this
draft
we
had
some
comments,
saying
yeah,
but
what?
If
you
suddenly
turn
into
an
rbnb?
J
And
of
course
we
said?
Well
then,
in
that
case
it's
not
really
in
the
home
environment.
You
just
turn
your
home
into
hospitality.
So
it's
not
really
a
home
environment
anymore,
but
then
you
know
we
had
more
and
more
feedback
saying
yeah,
but
you
know
it's
because
you
you
american,
live
with
that
middle
of
nowhere.
But
if
you
are
an
apartment
building,
you
know
your
neighbors
hear
your
mac
because
you
hear
their
mac
and
they
you
know
everybody
hears
each
other.
So
you
know
the
more.
We
get
this
feedback.
The
more.
J
I
Environment
is
actually
an
in-enterprise
where
all
the
devices
the
enterprise
wants
to
know
that
all
the
devices
belong
to
the
enterprise
and,
if
there's
anyone
else
that
comes
along
with
something
else,
they're
going
to
flag
it
and
maybe
there's
going
to
be
security
detail
that
goes
to
remove
the
device
from
the
thing.
So
I
actually
think
that
home
is
almost
never
ever
going
to
be
a
full
trust
environment.
J
O
Thank
you
yeah.
I
pretty
much
agree
with
what
michael
said.
I
also
think
that
home
environments
cannot
be
fully
trusted,
not
only
because
there
could
be
diverse
attackers
or
people
trying
to
listen
into
your
home
network,
but
precisely
like
you
said
also
because
there's
there
absolutely
is
a
lack
of
security
mechanisms
right,
especially
we're
talking
about
well
regular
homes
that
don't
really
have
like,
I
don't
know,
like
knowledge
or
resources
to
to
put
like
secure
mechanisms
at
their
home.
O
I
also
agree
that
in
in
this
scenario,
enterprises
could
be
seen
as
much
more
secure
than
home
devices
and
in
home
devices.
I
would
I
would
even
like
to
mention
like
my
phone
and
if
I
trusted
both
my
phone
and
my
laptop,
that
are
using
my
home
network.
I
would
not
be
interested
in
things
such
as
encryption
of
the
dns,
for
example,
because
I
should
be
trusting
that
network
and-
and
I
don't
that's
it
thanks.
C
J
C
Is
I
don't
think
we
can
trust
any
place
in
the
world
where
you
will
have
other
devices?
I
already
mentioned
that
in
the
mailing
list,
but
we
are
seeing
a
trend
where
any
kind
of
device
you
have
in
your
pocket,
especially
the
smartphones.
They
are
running
all
kinds
of
applications
which
are
often
including
features
that
are
scanning
nearby
devices,
whether
they
are
bluetooth,
low
energy,
wi-fi
and
some
companies
are
already
interested
in.
C
I
mean
what
would
be
the
benefits
of
that
of
having
this
specific
case
can't
we
apply
the
rules
that
we
have
in
non-fully
trusted
scenario
to
this
one.
Just
in
case
there
is
a
news
dropper
in
range,
whether
it's
someone
outside
your
house
or
just
your
smart
smartphone.
Listening
on
your
other
devices,.
J
Yeah,
thank
you,
mateo,
and
you
know
it's
interesting
because
I
I
agree
also
going
backwards
in
your
inner
statement.
I
don't
know
if
there
is
a
place
that
is,
is
a
full
trust
environment
and
maybe
you
know
the
conclusion
is
that
you
know
full
trust
environments.
These
place
don't
exist
and
that's
fine
and
from
from
what
I
heard
from
the
two
previous
commenters,
joey
and
michael,
is
that
the
enterprise
environment
is
such
because
it's
control
environment,
but
also
because
they
provide
you
their
devices.
J
So
the
pii
exposure
here
is,
you
know
close
to
none,
not
because
it's
a
it's
an
enterprise
asset
so,
but
also
I
I
do
see
that
in
an
enterprise
there
could
be
physical
security,
where
you
know
you
cannot
just
stick
on
the
wall
and-
and
you
know,
sneak
inside
et
cetera,
but
yeah.
I
see
your
point.
Maybe
there
is
no
full
trust
environment
at
all.
I
mean
it's
it's
I
mean
it's
good
to
define
that
environment
and
just
say
well
on
this
planet.
Sorry
guys
there
is
no
such
place.
P
Now
the
the
notion
that
you
enterprises
are
very
secure
and
all
the
same
is
just
wrong.
There's
a
whole
range
of
enterprises,
very
big
to
very
small,
some
very
open.
Some
very
close.
You
can't
make
these
general
characterizations
and
the
other
thing
I
would
note
is
that
that
you,
you
know
the
only
way
an
enterprise
or
anywhere
can
validate
who's
connected
to.
It
is
actually
to
do
a
real
challenge
where
the
user
has
to
identify
themselves.
J
Thank
you
bob
and-
and
this
is
you
know,
one
of
the
big
reasons
why
we
have
this
draft.
You
know
when
we
say
there
are
enterprises
where
you
know
there
may
be
full
trust.
We're
not
saying
all
enterprises
are
full
trust
because
everything
is
fine
everywhere
and
I
think
it's
you
know
it's
critical
to
define
where
this
this
would
be
set
if
it
would
be
set-
and
I
fully
agree
with
your
statement
here-
we're
looking
at
rcm
right,
so
we're
saying
exposing
the
mac
address.
J
Does
that
have
consequence
in
terms
of
pii
in
those
environments?
And
of
course
you
know
if
the
enterprise
assets
is
the
enterprises,
not
yours,
and
there
is
no
pii
there.
Well,
you
know
you
don't
really
care
about
exposing
your
mac,
because
really
there
is
nothing
of
you
on
on
this
device,
but
I
also
fully
agree
with
your
points
on
the
authentication
being
being
changed
all
right.
Thank
you
very
much.
Thank
you
for
this
input.
Another
one
I'd
like
to
like.
J
Four
four
more
minutes
sure
go
ahead.
Please,
okay!
Thank
you
very
much.
It's
what
I
call
the
race
conditions,
so
you
know
going
back
into
this:
a
total
11
eq
in
2018,
I'm
you
know
I'm
making
a
shortcut
saying
it's
four
beats
changing
the
mac
during
association.
It's
I
mean
it's
not
entirely
true.
What
it
says
is
that
the
non-mp
state
connecting
to
an
infrastructure
bss
shall
retain
a
single
mac
address
for
the
duration
of
its
connection
across
an
ess.
Now
to
make
it
simple,
bss
is
one
access
point.
J
Ess
is
when
you
move
from
one
access
point
to
the
other,
and
you
know
the
context
of
that
is
to
say
if
you
change
your
mac.
Well,
you
break
state
and
therefore
you
have
to
restart
okay.
So
so
that's
the
context
where
we
operate,
where
we
say
well
once
you're,
connecting
to
an
access
point.
If
you
want
to
be
the
same
device
on
that
access
point,
you
must
keep
your
mac
address,
because
if
you
change
it,
you're
not
the
same
device
anymore
and
we
start
from
scratch.
J
So
that's
where
we
were
in
2018
since
then,
there
has
been
a
lot
of
questions
coming
both
in
8-11
bh
and
in
8-11
bi,
where
you
know
some
authors
have
come
and
said.
Well,
you
know
I
may
want
to
go
out
to
lunch.
Come
back
and
reassociate,
which
is,
you
know,
regain
the
while
still
changing
my
mac
address,
or
you
know,
for
privacy
reasons.
J
If
I'm
in
a
public
environment
I
may
want
to
have
you
know
a
secure
connection
to
the
access
point
within
which
secure
tunnel
I
can
maybe
give
an
identifier
but
for
the
rest
of
the
world.
You
know
the
observers,
I'm
going
to
change
my
mac,
every
few
minutes
who
knows
so
from
the
outside
world.
You
know
my
mac
is
changing,
but
the
ap
still
knows.
It's
me
somehow.
J
So,
knowing
that
these
conversations
are
happening
in
the
draft,
you
know
we
do
not
make
any
assumption
in
the
fact
that
your
mac
address
has
to
stay
stable
as
long
as
you're
connected
to
an
access
point.
We
don't
don't
mention
this
requirement
anywhere
and
we
had
a
couple
of
feedback.
Saying
dude,
you
don't
know
you're
not
aware
of
it
11aq,
because
you
know
you
cannot
change
your
mac
there.
J
So
you
know
you
are
living
up
in
the
door
to
a
problem
doesn't
exist,
and
you
know
of
course,
every
single
time
to
every
single
contributor
responded.
Well,
it
turns
out.
We
are
aware
of
it,
but
we
don't
know
if
that's
going
to
hold
true
for
the
upcoming
years
and
we
don't
make
any
provision
there,
because
it's
not
our
problem
in
marinas.
It's
an
8011
problem,
so
we
don't
define
whether
the
rotation
happens
within
a
connection
or
not,
but
because
we
we
come
back
to
the
these
comments.
J
I
I
wanted
to
bring
the
question
to
the
group
and
ask:
do
you
think
that
leaving
this
door
open
as
we
do,
knowing
that
things
are
not
necessarily
carved
in
stone,
is
okay
or
do
you
think
that
we
should
say
well
hold
your
horses
you're
riding
here
in
you
know,
2000?
What
is
that
21
november?
Don't
you
know
be
specific
about
what
happens
is
allowed
in
2021
november
and
if
things
change
in
three
months,
then
you'll
change
your
draft.
J
Q
So,
yes,
aq
assumes
that
you've
got
a
single
mac
address
that
you
you
return
to
when
you
connect
back
to
the
ess,
but
that's
I
think,
going
to
be
addressed
in
bi
when
the
pmk
id
privacy
has
been
been
addressed,
because
that
will
allow
a
stay
to
reuse.
A
pmk
id
identify
secure
state
on
the
ap
using
a
random
mac
address.
So
from
the
point
of
view
of
what
what
madness
should
do,
I
would
say
nothing:
we
should
just
let
let
bi
continue
doing
what
bias
said.
They're
going
to
be
doing.
J
Q
B
B
J
Makes
sense,
thank
you
very
much.
Thank
you
very
much
thanks
all
right
and
that's
it
for
this
presentation.
So
thank
you
again
for
everybody
to
to
everybody
who
who
took
the
care
to
provide
feedback,
will
integrate
the
changes
and
propose
you
know
an
updated
version
of
this
draft
within
the
next
few
weeks.
B
As
expressed
in
the
in
the
mailing
list
by
by
some
people
thanks
michael,
the
idea
is
to
to
adopt
this
this
draft
and
and
we'll
go
to
that
at
the
end
of
the
meeting.
If
that's
okay,
we'll
go
now
to
present
the
other
draft
that
we
have
and
then
we'll
do
the
call
for
adoption
for
both
drafts
at
the
end,
so
amelia.
N
A
N
Me
to
project
this
go
ahead
and
project.
I
think
it
will
be
easier
to
reduce
the
risk
of
me
having
software
problems,
so
this
is
an
updated
version
of
a
presentation
that
we
already
saw
in
july
of
this
year.
So
for
those
of
you
who
are
already
in
the
july
meeting,
a
lot
of
this
will
look
familiar
and
it's
a
quick
run-through
of
the
draft
on
mac
address
randomization,
with
some
updates
that
next
slide.
Please.
N
And
so
the
goals
of
this
draft
is
simply
to
document
the
current
state
of
affairs
regarding
mac
address
randomization
at
the
iedf
and
other
sdos.
What's
been
going
on
so
far
next
slide,
please
we
have
a
table
of
contents
with
the
yeah
that
goes
over
all
of
the
activities
that
most
of
them
we've
already
heard
about
today.
N
N
N
The
draft
has
also
been
updated
to
a
version
one
to
reflect
these
new
investigations,
and
I
think
we've
also
addressed
some
comments
from
jerome
hungary.
So
next
slide
please
and
next
slide.
Please,
if
you
have
any
further
comments
and
reviews,
please
share
them
with
me
or
juan
carlos
or
carlos.
Thank
you.
B
A
We
also
changed
the
name
of
the
draft,
so
it
now
draft
suniga
madinas
to,
although
that
the
other,
the
other
name
was
also
representative
enough,
but
just
to
to
follow
the
typical
practices
and
then
regarding
the
mobile
oss
changes.
Let
me
go
back
just
to
that.
To
that
slide,
we
added
this,
which
basically
the
vbs
to
document
and
is
related
to
the
discussion
that
we
had
just
had
with
jerome
on
the
what
the
oss
are
doing
today.
So
this
is
an
attempt
to
kind
of
characterize
what
they
are
doing.
Of
course,
these
are
these.
A
We
already
got
some
comments
from
jerome
on
things
like
the
table
and
some
corrections,
so
please
we
would
like
to
get
as
much
feedback
as
possible,
not
only
in
the
actual
content
that
maybe
there
are
some
mistakes.
We
we
try
to
be
as
rich
as
possible,
but
of
course
we
there
may
be
some
errors,
but
also
in
the
way
we
could
keep
that
documentation,
because
it's
since
things
may
change,
we
may
want
to
reflect
in
the
document
a
bit
the
the
evolution
not
only
the
current
state.
A
B
Thanks
for
that,
carlos
indeed,
I
think
again,
this
document
being
informational.
It
provides
a
good
snapshot,
but
also
a
historic
of
how
things
are
evolving
and,
as
we
can
see
clearly
the
lack
of
consistency
in
the
behavior
of
different
implementations.
It's
also
something
that
we
need
to
be
aware.
B
Yes
thanks
the
last
part,
and
the
idea
now
is
to
to
adopt
these
two
drafts.
So,
let's
start
with
the
draft
henry
medina's
framework
zero,
three,
the
one
presented
by
jerome.
Previously
again,
this
document
has
been
discussed
at
length
on
the
mailing
list,
so
the
idea
is
to
adopt
it
as
a
working
group
item
and
for
that
we
want
to
just
ask
here:
if
there
are
any
questions
or
comments
regarding
adopting
this
draft.
B
B
K
And
that
is
these
tables,
which
you
don't
want
them
to
be
locked
down
in
an
rsc
we
now
have
github
and
github
can
be
tied
to
the
work
group
and
the
rest
of
it.
You
can
reference
the
github
in
the
document
point
to
where
it
is
and
then
maintain
these
tables
as
a
living
thing,
instead
of
just
a
static
in
rfc.
Consider
doing
that.
B
Thanks
bob,
that
was
an
answer
to
to
reach
comment
ballot,
but
also
addressing
the
the
other
draft,
not
the
one
that
is
being
displayed
right
now.
Sorry
about
the
confusion,
maybe
we
should
have
made
a
call
for
adoption
right
after
the
the
draft
henry,
but
again
we'll
go
back
to
to
to
that
point
about
the
the
table
on
the
on
the
second
draft.
Now
moving
back
again
to
the
first
draft
draft,
henry
medina
is
the
one
presented
before
by
by
jerome.
B
B
B
So
this
is
the
second
call
for
adoption
and
for
draft
swimming
and
latinas,
and
this
is
the
one
that
we've
already
got
two
comments
regarding
the
the
table
showing
the
discrepancy
between
behaviors
and
operating
systems
when
it
comes
to
mac,
address
randomization,
being
a
co-author
of
this
draft,
I
will
move
myself
away
from
the
mic
and
I
will
let
mature
coach
run
this
call
for
adoption
matthew.
Do
you
want
to
open
your
mic?
Please.
P
O
K
I
So
I
will
echo
what
bob
said
about
the
tables
and
things
like
this,
but
I
think
that
actually
the
useful
thing
that
this
document
could
do
rather,
like
I
think
one
of
the
early
behave
documents
for
nat-
is
to
just
give
names
to
the
different
policies
that
we
have
seen
over
time.
Not
say
who
does
them
at
one
point
in
this
document,
but
rather
to
say
these
are
the
policies
that
we've
seen
and
that
way
we
can
talk
intelligently
about.
I
You
know
things
even
if
we
just
call
them
type,
1
and
type
2
and
type
seven,
or
something
like
that.
At
least.
We
could
have
a
better
conversation
about.
You
know
if
the
devices
and
it
does
type
one
policy,
then
you
expect
this
kind
of
thing
to
happen
and
the
table
later
on
could
tell
us
what
versions
of
what
os's
did.
What
things
in
the
past.
F
Dave
yeah,
so
I'm
actually
going
to
say
very
similar
things
to
what
michael
said,
and
I
guess,
as
a
past
behaved
working
group
chair,
that's
probably
not
surprising.
I
think
I
have
no
personal
opinion
as
to
whether
there
is
a
snapshot
of
a
table
in
the
document
or
only
on
github
right.
I'd
find
either
way
with
that
one,
but
I
think
the
main
value
that
can
be
provided,
as
michael
said,
is,
if
you
look
at
the
table,
the
definition
of
the
rows
right
is
kind
of
similar
to
what
michael
was
saying
right.
F
You
can
define
a
set
of
the
types
of
behaviors
that
you've
seen
out
there,
regardless
of
exactly
which
operating
systems
and
stuff
they
map
to
or
which
versions
of
which
operating
systems.
If
you
can
define
the
taxonomy
by
which
the
github
or
whatever
the
table
is
whether
it's
in
the
document
or
github,
if
you
can
define
the
taxonomy
of
what
behaviors
are
that
you've
seen
so
far,
I
think
that
in
and
of
itself
is
valuable
to
adopt
in
the
working
group.
So
thanks.
B
L
Yes,
sorry
for
wearing
a
mask,
I'm
basically
in
my
desk
home
and
there's
a
technician
nearby,
so
I
apologize
for
the
noise.
It
was
unexpected
anyway,
I
would
love,
let's
say
for
the
first
meeting,
seeing
about
60
to
70
participants
in
the
meeting
with
many
interactions
on
the
chat.
It's
really
a
proof
that
this
working
group
needed
to
exist
just
to
clarify.
I
would
also
like
to
thank
teams
for
wba
and
glenn
and
ieee
for
presenting
their
sdo
point
of
view.
L
It's
always
interesting
when
multiple
sdo
works
and
now
removing
my
ed
hat
just
participants
of
this
working
group.
I
would
really
love
to
get
this
code
for
adoption
done
and
like
many
others,
I
don't
care
what
this
github
or
an
rfc.
There
are
many
rfc
that
says
a
snapshot
dated,
of
course,
in
2021,
2002
or
whatever.
So,
let's
continue
the
job.
Thank
you.